NextGen ActivityPub Social API

[trwnh]

i think that

@stevebate

part of the reason is that the standard C2S feature set very sparse compared to the Mastodon Client API, which is supported by many clients. For example, the AP Social API is missing features like:

• Search
• Streaming events
• Timelines (different from inbox/outbox, at user and server/fediverse levels)
• Authentication / Authorization
• Bookmarks (and custom collection discovery and management, in general)
• Media upload (described in nonnormative wiki)
• Actor/Account notes

is pretty spot-on, but at the same time needs a bit of reframing. i think that the primary reason that C2S was not adopted widely is not purely because of “missing features” but more accurately a sort of “impedance mismatch”. the C2S api is simply trying to do something different from what a social network is trying to do.

by which i mean:

• a social network wants to enable its users to do all of the above things and more;
• AP C2S was written to enable its users to maybe perform simple resource manipulations and/or push notifications to some recipients.

i’ve encountered this dynamic in trying to build a playground / “test server” for what i consider to be “minimum viable activitypub”: basically LDN + the AP addressing properties. this approach is fully compliant with the “Federated Server” profile (pre-errata), and while it discounts a few SHOULD recommendations, it does so because they are inapplicable. the way it works is like so:

• there is an outbox endpoint.
  • it accepts as2 activities for now (but could be extended to accept arbitrary RDF payloads for LDN purposes).
  • its sole function is to look at the values in as:to as:cc as:audience as:bto as:bcc, try to discover any ldp:inbox for each resource, and then deliver to the discovered inboxes.
    • this makes it compliant with 7.1.1 outbox requirements for the “Federated Server” conformance profile.
    • it does not perform any of the C2S side effects, so it is not compliant with the “Server” conformance profile.
• there is an inbox endpoint.
  • it accepts as2 activities for now (but could be extended to accept arbitrary RDF payloads for LDN purposes)
  • its sole function is to receive notifications.
    • it does not perform any S2S side effects, but this is because the side effects are inapplicable – the inbox server does not store any representations other than writing the notification payload to disk and allowing it to be read via HTTP GET.
    • consequently, since all the S2S side effects are SHOULD statements that are inapplicable, we maintain compliance with the “Federated Server” conformance profile.

of course there are some natural extension points:

• as described above, supporting arbitrary RDF payloads would make this compliant with LDN, and this is not terribly hard to do since LDN has provisions for discovering supported serializations (HTTP OPTIONS to check the Accept-Post headers).
• i may want to handle Follow activities at some point. the “Follow protocol” described in AP is probably one of the more/most well-defined parts of the “protocol”. the challenge is in wiring it up in a way that flows naturally between entities.
  • in particular, because of the Accept/Reject requirement, the only way this could ever be handled on the server is by handling it automatically. i would want to support other options, of course.
    • it may be handled at the server level automatically (e.g. if the actor is not blocked, then respond with an Accept immediately.)
    • it may be handled at the client level automatically or manually (with more capacity for client-side rules and automations, based on information the server does not have).
    • it may be handled at the user level manually (e.g. if the server does not handle it, and the client does not handle it, then the user may manually read the Follow in their inbox and manually send an Accept/Reject to that actor).
• i may want to add integration between the outbox and/or inbox with a “storage service”.
  • the “storage service” would store the activities sent and received.
  • the “storage service” might also have its own inbox which you might use as an interface for communicating with the “storage service” (if such a protocol/profile is defined). at least in Solid right now they use HTTP verbs but you could imagine using AS2 Create/Update/Delete/Add/Remove to interact with such a “storage service” both remotely and automatically. the user would simply add the “storage service” as a recipient on their activity before sending it to the outbox; the activity would then flow from the user’s outbox to the “storage service” inbox where it would have side effects.
    • if this were not done, then the user or their client would have to manually POST to multiple outboxes instead of POSTing to a single outbox that then delivers to multiple inboxes.

one thing that falls out of this experiment is that the inbox and outbox don’t have to be served by the same software. in fact, if you’re looking at it from the perspective of the 3 conformance profiles, then you end up with:

• the outbox can comply with the “Server” conformance profile by allowing for resource manipulation via Create/Update; the outbox can also comply with the “Federated Server” conformance profile by allowing for delivery to inboxes.
• the inbox can comply with the “Federated Server” conformance profile by adding activities into itself.

given this reframing, i would wonder what role AP C2S plays if applied to a more “social network” use case. or put another way: which additional APIs are needed to provide a good “social network” experience? what are the assumptions that can, should, or must be made? are we following the “instance” model, or do we instead have a concept of a singular “activitypub server”, or are we operating at the level of “http endpoints”?

i think before we really get around to “fixing c2s” we need to start with the foundational work and figure out what the invariants are. what are the things that any implementer can depend on to be true?

it might start to look like not just one API, but several APIs as part of an “API suite”.

for example:

• the “social notifications API” would allow for sending push notifications.
  • it must interface with a delivery service in order to perform side effects.
• the “social publishing API” would allow for resource manipulation.
  • it must interface with a storage service in order to perform side effects.
  • it may generate notifications by interfacing with the delivery service.
• …?

additional functionality would slot into this “suite” as appropriate. the challenge is in identifying the boundaries and natural points of integration.