One of the discussions at FediForum this week that was the most valuable for me was the session by Nic Clayton for FEP-9fd3. The goal is for servers to advertise what features of the Mastodon client API they can support, such as creating a poll or boosting a post. Clients could recognize if a server didn’t support a feature and hide it from the UI.
I’ve been holding off adding Mastodon client API support to Micro.blog until we have some kind of convention for this. 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 Mastodon supports. Micro.blog does not include public likes or boosts, for example. It would be confusing for a boost icon to just show an error message when clicked.
FEP-9fd3 attempts to solve this by listing “operations” for a server, with a versioning system. There is also the related FEP-6481 that lists “extensions” to the standard suite of ActivityStreams types. BookWyrm, for example, supports most of the standard types but also adds a book “Review” type.
I don’t think either of these is quite right for what is needed. Instead, at FediForum we discussed an idea to describe the activity and object types a server supports by name. I’m imagining the format to look something like this, in NodeInfo:
{
"types": {
"activities": [
"Create",
"Like",
"Announce",
"Question",
"Move"
],
"objects": [
"Note",
"Article",
"Image"
],
"properties": {
"Question": [ "oneOf" ],
"Move": [ "object", "target" ],
"Note": [ "summary", "content", "published", "inReplyTo" ],
"Article": [ "name", "content", "published" ]
}
}
}
Specifying properties would be optional. An empty array would indicate that a server supported all common properties for that object. If the “types” field was missing from NodeInfo, clients could assume a server supported everything, just as they do today for Mastodon servers. I’m not tied to this format, although I like that it’s fairly clean. There are many ways to describe this sort of thing.
Another issue is that we’re sort of mixing ActivityPub types with the Mastodon client API. The client API has its own name for things, like “statuses” instead of “notes”, and “polls” instead of “questions”. While the goal is to adapt API clients, defining this based on an existing standard makes some sense to me, and would naturally translate to the ActivityPub Client to Server API, which really should be used more often.
If there’s interest, I’d be happy to work with someone to formalize this in a FEP. It feels like an important missing piece.
