FEP-2677: Identifying the Application Actor

Standards Fediverse Enhancement Proposals
, ,
1

Hello!

This is a discussion thread for the proposed FEP-2677: Identifying the Application Actor.
Please use this thread to discuss the proposed FEP and any potential problems
or improvements that can be addressed.

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.
4 Likes
2

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):

https://directory.example/.well-known/webfinger?resource=https://node.example

or

https://directory.example/.well-known/webfinger?resource=https://node.example&rel=https://purl.archive.org/funfedi/applicationActor

could return

 {
    "subject": "https://node.example",
    "properties": [
        "https://codeberg.org/fediverse/fep/fep-2677": true,
        "https://codeberg.org/fediverse/fep/fep-4adb": true
        "https://codeberg.org/fediverse/fep/fep-4adb/some_option": 42
    ],
    "links": [
        {
            "rel": "https://purl.archive.org/funfedi/applicationActor",
            "href": "https://node.example/actor"
        }
    ]
 }

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.

2 Likes
3

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.

what do you think?

4

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.

5

I would rather see the metadata for this instance in the profile of the instance actor.

7

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.

8

In my vision, the information for support could get quite complicated, e.g.

  • FEP-67ff → specify the FEDERATION.md link
  • ActivityStreams → list supported Activity / Object combinations

This means we want a somewhat malleable data structure as given by json-ld.

Also I don’t think one necessarily needs to embed anything anywhere. The application actor could contain the @id of the properties document.

9

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.

10

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).

11

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.

12

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).

1 Like
13

It’s a machine. There is only one :wink: Unless you scale and have multiple nodes :rofl:

14

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).

15

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.

16

Adding a list of Application Actor paths to the FEP is probably a good idea.

Does someone know of one? Or do I have to attempt to compile it?

17

This document MUST then contain a link with relation https://purl.archive.org/funfedi/applicationActor

@helge I suggest using https://www.w3.org/ns/activitystreams#Application relation type, which would be self-describing.

Next, a request to https://node.example/actor with accept header application/activity+json could return

Spec-compliant implementations MUST use application/ld+json; profile="https://www.w3.org/ns/activitystreams"

This might be difficult to implement in some cases, for example when instance root URL is a static site. NodeInfo/WebFinger provides more flexibility.

Also, an old discussion on instance actors: Activities for Federation Application?

1 Like
18

Yeah, that’s a lot smarter.

19

I’ve updated FEP-2677:

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.

1 Like
20

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.

  def bot?
    %w(Application Service).include? actor_type
  end

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.

21

Just FYI, it looks like Funkwhale uses the “Service” AP actor type for it’s “instance actor” (they call it a “service actor”).

See also: