FEP-eb22: Supported ActivityStreams types with NodeInfo

Warning

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

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

Summary

Servers can advertise what features of the API they support, such as creating a poll or boosting a post. Clients can recognize if a server doesn't support a feature and hide it from the UI.

Background

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 popular clients like Mastodon support. To support a diverse mix of clients with different user experiences, clients and servers should communicate about which features should be shown in the client UI.

Some services might not include public likes or polls, for example. Some might not include boosting. It would be confusing for a boost icon to show an error message when clicked if that feature was not available. Instead, the client should detect whether boosting is available, and if not simply hide the icon when connected to that server.

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.

Proposal

Document in NodeInfo the ActivityStreams types and properties that correspond to features the server supports. This information can be used by both ActivityPub clients as well as Mastodon API clients. We use ActivityStreams types because they are already part of a fediverse standard, rather than inventing new keys to describe existing features.

Add a new top-level field types to NodeInfo with three fields, all of which are optional:

  • activities: The types of activities the server broadly supports.
  • objects: The types of objects that the server supports in the relevant activities.
  • properties: For each activity or object, what properties are allowed in that object.

If no types are present in NodeInfo, a client should assume a server supports all types, just as most clients do today.

If no objects are present for an activity, a client should assume a server supports all common objects. If a limited number of objects are present, a client should assume a server only supports those objects.

If no properties are present for an object, a client should assume a server supports all common properties. If a limited number of properties are present, a client should assume a server only supports those properties.

例

The following examples are simplified versions of what most servers should support. Most popular servers will support more activity and object types than this, but these examples keep the list short for readability. Other common activities include Follow, Undo, Accept, Block, and others as listed in the Activity Vocabulary specification.

Supporting common social features and book reviews (Review)

This example adds Review, an object used by BookWyrm for book reviews. Because only properties for Review are specified, a client can assume that all common objects and properties for the other activities are supported.

{
  "types": {
    "activities": [
      "Create",
      "Like",
      "Announce",
      "Question",
      "Move",
      "Follow"
    ],
    "objects": [
      "Note",
      "Article",
      "Image",
      "Review"
    ],
    "properties": {
      "Review": [ "title", "body", "rating", "inReplyToBook" ]
    }
  }
}

Supporting common social features, but not supporting polls (Question)

This example leaves off the Question type and the oneOf property used for polls.

{
  "types": {
    "activities": [
      "Create",
      "Like",
      "Announce"
    ],
    "objects": [
      "Note",
      "Article",
      "Image"
    ],
    "properties": {
      "Note": [ "summary", "content", "published", "inReplyTo" ],
      "Article": [ "name", "content", "published" ]
    }
  }
}

Supporting common social features including polls, but not supporting titled posts (name)

This example includes only the content and published properties for Article, meaning the client should not prompt for a title for long-form articles.

{
  "types": {
    "activities": [
      "Create",
      "Like",
      "Announce",
      "Question",
    ],
    "objects": [
      "Note",
      "Article",
      "Image"
    ],
    "properties": {
      "Question": [ "oneOf" ],
      "Note": [ "summary", "content", "published", "inReplyTo" ],
      "Article": [ "content", "published" ]
    }
  }
}

Supporting common social features, but not supporting boosts (Announce)

This example lists the bare minimum types, leaving off the explicit list of objects and properties. Clients should assume the server supports whatever properties are common for those types, such as Note, Article, and others.

{
  "types": {
    "activities": [
      "Create",
      "Like",
      "Question",
      "Move"
    ]
  }
}

Supporting common social features and account migration (Move)

This example lists object and target fields that are used for account migration with the Move activity.

{
  "types": {
    "activities": [
      "Create",
      "Like",
      "Announce",
      "Question",
      "Move"
    ],
    "properties": {
      "Move": [ "object", "target" ]
    }
  }
}

There have been a few other attempts at addressing how to describe what a server supports:

参考文献

著作権

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

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