So, what even is an instance actor?

[trwnh]

Branching out of FEP-2677: Identifying the Application Actor

@stevebate

On one hand, I have concerns about nodeinfo becoming required for federation when webfinger is already required. On the other, since “Application Actor” is not a well-defined concept, they and the extended nodeinfo support probably won’t become a general federation requirement and instead be an implementation-specific consideration.

I still believe we should have defined Application Actor better (requirements, behaviors, recommended practices) before, or in addition to, defining a discovery mechanism for a poorly-defined concept.

@stevebate

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?

@stevebate

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

@stevebate

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.

@stevebate brings up good points that deserve some effort at clarification and definition. in this topic, i will explore some of them.

prior art

xmpp

takeaway 1: activitypub servers communicate with an inbox endpoint, but xmpp communicate directly with other servers

xmpp doesn’t have a similar concept besides the use of “IQ stanzas” to query for information directly from the other server’s connection. this is used for XEPs such as XEP-0030: Service Discovery or XEP-0157: Contact Addresses for XMPP Services which look something like this:

<iq from='juliet@capulet.com/chamber'
    to='shakespeare.lit'
    id='disco1'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

note that to is just the fqdn of the xmpp server, so there is no real discovery needed to get to this point. the server is always represented by its own fqdn. this is similar to the proposal to just always put the instance actor at the root url of the instance. but more saliently, xmpp establishes streams for c2s and s2s in such a way that it is somewhat analogous to having all communication happen between servers or “server actors”.

from rfc 6120 section 2.5 “distributed network of clients and servers”:

   end-to-end communication in XMPP is logically peer-to-
   peer but physically client-to-server-to-server-to-client, as
   illustrated in the following diagram.

     example.net <--------------> im.example.com
        ^                                ^
        |                                |
        v                                v
   romeo@example.net           juliet@im.example.com

from 4.3.6 “determination of addresses”:

For server-to-server communication, the initiating server’s bare JID (<domainpart>) MUST be the authorization identity

4.7.1 “from” / 4.7.2 “to”

   For initial stream headers in server-to-server communication, the
   'from' attribute is one of the configured FQDNs of the server, i.e.,
   a JID of the form <domainpart>.  The initiating server might have
   more than one XMPP identity, e.g., in the case of a server that
   provides virtual hosting, so it will need to choose an identity that
   is associated with this output stream (e.g., based on the 'to'
   attribute of the stanza that triggered the stream negotiation
   attempt).  Because a server is a "public entity" on the XMPP network,
   it MUST include the 'from' attribute after the confidentiality and
   integrity of the stream are protected via TLS or an equivalent
   security layer.

   I: <?xml version='1.0'?>
      <stream:stream
          from='example.net'
          to='im.example.com'
          version='1.0'
          xml:lang='en'
          xmlns='jabber:server'
          xmlns:stream='http://etherx.jabber.org/streams'>

   For response stream headers in server-to-server communication, the
   receiving entity MUST include a 'to' attribute in the response stream
   header and MUST set its value to the domainpart specified in the
   'from' attribute of the initial stream header.

   R: <?xml version='1.0'?>
      <stream:stream
          from='im.example.com'
          id='g4qSvGvBxJ+xeAd7QKezOQJFFlw='
          to='example.net'
          version='1.0'
          xml:lang='en'
          xmlns='jabber:server'
          xmlns:stream='http://etherx.jabber.org/streams'>

so we see a very clear pattern here where servers communicate directly with each other and address each other directly. activitypub works a bit differently in that each actor has their own inbox endpoint. the addressing within activitypub is more-or-less purely informational, because the real delivery happens via that POST to inbox. if you receive the activity, it doesn’t matter whether or not you are actually addressed in the activity. (this allows bto/bcc to work, also.)

so clearly, we need to rethink this for activitypub. let’s start by trying to define which communications should happen directly.

mastodon

takeaway 2: we mostly want something to receive reports and maybe blocks

mastodon in particular made the decision to start federating out Flag and Block activities, which are used to represent reports and blocks. however, the addressing is a bit wonky because of sharedInbox. mastodon just blindly assumes that it should POST to the sharedInbox if found… and otherwise it just POSTs directly to the reported or blocked user! this is generally undesirable and not-useful behavior. what is expected is that there is some separation between a “user” and their “instance”, although the server is implicitly expected to not differentiate significantly between a personal inbox and a shared inbox.

