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
- It's an [ActivityPub] Actor of type Application.
- 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:
- A fixed path for the application actor
- 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 typeService
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 拡張提案の著者は、この作品に対するすべての著作権および関連する権利または隣接する権利を放棄しています。