@cwebber
I'm using Offer/Accept semantics and the instrument property for capability negotiation and request routing in my infrastructure plan

The context is C2S, not federated, protocol, although there are hacks whereby a server could accept Activities on designated Inboxes to support clients on remote server implementations that aren't ActivityPub *client* conformant that I describe at the bottom

Once you've defined the mechanisms to communicate an authorization to a remote client, which is to say a client connecting to an actor on a different instance, the next step is workflows for requesting and offering authorizations. OAuth2 is fine for situations where a person has already decided to make a grant on an account where they have access, but it doesn't address use cases where the authorization and use are from different entities

The issue is that this completes the definition of a protocol implementation that can function as a Turing machine. While this is great in that you've proven any computational task could be implemented in the protocol, it's not really ethical to make it a condition for federation that servers implement this, quite aside from the initial declaration in the specs that client, server, and federated server are different assertions of compliance

It's possible, though, for a client to tunnel C2S over S2S if their local server allows them to create Activity Objects addressed to the Inbox of a remote set up for this purpose. The remote could be a proxy or a service actor, depending on the application logic involved

Sign in to participate in the conversation
Octodon

Octodon is a nice general purpose instance. more