takeaway 3: maybe sharedInbox is enough, maybe it isn’t

so, is the sharedInbox “enough” to determine that the user is on an “instance”? well, if you just want to receive activities, then “maybe”. if you want to do anything else involving actors, then maybe not! maybe we need the concept of an “instance actor” to be more explicit and to allow for communications like any other actor.

takeaway 4: what happens if we make/encounter an “instance actor”? we can follow it.

having an actor implies we can send it activities and we can receive activities from it, and most importantly we can follow it. now that we have a reference to an actor and not just an inbox endpoint (via sharedInbox), this actor can be the object of a Follow.

theorycrafting

we established that:

1. other protocols like xmpp make s2s communication happen directly, without inboxes
2. the most likely use for an instance actor is to send and receive service-related activities like Flag or Block
3. the way this is currently done is sort of through sharedInbox
4. having an explicit instance actor most importantly allows us to Follow it

so here’s some possible use cases of what we can do with such an instance actor

• sending Flag and Block to the instance actor via an explicit inbox instead of via sharedInbox may not be too different, but it is at least a more pure model for interaction
• the instance actor may be followed to receive whatever the instance actor deems interesting enough to send out
  • perhaps it sends out notifications of local actions taken
  • perhaps it allows for admins to post regular statuses or notes or messages or whatever
    • this could be used for announcements
    • this could also be used for messaging other admin/mod teams directly as a sort of inter-instance mail system
  • perhaps it relays or Announces public posts from that instance

now we see we’re mostly missing a way for a follower to signal interest in arbitrary subsets of activities, which i have talked about previously in the form of followable Collections that you make into actors and then expose via streams. of course it could be some other mechanism, but eh.

some other concerns: can users follow instance actors? if so, aren’t they opting in to inter-instance communication on behalf of their admins? this implies that it would be best practice to not deliver administrative actions to the instance actor’s followers, at least.

discovering such an instance actor

if this is to be done, then it makes the most sense to use endpoints for this. endpoints are typically server-wide, and the mere presence of an endpoint like endpoints.instanceActor (name pending) should be enough to at least semantically guarantee that the server you are communicating with a) is an instance, b) can be communicated with directly / without involving users

{
  "@context": {
    "instanceActor": {
      "@id": "https://...",
      "@type": "@id"
    }
  }
}

conclusion

i left this open-ended because i’m not fully sure what the boundaries are for this “instance actor” concept. personally i don’t even like the idea of “instances” at all or that much, but i recognize that it’s a popular model for the sake of convenience

we might minimally say something like this for the normative requirements:

• if endpoints.instanceActor is present on an actor, you SHOULD send related Flag and Block to it
  • you MAY send them to endpoints.sharedInbox if present (?)
  • you SHOULD NOT send Flag and Block directly to the actor (?? i am unsure of this one because the semantics of Flag and Block are implementation-specific)

[aschrijver]

@trwnh

endpoints.instanceActor (name pending)

In the naming I’d avoid hardwiring “instance” as terminology. Maybe make it a systemActor instead to make it more versatile in applicability. That also kind of corresponds to well-known actor systems, like Akka, who use the term ActorSystem for the top-level coordinator of the actor hierarchy on a particular server.

I might also cross-ref my showerthoughts on actor systems vs. AP in: Thoughts on Actor Model versus Fediverse

[stevebate]

Excellent writeup. Thanks!

I agree that that are two terms here that are not well-defined (or defined and used ambiguously): instance and endpoint.

For endpoint, maybe we can qualify that as a network endpoint or an actor endpoint of some kind. Even then, network endpoint may be defined in various ways, but I’ll define it here as a (protocol, IP address or domain name, port). For AP, this applies to both HTTP/S POST and GET requests.

We could define instance as a network endpoint, but there are issues with that. For example, inbox URLs are not required to have the same network endpoint as an actor URI. I’m not sure what means from an “instance” perspective. It’s probably best to avoid using the term at all and be more specific about what we mean in the related discussions (network endpoint for AP POST/GET vs inbox URL, for example). However, when I use instance, I mean it in the sense of a network endpoint that can process AP POST/GET requests.

end-to-end communication in XMPP is logically peer-to-
peer but physically client-to-server-to-server-to-client …

