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.
We will first define, what we mean by an application actor. We will impose two requirements on them
As already mentioned application actors are currently used by most Fediverse applications to fetch public keys. See here for a list of examples.
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.
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"
}
}
The approach of this FEP has been chosen to have a light touch. Some alternative choices would be:
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:
Application
is triggered by events in the application, e.g. a signed request and then fetching the corresponding public key.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.
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 Universal (CC0 1.0) Public Domain Dedication
To the extent possible under law, the authors of this Fediverse Enhancement Proposal have waived all copyright and related or neighboring rights to this work.