Servers can advertise what features of the API they support, such as creating a poll or boosting a post. Clients can recognize if a server doesn’t support a feature and hide it from the UI.
As the fediverse grows, we’ll naturally see a wide range of servers and clients, and not all of them will exactly match the features that popular clients like Mastodon support. To support a diverse mix of clients with different user experiences, clients and servers should communicate about which features should be shown in the client UI.
Some services might not include public likes or polls, for example. Some might not include boosting. It would be confusing for a boost icon to show an error message when clicked if that feature was not available. Instead, the client should detect whether boosting is available, and if not simply hide the icon when connected to that server.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this specification are to be interpreted as described in RFC 2119.
Document in NodeInfo the ActivityStreams types and properties that correspond to features the server supports. This information can be used by both ActivityPub clients as well as Mastodon API clients. We use ActivityStreams types because they are already part of a fediverse standard, rather than inventing new keys to describe existing features.
Add a new top-level field types to NodeInfo with three fields, all of which are optional:
activities: The types of activities the server broadly supports.objects: The types of objects that the server supports in the relevant activities.properties: For each activity or object, what properties are allowed in that object.If no types are present in NodeInfo, a client should assume a server supports all types, just as most clients do today.
If no objects are present for an activity, a client should assume a server supports all common objects. If a limited number of objects are present, a client should assume a server only supports those objects.
If no properties are present for an object, a client should assume a server supports all common properties. If a limited number of properties are present, a client should assume a server only supports those properties.
The following examples are simplified versions of what most servers should support. Most popular servers will support more activity and object types than this, but these examples keep the list short for readability. Other common activities include Follow, Undo, Accept, Block, and others as listed in the Activity Vocabulary specification.
Review)This example adds Review, an object used by BookWyrm for book reviews. Because only properties for Review are specified, a client can assume that all common objects and properties for the other activities are supported.
{
"types": {
"activities": [
"Create",
"Like",
"Announce",
"Question",
"Move",
"Follow"
],
"objects": [
"Note",
"Article",
"Image",
"Review"
],
"properties": {
"Review": [ "title", "body", "rating", "inReplyToBook" ]
}
}
}
Question)This example leaves off the Question type and the oneOf property used for polls.
{
"types": {
"activities": [
"Create",
"Like",
"Announce"
],
"objects": [
"Note",
"Article",
"Image"
],
"properties": {
"Note": [ "summary", "content", "published", "inReplyTo" ],
"Article": [ "name", "content", "published" ]
}
}
}
name)This example includes only the content and published properties for Article, meaning the client should not prompt for a title for long-form articles.
{
"types": {
"activities": [
"Create",
"Like",
"Announce",
"Question",
],
"objects": [
"Note",
"Article",
"Image"
],
"properties": {
"Question": [ "oneOf" ],
"Note": [ "summary", "content", "published", "inReplyTo" ],
"Article": [ "content", "published" ]
}
}
}
Announce)This example lists the bare minimum types, leaving off the explicit list of objects and properties. Clients should assume the server supports whatever properties are common for those types, such as Note, Article, and others.
{
"types": {
"activities": [
"Create",
"Like",
"Question",
"Move"
]
}
}
Move)This example lists object and target fields that are used for account migration with the Move activity.
{
"types": {
"activities": [
"Create",
"Like",
"Announce",
"Question",
"Move"
],
"properties": {
"Move": [ "object", "target" ]
}
}
}
There have been a few other attempts at addressing how to describe what a server supports:
CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
To the extent possible under law, the authors of this Fediverse Enhancement Proposal have waived all copyright and related or neighboring rights to this work.