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:
{
"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 should be adhered to.
例
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.
{
...,
"metadata": {
"activitypub": {
"extensions": [
"https://w3id.org/manyfold/3dModel#v1"
]
}
}
}
A similar (entirely theoretical) example for Bookwyrm's Review
object type might be:
{
...,
"metadata": {
"activitypub": {
"extensions": [
"https://joinbookwyrm.org/ns/activitypub#Review"
]
}
}
}
参考文献
- FEP-f1d5, NodeInfo in Fediverse Software
- James Smith, Manyfold ActivityPub design document, 2024
- James M. Snell & Evan Prodromou, ActivityStreams 2.0, 2017
- Christine Lemmer-Webber & Jessica Tallon, ActivityPub, 2018
- S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 1997
著作権
CC0 1.0 ユニバーサル (CC0 1.0) パブリック ドメイン
法律で認められる範囲において、この Fediverse 拡張提案の著者は、この作品に対するすべての著作権および関連する権利または隣接する権利を放棄しています。