So, what even is an instance actor?

ActivityPub
7

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.
1 Like