Service Capability Discovery

ActivityPub Server to Server
,
9

the concept of “server actor” is still not well-defined – what makes an actor a “server actor”? a server can have zero or more actors. for example, pleroma/akkoma uses different “internal” actors for different purposes:

  • internal.fetch is used to proxy signed fetches. it is served at /internal/fetch.
  • relay is used to relay public posts from local users. it is served at /relay.

you could imagine many such actors which don’t correspond to users – perhaps a delivery actor delivers activities on behalf of local users, perhaps a moderation actor can be used to send and receive Flag activities or communicate with other mod teams, perhaps any number of other actors could be spun for specific use cases. whether any or all of these are considered “server actors” depends on the definition, and i’d be hard pressed to say that exactly one of these is the “server actor” without further clarification.

which URI should be used as the resource parameter on the webfinger query? i identified several possibilities:

  • acct:domain.example@domain.example
    • is userpart == host always the “server actor”?
  • https://domain.example/
    • is / always the “server actor”?
    • is https://domain.example equivalent?

previously, this ambiguity was solved by using /.well-known/host-meta to describe the host itself, without going through webfinger – in fact, you would previously go through there to find webfinger, before /.well-known/webfinger was defined. you could even use that well-known URI to represent the host itself, with a minimal extension to host-meta to allow content negotiation as application/activity+json (which is an option not precluded by RFC 6415) if you aren’t put off by having to serialize an XRD and JRD as well. otherwise, any arbitrary resource name could be used.

hopefully the two quotes above taken together should show the conflict. generator does not mean “server actor”. you shouldn’t assume “generator” and “server actor” are the same or equivalent property. they just sometimes have the same value.

i would say it’s more generally useful in all cases where you have an inbox that is an HTTP resource. using HTTP mechanisms for HTTP resources is entirely natural.

regarding FEP-844e specifically, i have commented on the actual discussion thread: FEP-844e: Capability discovery - #7 by trwnh

1 Like