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,
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.
It might be more clear to name this FEP “Instance Actor Discovery”. Identifying an actor could be confused with actor identity topics.
I’d like to see either Application or Service actor types be allowed. However, even if it were some other AS2 actor-related type, I think it doesn’t change any AP behavior. If so, maybe the actor type should only be required to be a valid AS2 actor type?
Did you consider using Webfinger for instance actor discovery? Some advantages:
Webfinger is already used for account-based actor discovery
It’s already required for Fediverse interop (nodeinfo is not).
It’s a formal specification, whereas nodeinfo is informally specified.
It can support decentralized discovery (e.g., third-party instance actor directories)
For example, a discovery request (it would be URL-encoded in practice):
This response includes properties for FEP implementation status (rather than embedding them in the instance actor document). This would allow instances that don’t have an instance actor to also advertise FEP support. However, I think this should be the topic of a separate FEP in any case.
i think a good idea to find/resolve actors is webfinger. then we only have to define the reserved name of the instance actor. e.g. ApInstanceActor or ActivityPubActor, … that is resolvable by webfinger.
WebFinger can provide metadata for any resource. The Mastodon -iverse uses it with an “acct:*” URI to convert account names to actor URIs, but for instance actors I think it makes more sense to treat the instance itself as a resource and the instance-level actor link as metadata for that instance.
Why is that? It would require any implementation that wants to provide metadata (about FEP support, for example) to have an instance-level actor with additional inbox/outbox and other actor-related requirements. It seems like an unnecessary coupling of independent features.
Maybe I could be convinced otherwise, but I currently think it would not be a good idea to consider the instance-level actor as a proxy for the instance itself. The notion of an instance-level actor is still a bit vague. How is it technically different than any other actor? Why can there only be one? Maybe an instance wants an “instance actor” representing the moderation team, and another for technical site administration, and another for relay support. (Those would probably be Group or Organization actors rather than Application or Service.)
As far as I can tell, an “instance actor” is any actor that is referenced by the instance metadata with the instance actor link relation. There might be different authorizations for an instance actor compared to a non-instance actor, but that hasn’t been specified yet. In the examples of instance actors I gave above, each of them might have different authorizations, depending on their role.
it is often the case that an application has exactly one admin account. this account can then create other users and assign permissions. it can decide whether there are other users who are allowed to do the same as it.
Makes sense to me. I thought about that but I didn’t know what you had in mind for the FEP metadata. Either way, the WebFinger links can reference an FEP-related metadata document independently from one or more instance actors.
Yes, but it still requires an actor to hold the @id of the properties document (which doesn’t appear to be actor-specific, although that’s not completely clear yet).
At the moment i like the idea of putting an admin task in the inbox of the main instance actor.
And implementing “inbox/outbox and other actor-related requirements” is allready done, if you are an AP Application.
That’s sometimes the case, but also often it’s not the case. Mastodon allows multiple admin accounts, for example, and I know of many other applications where “admin” is a role that can be assigned to multiple users.
As far as I know, the “instance actor” in Mastodon is a distinct concept from admin accounts.
However, this potential ambiguity is why I think we may need an FEP for “instance actors” that clearly defines what they are and the requirements associated with them. The discovery technique could be part of that document or separate (especially if we envision alternative discovery techniques).
Some instance implementations are limited to a single actor. To support an “instance actor”, do they need to implement a special instance actor (different technical requirements) or can the original actor serve the purpose?
Either way, your comment is illustrating my point about the unclear semantics for an “instance actor”. Is it a proxy for a “machine”, a proxy for an admin account, a proxy for an “instance”, something else?
Also, instance is an abstraction and it doesn’t necessarily correspond to a single machine (virtual/container or bare metal), a single operating system process, or a single internet domain. Inversely, a single operating system process can host any number of instances, which effectively just become URI prefixes/namespaces (Vocata does this, for example).
For Lemmy we simply have the instance actor available at the root path, eg at https://lemmy.ml/. I think that makes a lot more sense than a separate resolve step, or hardcoding a software specific path.
Requirements is now divided into a definition of application actor and how it is identified using NodeInfo. I’m using @silverpill’s suggestion of using https://www.w3.org/ns/activitystreams#Application instead of a custom URI.
I’ve added a Discussion Section that contains some thoughts on questions like Service vs Application and reusing the Nodeinfo approach.
As already mentioned application actors are currently used by most Fediverse applications to fetch public keys.
I think this (and the referenced earlier information) would benefit from being more specific. I assume you mean the public keys of the Application actor specifically (vs public keys, in general).
My Mastodon instance can fetch the public keys for any actor without a signed request. I seem to be able to do the same with mastodon.social (based on testing with a few actors).
Mastodon uses Service for bot accounts.
Mastodon considers Application actors to be bot accounts too.
%w(Application Service).include? actor_type
It’s not clear to me that the referenced projects use an instance actor in the same way or in the way the FEP requires. I also wonder if the instance actor can be followed, blocked, implements an outbox (it must implement the endpoint, at least), can be mentioned in posts, etc. In other words, is it a regular actor other than never requiring signed fetches for the actor resource?
Also, until there’s more discussion about nodeinfo, I’m -1 for the reasons I stated previously.