@trwnh

so we see a very clear pattern here where servers communicate directly with each other and address each other directly. activitypub works a bit differently in that each actor has their own inbox endpoint.

This looks the same to me for XMPP and AP. Both protocols communicate server to server and the receiving servers use additional information (XMPP Address ResourcePart, AP URL path) to “route” incoming messages to their intended (inbox) destination. Of course, AP has other levels of delivery based on addressing in the payload of an incoming message.

An “inbox endpoint” (and that term is used this way in the spec) is a bit different than a network endpoint since it also includes the routing information in the URL (path + query). Others will probably disagree, but I think it would be more clear to use “inbox URL” instead of “inbox endpoint” to minimize confusion with network endpoints.

Given these definitions, it seems that an “instance actor” could be defined as an actor with a URI that matches the instance’s network endpoint. I’m not recommending that approach, but it would be reasonable and wouldn’t require any special non-AP server support or additional JSON-LD term definitions.

The reason I wouldn’t recommend it is because I don’t especially like the idea of a singleton/instance actor. The roles you are describing sound like some kind of moderation-related actor. The Application Actor FEP describes using the actor as a way to publish arbitrary instance metadata. Over time, I think a singleton instance actor will suffer from the “big ball of mud” pattern. Having more functionally oriented endpoint-level actors would also reduce the need for special collections to follow.

Again, thanks for initiating this discussion.

[trwnh]

@aschrijver

In the naming I’d avoid hardwiring “instance” as terminology.

@stevebate

I’m not sure what means from an “instance” perspective. It’s probably best to avoid using the term at all and be more specific about what we mean in the related discussions

i used the word “instance” to mean like the mastodon model. perhaps serviceActor would be more appropriate. i don’t think there is a reason to specify or require it to be a Service type, but that’s probably the direction things would head. this is tangential to the new as2 primer guidance that Service was meant to represent a server. (i believe during the issue triage meeting, evan explained that Application and Service were mostly inherited from the original Activity Streams, which used them as “client” and “server” mainly.)

@stevebate

two terms here that are not well-defined (or defined and used ambiguously): instance and endpoint.

let’s say

instance
: a software service hosting users

endpoint
: a uri that accepts HTTP requests, particularly POST requests

these definitions can be refined further of course, or replaced with other terms

@stevebate

This looks the same to me for XMPP and AP.

the best way i can draw an analogy is like this: imagine if all activitypub requests were made against a single inbox, and delivery happened only by addressing properties. that’s what xmpp is like. arguably that’s also what sharedInbox is like. the thing that activitypub brings to the table is that each actor has their own inbox, theoretically separate from the “instance” software. in a “pure AP” world, an activity would be POSTed individually to each addressed actor’s inbox. this leaves the door open for a more microservice-like architecture. in concrete terms, you can POST an activity that doesn’t have any addressing properties included. (this also allows bto/bcc to work.)

@stevebate

Having more functionally oriented endpoint-level actors would also reduce the need for special collections to follow.

the question for this then becomes, “how do we avoid defining a dozen different endpoints that work mostly similarly?” again, looking at XEP-0157: Contact Addresses for XMPP Services we see a disco query being used. there are a lot of different categories:

  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='server' type='im'/>
    <feature var='http://jabber.org/protocol/disco'/>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>http://jabber.org/network/serverinfo</value>
      </field>
      <field var='abuse-addresses'>
        <value>mailto:abuse@shakespeare.lit</value>
        <value>xmpp:abuse@shakespeare.lit</value>
      </field>
      <field var='admin-addresses'>
        <value>mailto:xmpp@shakespeare.lit</value>
        <value>xmpp:admins@shakespeare.lit</value>
      </field>
      <field var='feedback-addresses'>
        <value>http://shakespeare.lit/feedback.php</value>
        <value>mailto:feedback@shakespeare.lit</value>
        <value>xmpp:feedback@shakespeare.lit</value>
      </field>
      <field var='sales-addresses'>
        <value>xmpp:bard@shakespeare.lit</value>
      </field>
      <field var='security-addresses'>
        <value>xmpp:security@shakespeare.lit</value>
      </field>
      <field var='status-addresses'>
        <value>https://status.shakespeare.lit</value>
      </field>
      <field var='support-addresses'>
        <value>http://shakespeare.lit/support.php</value>
        <value>xmpp:support@shakespeare.lit</value>
      </field>
    </x>
  </query>

