mirrors/fep
1
0
Fork 0
mirror of https://codeberg.org/fediverse/fep.git synced 2026-08-05 19:55:46 +00:00
Code Packages Wiki Activity

Update fep-2677

Browse Source
This commit is contained in:
Helge
2023-10-17 17:50:48 +02:00
parent fda7b5cef5
commit 9040bbe6a4
1 changed files with 52 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
fep/2677/fep-2677.md
+52 -7
View File
@@ -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