+++
title = "re: starting to investigate other protocols"
summary = "The main thing I'm trying to formulate right now is a generic understanding of what is a protocol and what makes up a protocol [...] The \"implicit protocol of the fediverse\" is not sufficiently described by \"the ActivityPub specification\""
date = 2024-09-29T19:53:00-05:00
source = "https://socialhub.activitypub.rocks/t/socialwebfoundation-what-do-people-think/4564/13"
series = "fedi and the social web 2024"
series_part = "2.5"
[[params.inReplyTo]]
url = "https://socialhub.activitypub.rocks/t/socialwebfoundation-what-do-people-think/4564/12"
+++

<blockquote cite="https://socialhub.activitypub.rocks/t/socialwebfoundation-what-do-people-think/4564/12">
<p>And from an activist perspective, I’d be very loud about starting to investigate other protocols – and why you’re doing it.</p>
</blockquote>

If anything, the recent developments have definitely gotten me to more seriously revisit some ideas I had a few years back about a multi-protocol approach[^multi-proto-approach] and how best to synthesize several different protocols that have similar or different approaches to certain things. The main thing I'm trying to formulate right now is a generic understanding of what is a protocol and what makes up a protocol. To give an example limited to just 3 "protocols" that mostly work off of from/to semantics, we can look at SMTP, XMPP, and ActivityPub.

- Data format: SMTP is more or less plaintext, XMPP is XML, and ActivityPub is JSON.
- Message payload format: SMTP uses RFC 822 messages, XMPP uses stanzas, and ActivityPub uses AS2 Activities.
- Message semantics: SMTP messages have headers and body content. XMPP stanzas can be message, presence, or information query. ActivityPub activities... are activities. That's it.

So before you even get to the part where you can do anything interesting, you find that ActivityPub is really not much of a protocol. All three of these protocols let you "send and receive", but there's more to communication than just sending and receiving. So, given that, what does ActivityPub *actually* provide?

The best I can describe it right now, ActivityPub provides the following "protocols" layered on top of LDN:

- A protocol for "following". You send a `Follow`, it can trigger an `Accept` or `Reject`, you can `Undo` it later, and there are side effects of being added to `followers`/`following`.
- A protocol for "liking". You send a `Like`, there are side effects of being added to the `likes` collection.
- A protocol for "(re)sharing". You send an `Announce`, there are side effects of being added to the `shares` collection.

Everything else is far too undefined or under-defined to constitute much of a "protocol". Things like Create have "surprisingly few side effects" according to the ActivityPub TR, because they were intended for the C2S API to be able to do basic CRUD and Collection management. But in the fediverse, Create actually has a lot more to it! So if we were to define a basic "social media post" application protocol for the lowest common denominator of most of the current fediverse, then we need to define more than what the ActivityPub spec concerns itself with, just to get to "hello world" levels of functionality. We need to explicitly define the following additional things to get from "AP Create notification" to "social media post" in its most limited form:

- You send a `Create` where the `object` is a `Note`.
  - The object MUST have `content` whose value is a string.
    - The content MUST conform to some sanitized subset of HTML.
  - The object MUST have a `published` whose value is a string containing a timestamp.
  - The object MUST have an `attributedTo` whose value is exactly one actor.
    - The actor MUST be of type `Person`.
    - The actor MUST have a `name` whose value is a string.
      - The name MUST be plain text, and will be interpreted as plain text. 
    - The actor MUST have an `icon` whose value is the URL to a 1:1 image file.
    - The actor MUST have a `preferredUsername` whose value is a string.
      - The username MUST be unique on the domain.
      - The username MUST link back to the actor when querying that actor's domain's WebFinger endpoint for an `acct:` URI formed of the username and the domain. 
  - The object MUST have `to` or `cc` or both, whose value is an array which contains at least `https://www.w3.org/ns/activitystreams#Public`.

Now, I'm simplifying a bit, so the above has the following caveats:

- Requirements can be relaxed or willfully violated as various needs arise. For example, if an actor is missing an `icon`, the protocol can be modified such that a "default avatar" is assumed instead.
- Requirements can also be added or extended as the protocol matures and develops. For example, support for `inReplyTo`, `attachment`, `tag` can be added over time.
- Protocols may require other protocols or specifications. For example, WebFinger in the above "social media post" protocol.
- Additional protocols would be need to be defined for each use case. For example, a similar protocol for "making a blog post" could be defined using `Create Article`.
- Specifications ideally ought to be followed, but ultimately the real protocol is what implementers end up doing, and the above protocol codifies some mistakes and errors into itself. For example, hard assumptions of actor and object types, hard requirements on the maximum cardinality of properties like `attributedTo`, soft requirements for specifically `https://www.w3.org/ns/activitystreams#Public` instead of `as:Public`. (All of these things represent real incorrect assumptions by real implementers.)

When you put it like this, it becomes clear that if the fediverse wants to continue to make use of ActivityPub, then there are a *lot* of things that need to be explicitly defined as protocols layered[^protocol-layering] on top of ActivityPub. The "implicit protocol of the fediverse" is not sufficiently described by "the ActivityPub specification". We need to standardize and align on common patterns and common protocols for those patterns.

And the challenge here, the issue is, that if we don't do this work at a grassroots level, then Meta will do it for us. (Can you imagine a "developer portal" for "interoperating with Threads"?) Things like the FEP process allow writing up these "micro-protocols", and then after that, the difficult task of cat-herding begins, as you need to get implementers onboard with adhering to these specifications. And of course, we're all mostly doing this in our free time and without access to the resources that larger organizations have or can gain access to. So it's going to be an uphill battle. But whichever "protocol building blocks" we can agree and align upon, let's go for it.

[^multi-proto-approach]: I was specifically looking at a "unified communication" project, which mapped abstract forms of communication like "messaging", "publishing", "discussing", "reading" onto existing protocols like SMTP, XMPP, ActivityPub, IRC, RSS, ATOM, HTTP. There's a risk of ending up with something like Pidgin here, but maybe that's not the worst thing.

[^protocol-layering]: And of course, other protocols and other layerings are possible. Libervia (formerly Salut a Toi) does AS2 with PubSub over XMPP, but offers an "ActivityPub gateway". You could, if you wanted to, send AS2 over an SMTP transport.