Extension Support Discovery

ActivityPub Server to Server
1

With inspiration of Service Discovery from XMPP (XEP-0030), which enables XMPP servers/clients to add, support, and deprecate extensions in a piecemeal manner, it may be worth implementing similar concepts within ActivityPub applications.

Meanwhile, some existing applications announce details of their support and configuration in their Nodeinfo metadata. Whereas Pleroma (and derivatives), enumerates a clear list under “features” and other service limits, and PeerTube announces what functionality is enabled and such under “nodeConfig”.

The reason why this is important is: having a cross-vendor serialization that’s mutually supported would enable being able to “upgrade” ActivityPub as a protocol incrementally, and as a more practical approach than something ‘profile-based’ (as in, a versioned package of extensions together) which would be exceptionally more difficult to agree upon.

For example, one application of this could be for replacing and upgrading to RFC9421 (HTTP Message Signatures) and finally dropping the expired/replaced ‘draft-cavage-http-signatures-12’ draft from +4 years ago. If this were presented in a ‘features’ list (or similar) announced in Nodeinfo, it could be as simple as checking for if ‘rfc9421’ is in the list (or especially: the respective FEP identifier, for something that gives a specific opinionated use of the RFC), and then doing RFC9421-based signatures instead, if support is listed by the remote end.

Nonetheless, in order to advance this idea, there are few questions worth discussing:

  • Is Nodeinfo an appropriate mechanism for announcing extension support? Should a different endpoint be used instead?
  • Should feature support perhaps be split/categorized between federation-specific (S2S) and client-specific (C2S) features?
  • Is it worth expanding this to what object types are supported also? (e.g. announcing support for Article, Page, Event, etc?), Or should that instead be left to FEP (or other spec identifiers) that’s inherently more specific (given two implementations may have very different definitions of the same type)?
  • Is a tag list the most rational approach, or is there any merit in making it more complicated (should it allow being an object/map type instead)?
  • Should there be a fallback mechanism to have it announced in an actor object instead, would that impose any risks? Alternatively: is it worth extending the same format to actors, like with the capabilities property in actor objects in Pleroma?
6 Likes
2

Proposal for specifying extensions support with NodeInfo has been submitted .

2 Likes