FEP 6841: Specifying ActivityPub extension support with NodeInfo (#278)

Motivated by the need to know if a remote server supports a particular ActivityPub extension, I've knocked this proposed solution together based on defining extension IRIs, and adding them into a server's NodeInfo response. I'm totally open to changing pretty much anything about this, it's as much a prompt for discussion as a completely thought-out proposal. Reviewed-on: https://codeberg.org/fediverse/fep/pulls/278 Co-authored-by: James Smith <james@floppy.org.uk> Co-committed-by: James Smith <james@floppy.org.uk>
2026-08-05 19:55:46 +00:00 · 2024-03-12 20:52:24 +00:00
parent 9c13aed638
commit 304a84c46d
1 changed files with 116 additions and 0 deletions
@@ -0,0 +1,116 @@
+---
+slug: "6481"
+authors: James Smith <james@floppy.org.uk>
+status: DRAFT
+dateReceived: 2024-03-12
+relatedFeps: FEP-f1d5
+---
+# FEP-6481: Specifying ActivityPub extension support with NodeInfo
+
+
+## Summary
+
+Many FediVerse services extend [ActivityPub] and [ActivityStreams] to add their own behaviour, such as custom object types. In order to interoperate with other servers running different software, the service needs to know whether or not the remote server supports these same extensions.
+
+This FEP defines a standard method of specifying support for particular extensions in the server's [NodeInfo] file (as described in [FEP-f1d5]), so that compatibility information can be automatically discovered.
+
+## History
+
+Many FediVerse software platforms such as [Bookwyrm] and [Pixelfed] have used the NodeInfo `software` field to determine if a remote server is running the same software, and is therefore compatible with their extensions. This works, however it restricts full interoperability with different software that could potentially use the same types.
+
+## Requirements
+
+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].
+
+## Declaring extension support
+
+FediVerse software that extends ActivityPub SHOULD indicate extension support in its [NodeInfo] file.
+
+Extension identifiers MUST be valid IRIs. IRIs MAY be created with the [w3id.org] Permanent Identifier service, and if so they SHOULD redirect to a document that describes the extension.
+
+To comply with this FEP, extensions MUST be specified in the `metadata` section of the NodeInfo file, as shown below:
+
+```json
+ {
+  "version": "2.2",
+  ...,
+  "protocols": ["activitypub"],
+  ...,
+  "metadata": {
+    "activitypub": {
+      "extensions": [
+        "https://w3id.org/my-project/my-extension#v1"
+      ]
+    }
+  }
+}
+```
+
+*Note: The metadata key `activitypub` is chosen to match the string in `protocols`, and is refers to extensions in any of ActivityPub, ActivityStreams and the Activity Vocabulary.*
+
+It is RECOMMENDED that extension developers specify version information in their IRIs, for instance in a fragment identifier as above.
+
+Once defined, IRIs MUST be constant - they cannot be changed while retaining compatibility. For this reason, it is RECOMMENDED to use a long-term service (e.g. w3id.org) for IRIs.
+
+### Defining IRIs
+
+No specific recommendation is made for IRI design, although if using w3id.org, their [Naming Policy](https://w3id.org/#naming-policy) should be adhered to.
+
+## Examples
+
+*This section is non-normative.*
+
+[Manyfold] intends to define a new Activity Vocabulary Object type for its own rich content, `3dModel`. The specification will define an extension IRI, for instance `https://w3id.org/manyfold/3dModel#v1`.
+
+Applications that wish to receive Activities with this type can state their support for the extension in their NodeInfo file as follows; Manyfold instances will then know that they can send that object type and it will be understood.
+
+```json
+{
+  ...,
+  "metadata": {
+    "activitypub": {
+      "extensions": [
+        "https://w3id.org/manyfold/3dModel#v1"
+      ]
+    }
+  }
+}
+```
+A similar (entirely theoretical) example for [Bookwyrm]'s `Review` object type might be:
+
+```json
+{
+  ...,
+  "metadata": {
+    "activitypub": {
+      "extensions": [
+        "https://joinbookwyrm.org/ns/activitypub#Review"
+      ]
+    }
+  }
+}
+```
+
+## References
+
+- FEP-f1d5, [NodeInfo in Fediverse Software][FEP-f1d5]
+- James Smith, [Manyfold ActivityPub design document][Manyfold], 2024
+- James M. Snell & Evan Prodromou, [ActivityStreams 2.0][ActivityStreams], 2017
+- Christine Lemmer-Webber & Jessica Tallon, [ActivityPub][ActivityPub], 2018
+- S. Bradner, [Key words for use in RFCs to Indicate Requirement Levels][RFC-2119], 1997
+
+
+[ActivityPub]: https://www.w3.org/TR/activitypub/
+[ActivityStreams]: https://www.w3.org/TR/activitystreams-core/
+[Bookwyrm]: https://docs.joinbookwyrm.com/activitypub.html
+[FEP-f1d5]: https://codeberg.org/fediverse/fep/src/branch/main/fep/f1d5/fep-f1d5.md
+[Manyfold]: https://manyfold.app/technology/activitypub.html
+[NodeInfo]: https://nodeinfo.diaspora.software/
+[Pixelfed]: https://docs.pixelfed.org/spec/ActivityPub.html
+[RFC-2119]: https://tools.ietf.org/html/rfc2119.html
+[w3id.org]: https://w3id.org
+## Copyright
+
+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.