FEP-2677: Identifying the Application Actor

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	-

参考文献

• [ActivityPub] Christine Lemmer Webber, Jessica Tallon, ActivityPub, 2018
• [FEP-f1d5] CJ, silverpill, NodeInfo in Fediverse Software, 2023
• [NodeInfo] NodeInfo protocol 2.1
• [RFC 2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 1997
• [RFC 7033] P. Jones, G. Salgueiro, M. Jones, J. Smarr, Webfinger, 2013

著作権

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

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