abuse, admin, feedback, sales, security, status, support. do we then envision 7 different endpoints? or can we consolidate or reduce this somehow? or perhaps we define an endpoint for discovery of… arbitrary info? serviceDiscovery? there are a lot of potential approaches here.

[stevebate]

@trwnh

instance
: a software service hosting users

Let’s say I have multitenant AP server software (something like Takahē or Vocata, for example). The software supports multiple URL prefixes (each hosting one or more actors representing zero or more users) served from a single process. Let’s say each URL prefix has its own configuration (moderation policies, rules, authorized fetch, etc.). Each prefix could also have its own Webfinger, nodeinfo, OAuth2, and other services. Are each of those URL prefixes representing an “instance”? To an external observer, it’s going to be almost indistinguishable from what most people intuitively think of when they say “instance”.

I’m using “URL prefix” (scheme://domain:port/) instead of “network endpoint” because the server process may have only a single HTTP network endpoint (IP address / port) for POST requests for all the URL prefixes it hosts. In this case, the URL prefixes resolve to a single network endpoint after DNS resolution.

All that said, defining an AP “instance” as a URL prefix accepting AP POST/GET, without saying anything about the underlying software/service implementation, does make some sense to me.

@trwnh

endpoint
: a uri that accepts HTTP requests, particularly POST requests

I’ll try to refer to this as an URL POST endpoint to avoid confusion with network endpoints.

@trwnh

the question for this then becomes, “how do we avoid defining a dozen different endpoints that work mostly similarly?”

A large AP server could have a huge number of actor URL POST endpoints that work mostly similarly. Working similarly seems like less of an issue than having similar (or identical) purposes or roles. I can’t comment on the XMPP contact addresses, but it does seem like sales might not be interested in admin-related messaging (for example). If you used Collection Actors for this purpose, wouldn’t you have a similar number of “instance actors” anyway (one per collection)?

[naturzukunft]

thank you very much for this thread. unfortunately, i haven’t managed to read it yet. I have only picked up bits and pieces and am confused. For me, there can only be one instance actor and you don’t have to look for him. It can be reached under the domain of the instance.

curl --location --request GET 'https://mastodon.social' \
--header 'Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams'

currently mastodon response with 406

{
    "error": "Not Acceptable"
}

rdf-pub also, i forgot to add the accept header
But it works without Accept:
curl --location --request GET 'https://dev.rdf-pub.org/'

[trwnh]

So with FEP-ceee now being submitted, I think this topic deserves a second look.

Can people help make a list of desired use-cases for an “instance actor”? Can we come up with a list of characteristics that help define or specify what the “instance actor” even is?

Per FEP-2677, we have:

• Use case: HTTP Signature bootstrapping.
  • Characteristic: Is retrievable without a signature.
  • Implied characteristic: Has a publicKey.
  • Analysis: Is discovering this actor via NodeInfo or Webfinger even necessary? Based on my understanding, the way you’d primarily discover such an actor is if you receive a request already signed by it.
• Use case: “Allowing for application to application communication by having application actor send activities to another application actor’s inbox.”
  • Characteristic: Has an inbox.
  • Analysis: This matches what we concluded last time, but arguably it is redundant with sharedInbox in usage (if perhaps not in theory).
• Use case: “Having an object one can attach further information to.”
  • Characteristic: Has support for declaring properties.
  • Analysis: This could be done, I suppose, but properties of the node/host are generally expressed with NodeInfo or host-meta. NodeInfo has metadata, and host-meta has properties, both of which support freeform key-value pairs. I’m not sure we need a third way to do the same thing.

Per FEP-ceee, we have:

• Characteristic: “support instance-wide functionality”
  • Analysis: What does this mean? Which functionality is included? What’s the use case?
• Characteristic: Can be looked up via WebFinger via an HTTPS URI of the origin/host/FQDN.
  • Analysis: Sure, I guess? But this doesn’t seem to be very special. The devil is in the details, though, so it all comes down to what the link relation that is specified/declared entails.

[stevebate]

@trwnh

Characteristic: “support instance-wide functionality”

• Analysis: What does this mean? Which functionality is included? What’s the use case?

It means, for example, that an instance can send signed messages not associated with any specific user or bot accounts associated with that instance. My understanding is that is most or all of the purpose of the Mastodon instance/application “representative” account (you probably know better than me). AFAIK, the Mastodon instance-level actor cannot be followed and you can’t send messages to it. Is that correct? If so, I agree that it doesn’t seem like there’s a need for discovery in that case. I don’t know if other servers actually have instance-to-instance behaviors where they’d need to discover the remote instance actor(s).

@trwnh

NodeInfo has metadata, and host-meta has properties, both of which support freeform key-value pairs. I’m not sure we need a third way to do the same thing.

I agree that this should not be conflated with instance-level actor data. Funkwhale makes relatively extensive use of NodeInfo metadata (similar info to Mastodon’s API /api/v2/instance). Like I mention in FEP-ceee, the profile-page rel could be used with WebFinger like it is for Mastodon, but also link to instance metadata representations other than HTML.

[aschrijver]

Would it be possible to define a consistent model and use common language to share our understanding of how this works? In the two posts above concepts are used interchangeably, and that is then compared to further variations that exist in the wild. For instance, are …

• Host / Node / Server
• Instance / Application

… two different concepts with multiple synonymous names?

For a die-hard fedi dev this may lead to an exclaiming of a “Duh, obviously they [are / are not]!”, but for an average dev the fuzziness in terminology make it very hard to wrap ones head around the mental model. The die-hards are the domain experts that should come to a consensus on which terms to use.

Take for example “Instance” and two interpretations I see people give that concept:

• “Instances / Servers federate together to form one big social network”
• “An Instance of an App is like an instance of an object in OOP. It represents a particular App installation”

Both might be true at the same time, but only if a server only ever serves a single app. In other words, accidentally true because it happens to fit an often observed case. How does this map to other cases? For instance, what if I don’t offer an App, but “a host of services that are composable into numerous applications” … See what I did? In one sentence I introduced more confusion, because there isn’t any well-defined model.

[stevebate]

@aschrijver

Would it be possible to define a consistent model and use common language to share our understanding of how this works?

I don’t know. However, it would be great if we (the community) could do that.

This thread may be misnamed. It should probably be “So, what even is an instance?”. Given an answer to that question, the actor aspect might answer itself.

In the context of this thread, I may sometimes use instance/Application interchangeably only because FEP-2677 uses the concept of an “Application Actor”. I think what I’m referring to as an “instance” is the same or very similar to the FEP-2677 Application concept (which seems different than the AS2 concept), but I’m not completely confident about that. My guess is that the FEP-2677 “Application” was inspired by Mastodon’s special actor with that AS2 type. However, I don’t know.

In FEP-ceee, I define “instance” as a web origin. I don’t answer the question “Why have instances?”. I think we should consider a separate FEP that elaborates my definition and gives an answer to “why?”.

My current thinking about “why?” (which may evolve quickly based on discussions here) is that an “instance” represents an authorization and administration realm.

For authorization, it is the basis for determining “same origin” and whether an actor has the authorization to perform certain actions. The AP Recommendation uses the term “server” for this purpose but that is even more ambiguous, in my opinion.

with their authority belonging to that of their originating server.

For administration, it’s a boundary for shared policies, configuration and services (like WebFinger, nodeinfo, host-meta) associated with a group of AP actors.

An instance-level actor performs functions (like signed instance-level fetches) within the scope and authority of the instance’s authz/admin realm.

In a specific implementation, instance-level actors might support some implementation-specific exchange of data between instances. There are other possibilities. Until we survey how instance-level actors are used in practice, I think the topic will remain a bit murky. This is one of the issues I have with FEP-2677. It lists various implementations that support an “Application Actor”. The list gives the impression that they are implementing the same or very similar thing and it’s currently not clear to me that this is true at all.

@aschrijver

Take for example “Instance” and two interpretations I see people give that concept:

• “Instances / Servers federate together to form one big social network”
• “An Instance of an App is like an instance of an object in OOP. It represents a particular App installation”

My current working definition of “instance” is consistent with the first bullet. It’s maybe kinda, sorta consistent with the second one, but “App” and “installation” are other vague terms (I don’t know if “App” refers to an AS2 Application actor, for example). Like I said above, an “instance” can be viewed as a specific authz/admin/service realm identified by a web origin.

Multiple instances can share the same underlying software, just configured differently. As a relatively concrete example, Mastodon software could be installed once on a system (e.g., a Docker image pull) and deployed as multiple instances, configured differently (Docker container deployment).

The Takahē server can be installed once and be configured to serve multiple instances with its multi-tenant support. This use case doesn’t fit the intuitive OOP view quite as well.

[trwnh]

@aschrijver

are …

• Host / Node / Server
• Instance / Application

… two different concepts with multiple synonymous names?

I use “host” more like “HTTP Host”, and “instance” like “instantiation of software application to form a server or node in the network”. So I think there’s some ambiguity around “host”, and ambiguity around “server”/“instance”, but not as much around the other terms. I do think that yes, in most cases, the topology of the fediverse makes these equivalences only incidentally true. But for our purposes, we can derive a model that mostly matches the HTTP model, since HTTP is an implicit foundation for the fediverse currently. Yes, you can have several physical or virtual “servers” handling those HTTP requests, but they all flow through some central point, load balancer, gateway, etc. Likewise, you can have several “instantiations” of the same software behind that point. These usages of the terms are besides the point. The application is providing a service, and everything else fits mostly within the bounding box of that service. That service is a node in the network. It can service several hosts.

@stevebate

This thread may be misnamed. It should probably be “So, what even is an instance?”. Given an answer to that question, the actor aspect might answer itself.

I think even if we had a concrete answer for what is an “instance”, we would still need to justify why it needs an actor. For terminology, I think “service” makes the most sense, in keeping with the AS2 Primer guidance for the Service type. I think the concept of an ActivityPub conformant Server mostly aligns with this definition as well.

@stevebate

Like I said above, an “instance” can be viewed as a specific authz/admin/service realm identified by a web origin.

Multiple instances can share the same underlying software, just configured differently. As a relatively concrete example, Mastodon software could be installed once on a system (e.g., a Docker image pull) and deployed as multiple instances, configured differently (Docker container deployment).

The Takahē server can be installed once and be configured to serve multiple instances with its multi-tenant support. This use case doesn’t fit the intuitive OOP view quite as well.

Takahe mostly follows the “virtual host” pattern, in which several hostnames are mapped to the same software. It still sounds kind of weird to me to say that a single “instance” of Takahe can be used to run multiple “instances”, but I guess that goes to show the problem of ambiguity. Really, the popular usage of the term “instance” in the fediverse should probably be replaced with “server”, “service”, “host”, or “origin”, or perhaps even “node”.

• I know diaspora* used “node”, hence “NodeInfo”.
• ActivityPub mostly uses “server” or “service”.
• From an HTTP perspective, it would be the “host” or “origin” or “domain”.

Whichever term you use for this concept, it typically has a representative actor, and:

@stevebate

an instance can send signed messages not associated with any specific user or bot accounts associated with that instance. My understanding is that is most or all of the purpose of the Mastodon instance/application “representative” account (you probably know better than me). AFAIK, the Mastodon instance-level actor cannot be followed and you can’t send messages to it. Is that correct? If so, I agree that it doesn’t seem like there’s a need for discovery in that case. I don’t know if other servers actually have instance-to-instance behaviors where they’d need to discover the remote instance actor(s).

Replace “instance” with the chosen term… let’s say “host”. The “representative account” has an associated actor that is really more of a proxy than anything. It’s used to avoid leaking which user fetched which post, by signing “on behalf of” some user on that host. Over time, it grew to do slightly more than that. Before it existed, Mastodon just used the first account it could find.

[stevebate]

@trwnh

I think even if we had a concrete answer for what is an “instance”, we would still need to justify why it needs an actor.

It seems like we (including you) have already provided current or potential use cases for instance-level actors. For now, I’m assuming the justifications exist given many implementations have something along those lines for some purpose.

@trwnh

Takahe mostly follows the “virtual host” pattern, in which several hostnames are mapped to the same software. It still sounds kind of weird to me to say that a single “instance” of Takahe can be used to run multiple “instances”, but I guess that goes to show the problem of ambiguity.

Yes, I never said a single Takahe instance hosts multiple instances. Phrasing it that way is definitely weird. I said a single Takahe software deployment can serve multiple instances (web origins). I’m not clear about your point about the “virtual host” pattern. Mapping multiple domain names is part of it, but there’s more. Those virtual hosts can be configured independently. They have their own network endpoints for services like WebFinger. They will not be considered “same origin” for authorization purposes by the implementations I’ve seen.

@trwnh

Really, the popular usage of the term “instance” in the fediverse should probably be replaced with “server”, “service”, “host”, or “origin”, or perhaps even “node”.

• I know diaspora* used “node”, hence “NodeInfo”.
• ActivityPub mostly uses “server” or “service”.
• From an HTTP perspective, it would be the “host” or “origin” or “domain”.

Diaspora* also uses the term pod. It appears to me to be synonymous with node, but I’m not sure about that. The AP-based Funkwhale application also refers to their “instances” as “pods”. FWIW, they also provide a pod-level “service actor” (as:Service). I don’t know how it’s used.

The term service is only used in the AP Recommendation in the context of “denial-of-service”. The term server is used extensively, but not clearly defined (IMO). The term server instance is used once.

The definition I’m suggesting for “instance” is closest to HTTP web origin (as described in the FEP). The domain and “host” (domain:port, per the HTTP Host header) are included in the origin along with the protocol.

I’m open to changing the term (although it’s a hassle to change the title of a title-hashed FEP), but it’s not clear to me yet if we have a better candidate. Since AP uses the term server so much, maybe someone should write an FEP to define an “AP Server” as a specific concept distinct from all the other informal uses of “server” in other contexts. Depending on the definition, I’d be happy to rewrite my FEP to use that concept and label.

(I haven’t mentioned it before, but my thinking about instances is influenced by the Vocata server implementation and its mulitenant support. I should probably add some information about that server to the implementations section of the FEP.)

[trwnh]

@stevebate

It seems like we (including you) have already provided current or potential use cases for instance-level actors. For now, I’m assuming the justifications exist given many implementations have something along those lines for some purpose.

I’d like to make a distinction: there are use-cases for whatever actors the host server wants to spin up. That’s just business logic. An actor for every user? Sure. An actor to proxy signatures? Go for it. An actor for admin-to-admin messaging? Why not. ActivityPub doesn’t make any distinctions here, nor does it prescribe any particular mapping.

What there isn’t a justification for is to say that there should be one such actor representing the whole host whose use-case is self-evident. It clearly isn’t self-evident. Metadata about the host is usually served via host-meta and/or host-meta.json well-known endpoints. Each web origin has its own host-meta endpoints. That’s the point I was trying to make about the “virtual host” pattern – to show that we don’t actually care about the topology behind that web origin, we just care about what we see from the outside. Hence, the importance of appropriate link relations to describe the purpose of the linked resource. Put another way, I’d much sooner support a rel-value for “this is a resource that is an ActivityPub actor that receives abuse reports for the current resource” or “this is a resource that is an ActivityPub actor that can be used to contact an administrator with miscellaneous questions about the current resource” or some other such clearly-defined semantics. But to say “this is a resource that is an ActivityPub Application or Service for the current resource” doesn’t really make sense.

With regards to the terminology, I think “web origin” is fine.

[stevebate]

@trwnh

What there isn’t a justification for is to say that there should be one such actor representing the whole host whose use-case is self-evident.

I agree. The FEP-ceee I submitted doesn’t suggest that (but allows it). There’s an example that shows multiple instance-level actors with different roles. I don’t know if you are referring to FEP-2677 or the general usage of the concept in practice. I’ll hold off on additional comments until I see where the discussion is going.

Maybe some concrete examples of the alternative you have in mind could ground the conversation a bit?

[trwnh]

I was referring to the general concept, which is to say: an “instance-level” actor doesn’t really imply anything different than a “user-level” actor. It presupposes that there is a mapping between actors and users, or actors and hosts, when there isn’t. There’s nothing special about the “instance actor” in current usage. As was done in the past, HTTP Signatures could be generated by any public actor that doesn’t require signatures to fetch its representation. In fact, there isn’t even any compelling reason to require that the signature is attached to an actor as metadata – the signing keyId may instead be a “normal” HTTP resource, or it may be a representation of only the key, with a sec:owner signifying its owner, which, again, can be any actor on the host, not guaranteed to map to any user. That the keyId points to a fragment like actor#main-key is a Mastodon-ism. It could just as easily point to a fully qualified resource.

In concrete terms, we would have something like https://w3id.org/fep/xxxx/somePurpose being used as a property name or as a link relation. Say https://w3id.org/fep/xxxx/reportToActor is used for sending your Flag activities. Say https://w3id.org/fep/xxxx/signedFetchRepresentative is used to discover the signed fetch representative. Say https://w3id.org/fep/xxxx/moderationMessageActor is used for inter-instance modmail. Or so on or so forth.

[silverpill]

NodeInfo 2.2 has a new property instance:

An instance is a the concrete installation of a software running on a server.

2.2 has not been finalized yet, and an alternative definition could be proposed.

---

Another interesting case: Lemmy uses instance actor to share instance name and description with other instances. Documentation page: Federation

[stevebate]

@trwnh

I was referring to the general concept, which is to say: an “instance-level” actor doesn’t really imply anything different than a “user-level” actor.

An instance-level service actor provides an instance-level service. A user actor does not. To me, those are distinctly different actor roles. And I consider them equally special in their own way.

@trwnh

In concrete terms, we would have something like https://w3id.org/fep/xxxx/somePurpose being used as a property name or as a link relation.

I understood that part. It seems like you don’t like the more generic Service link relation type with a link as:relationship property for disambiguation and would prefer role-specific link relation types. The advantage of what you’re suggesting is that rel property filtering could be used to select a specific role (vs getting all the services and filtering on the link as:relationship property). However, I don’t think Fediverse WebFinger implementations commonly implement the optional rel query filtering anyway. If someone defines some “standard” instance-level actor roles in an FEP, I’ll update my FEP to reference those.

What I wasn’t clear about is if those examples of role-based service link relation types are for links for all WebFinger resources (or maybe just Actor-related resources) or the instance resource or both or something else. One possible point of confusion is that these service links are not linking an actor to other actors. It’s linking an “instance” to instance-level service actors. The instance itself is not an actor, it’s just a resource that can be queried in WebFinger. I’m trying to not use the term “instance actor” anywhere (vs instance-level actor). If I did, it was a mistake.

In your link relation examples, what is the “subject” (the source end of the link)?

[stevebate]

@silverpill

Another interesting case: Lemmy uses instance actor to share instance name and description with other instances. Documentation page: Federation

Yes, another interesting variation. Mastodon uses nodeinfo metadata for that (which seems like a better choice to me):

{
  "version": "2.0",
  "software": {
    "name": "mastodon",
    "version": "4.3.0-alpha.0+pr-28693-384ec56"
  },
...
  "metadata": {
    "nodeName": "Mastodon",
    "nodeDescription": "The original server operated by the Mastodon gGmbH non-profit"
  }
}

To find the instance metadata, it appears Lemmy uses a standard URI pattern for the “instance metadata actor” (IIUC).

[trwnh]

@stevebate

What I wasn’t clear about is if those examples of role-based service link relation types are for links for all WebFinger resources (or maybe just Actor-related resources) or the instance resource or both or something else. One possible point of confusion is that these service links are not linking an actor to other actors. It’s linking an “instance” to instance-level service actors. The instance itself is not an actor, it’s just a resource that can be queried in WebFinger.

The “instance resource” is what I’m trying to define. For example, FEP-ceee proposes doing a WebFinger query on the web origin (host). This assumes that https://domain.example is a resource that should have a descriptor.

Let’s take the kenzoishii example from ActivityPub. Say there’s an actor that maps to a user, https://kenzoishii.example.com being its location. Would you then propose that a query for webfinger?resource=https://kenzoishii.example.com&rel=https://www.w3.org/ns/activitystreams#Service should return a link for https://example.com? And if so, then what is the purpose of this link? When would it be followed, and why?

[stevebate]

@trwnh

Would you then propose that a query for webfinger?resource=https://kenzoishii.example.com&rel=https://www.w3.org/ns/activitystreams#Service should return a link for https://example.com? And if so, then what is the purpose of this link? When would it be followed, and why?

No, I’m not proposing that. I’m not sure where the miscommunication is happening, but maybe you are mostly focused on the actor aspect (which would be fair given the title of this thread). FEP-ceee defines “instance” but only gives a very high-level definition of “instance-level actors”. The potential roles and responsibilities of “instance actors” in a specific implementation is outside the scope of my proposal.