FEP-6481: Specifying ActivityPub extension support with NodeInfo

Warning

このFEPはまだ翻訳されていません。

ここから翻訳に協力することができます。

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"
      ]
    }
  }
}

参考文献

著作権

CC0 1.0 ユニバーサル (CC0 1.0) パブリック ドメイン

法律で認められる範囲において、この Fediverse 拡張提案の著者は、この作品に対するすべての著作権および関連する権利または隣接する権利を放棄しています。