From 9040bbe6a4571754ee468fe4d3cf4c9439bf8d70 Mon Sep 17 00:00:00 2001 From: Helge Date: Tue, 17 Oct 2023 17:50:48 +0200 Subject: [PATCH] Update fep-2677 --- fep/2677/fep-2677.md | 59 ++++++++++++++++++++++++++++++++++++++------ 1 file changed, 52 insertions(+), 7 deletions(-) diff --git a/fep/2677/fep-2677.md b/fep/2677/fep-2677.md index 4e86679..d9adb34 100644 --- a/fep/2677/fep-2677.md +++ b/fep/2677/fep-2677.md @@ -10,7 +10,7 @@ discussionsTo: https://codeberg.org/fediverse/fep/issues/190 ## 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` +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. @@ -26,12 +26,26 @@ could attach a list of implemented FEPs to the application actor. ## Requirements -The key word "MUST" in this specification are to be interpreted as described in [RFC 2119]. +### Application Actor -Following [NodeInfo], see also [FEP-f1d5], a Fediverse application implementing this -FEP, i.e. FEP-2677, MUST provide the well-known path `/.well-known/nodeinfo` and serve a document in JRD format [RFC 7033]. -This document MUST then contain a link with relation `https://purl.archive.org/funfedi/applicationActor`, -whose link resolves to an actor of type `Application` (see [ActivityPub]). This actor MUST be retrievable with an unsigned HTTP request. +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](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-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](#currently-implemented-application-actors) 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 @@ -46,7 +60,7 @@ to `https://node.example/.well-known/nodeinfo` will resolve to "href": "https://node.example/nodeinfo/2.0" }, { - "rel": "https://purl.archive.org/funfedi/applicationActor", + "rel": "https://www.w3.org/ns/activitystreams#Application", "href": "https://node.example/actor" } ] @@ -74,6 +88,37 @@ could return } ``` +## 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://codeberg.org/bovine/bovine/) | `https://bovine.example/activitypub/bovine` | +| [Firefish](https://joinfirefish.org/) | `https://firefish.example/actor` | +| [Lemmy](https://join-lemmy.org/) | `https://lemmy.example/` | +| [Mastodon](https://joinmastodon.org/) | `https://mastodon.example/actor` | +| [Mitra](https://codeberg.org/silverpill/mitra) | `http://mitra.example/actor` | +| [Pleroma](https://pleroma.social/) | `https://pleroma.example/internal/fetch` | + +__Note__: Feel free to add further links. + ## References - [ActivityPub] Christine Lemmer Webber, Jessica Tallon, [ActivityPub](https://www.w3.org/TR/activitypub/), 2018