FEP-2677: Identifying the Application Actor

Warning

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

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

Summary

It is a common pattern in Fediverse applications to have a special actor of type Application. This is for example the actor at https://mastodon.example/actor for Mastodon or at https://pleroma.example/internal/fetch for Pleroma. This application actor can be fetched with an unsigned request, so it is possible to use it to fetch public keys.

The goal of this FEP is to provide an explicit mechanism of identifying the application actor, with the goal of making it usable for further tasks, e.g.

  • Allowing for application to application communication by having application actor send activities to another application actor's inbox.
  • Having an object one can attach further information to. This means, one could attach a list of implemented FEPs to the application actor.

Requirements

Application Actor

We will first define, what we mean by an application actor. We will impose two requirements on them

  1. It's an [ActivityPub] Actor of type Application.
  2. It can be retrieved without authentication, e.g. with an unsigned HTTP request.

As already mentioned application actors are currently used by most Fediverse applications to fetch public keys. See here for a list of examples.

Identifying the Application Actor with nodeinfo

In [NodeInfo], see also [FEP-f1d5], the well-known path /.well-known/nodeinfo is defined and it is specified that a document in JRD format [RFC 7033] is served there.

The requirement of the current FEP is that the /.well-known/nodeinfo contains an additional link with relation type https://www.w3.org/ns/activitystreams#Application, which resolves to an application actor as described in the previous section.

We note that it is not necessary to implement the relations specified in [NodeInfo] to satisfy the current FEP.

Example

We will consider the server with domain node.example. This means that a request to https://node.example/.well-known/nodeinfo will resolve to

 {
    "links": [
        {
            "rel": "http://nodeinfo.diaspora.software/ns/schema/2.0",
            "href": "https://node.example/nodeinfo/2.0"
        },
        {
            "rel": "https://www.w3.org/ns/activitystreams#Application",
            "href": "https://node.example/actor"
        }
    ]
 }

Next, a request to https://node.example/actor with accept header application/activity+json could return

{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        "https://w3id.org/security/v1",
    ],
    "id": "https://node.example/actor",
    "type": "Application",
    "inbox": "https://node.example/actor/inbox",
    "outbox": "https://node.example/actor/outbox",
    "publicKey": {
        "id": "https://node.example/actor#main-key",
        "owner": "https://node.example/actor",
        "publicKeyPem": "-----BEGIN PUBLIC KEY-----\n....\n-----END PUBLIC KEY-----\n"
    }
}

Discussion

The approach of this FEP has been chosen to have a light touch. Some alternative choices would be:

  1. A fixed path for the application actor
  2. A fixed path for application information instead of aiming to attach it to the application actor.

Both options have the downside that it would require to introduce a new path, which forces every implementation to implement it in a similar way. Instead, we reuse an existing path, and the implementer is free to choose where to put the application actor.


The second question is why fix the type Application and not Service. First, it is consistent with most current implementations. Second, Mastodon uses Service for bot accounts. So it feels like a good idea to start distinguishing from this usage. We would phrase this distinction as follows:

  • An actor of type Application is triggered by events in the application, e.g. a signed request and then fetching the corresponding public key.
  • An actor of type Service is triggered by either activities arriving at its inbox or external events, e.g. a timer. This means an actor of type Service is similar to one controlled by an user.

These are not hard rules on when to use Application or Service. They will probably break down as more complicated Fediverse implementations are build. We hope that they can serve as a level of guidance, how to differentiate actors.

Currently implemented application actors

Software Application Actor URI
Bovine https://bovine.example/activitypub/bovine
Firefish https://firefish.example/actor
Lemmy https://lemmy.example/
Mastodon https://mastodon.example/actor
Mitra http://mitra.example/actor
Pleroma https://pleroma.example/internal/fetch
Mbin https://mbin.example/i/actor
WordPress https://wordpress.example/wp-json/activitypub/1.0/application
Mobilizon https://mobilizon.example/relay
Gancio https://gancio.example/federation/u/<instance_name>
Friendica https://friendica.example/
PeerTube https://peertube.example/accounts/peertube
Pixelfed https://pixelfed.example/i/actor

Note: Feel free to add further links.

実装

Software dateImplemented dateReleased
WordPress 2023-12-21 -
Mobilizon 2023-12-14 -
Gancio 2023-12-22 -

参考文献

著作権

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

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