+++
date = 2024-09-30T17:41:00-06:00
tags = ["capitalism", "social", "capital", "mastodon", "utility", "analysis"]
[[params.inReplyTo]]
name = "post #36 of \"SocialWebFoundation - what do people think?\""
url = "https://socialhub.activitypub.rocks/t/socialwebfoundation-what-do-people-think/4564/36"
[[params.syndication]]
name = "Original post on SocialHub"
url = "https://socialhub.activitypub.rocks/t/socialwebfoundation-what-do-people-think/4564/37"
+++

> I think that, before we had an open standard for social networking, protocol experimentation was more important. Now that we have an open standard, with a hundred implementations, tens of thousands of nodes, and tens of millions of users, I think efforts should go into encouraging the use of that standard and enhancing it through backwards-compatible extensions, rather than starting the whole process from the ground up.
{cite="https://socialhub.activitypub.rocks/t/socialwebfoundation-what-do-people-think/4564/36" card="socialhub.activitypub.rocks/eprodrom"}


I think this is a bit too conservative of a take regarding backwards-compatibility. I really don’t think we’re at any sort of broad alignment, even within the ActivityPub space alone. Just about the only thing we universally do is POST to inbox. That payload is AS2 Activities. Things tighten up a bit when you consider e.g. the "Mastodon Protocol" as defined by https://docs.joinmastodon.org/spec/activitypub but even then, not everyone follows this protocol, and as a protocol, it’s got a lot of missing bits that are very important for a "social networking protocol" to have, not to mention it doesn’t closely follow the requirements laid out in AP or AS2. The main criticism that several people have raised (@hrefna @stevebate and @jenniferplusplus in particular) is that any interop we have on the fediverse today is more the result of the blood, sweat, and tears of implementers than it is the “open standard” that pretty much no one implements to the letter. The far more common outcome is to reverse-engineer Mastodon, or reverse-engineer Lemmy, with the aid of their documentation, with lots of hours spent looking at the code, and with outreach and collaboration involving other implementers.

Honestly, looking at the ActivityPub spec over and over and over and over and over (as I’ve done countless times), the well-defined parts that stick out are:

- A "following protocol". You send `Follow`, you get back `Accept` or `Reject`, you add to `followers` and `following` as appropriate, and you can later `Undo`. This is the core functionality of ActivityPub.
- A "liking protocol". You send `Like`, which should get added to the `likes` collection.
- A "(re)sharing protocol". You send `Announce`, which should get added to the `shares` collection.

But besides that, most of the activities that got specced in AP are for C2S CRUD resource management or Collection management. The way that these activities get used (or not used) in the fediverse doesn't line up with the spec. For example, `Create` is described in S2S as having "surprisingly few side effects". But in the fediverse it actually has more side effects, which aren't described by ActivityPub. It also has unstated requirements on the "shape" of the activity, which properties are required, and how those properties get interpreted (which only *somewhat* aligns with the definitions provided in AS2).

I think there's a lot of work that one would need to do to describe "the implicit protocol of the fediverse", which is not sufficiently described by "the ActivityPub specification". If you want to frame this in AP terms, the "server-to-server" bits aren't the "real" protocol, but rather there are *client-to-client* protocols that are currently undescribed. These "client-to-client" protocols would be defined and layered on top of the AP S2S delivery mechanism, which is just LDN but with the restriction that the notification payload is an AS2 Activity and with some basic side effects sprinkled on top. And yes, most existing fediverse implementations ought to be considered Clients more than they can be considered Servers; they just happen to be monolithic and have subsumed the server component into the client, as if Thunderbird came with its own IMAP+SMTP implementation embedded into the application.

So, given all this, I have to ask: what are we targeting here? What are we trying to be backwards-compatible with? If it's the existing install base of Mastodon and Mastodon-compatible software, then I think a blind adherence to backwards-compatibility is actually going to severely hold back the future potential of the social web. If it's Threads, then I honestly don't think that many of the smaller and independent implementers are interested in implementing and adhering to the Threads Protocol. Is it some kind of synthesis of the lowest-common-denominator of all fediverse implementations? Well, in that case, you can't target something that isn't clearly defined.

To bring up the perennial example of a chess extension to ActivityPub, you could imagine implementing a "chess protocol" that works client-to-client. You could even declare support for this protocol somehow, probably at an actor level you could indicate which clients are connected to your actor, but I'm getting ahead of myself here. The point is that just like we could have a "chess protocol", we similarly could define a "social media post" protocol, which isn't currently defined. Such a "protocol" would include things like interpreting a Create Note as a "status", and it would include which properties are required or recommended or optional, and it would include guidance on how to interpret those properties and how to render them to the user, but also very importantly it would include a description of the side effects that you can expect that client to perform. Using Mastodon as an example, one of the side effects of receiving a Create Note currently is that the "status" it gets transformed into will be stored indefinitely in the local database, irrespective of HTTP caching headers. The "protocol" would ideally also define how the "status" should be deleted, and when, under which circumstances. For example, sending a Delete of your own actor is not defined anywhere as deleting your "statuses" as well. And I don't think this belongs in the ActivityPub spec necessarily, because it's just as valid to say that all activities delivered by the actor prior to its own deletion are notification messages that could be stored indefinitely or externally in your on-disk cache (barring the presence of HTTP caching headers which would cause them to be expired from cache). Perhaps if that "social media protocol" actually existed in explicit, unambiguous, documented form, then it would be possible to target it with backward-compatible extensions. But we don't have any such thing today. The closest thing we have to that is https://docs.joinmastodon.org/spec/activitypub which is itself an incomplete description.

> But protocols are about interoperability, and having incompatible protocols reduces interoperability. And protocol diversity is just not as important to me as connecting more people on the social web.
{cite="https://socialhub.activitypub.rocks/t/socialwebfoundation-what-do-people-think/4564/36" card="socialhub.activitypub.rocks/eprodrom"}

If this were the entire argument, then I would (facetiously) say to just use SMTP. After all, SMTP has billions of users, which is far more than ActivityPub has.  Why does ActivityPub exist when the same mechanisms could have been specified on top of SMTP? Isn't the existence of ActivityPub harmful to the email social network?

Hopefully you can see why this argument doesn't (or shouldn't) make sense. Not even when you switch out the protocols for different protocols.

If what truly matters is, as you say, "connecting more people on the social web", then I think we're going to have to come up with a definition for "social web" that we can agree upon. Because as it stands, the "social web" is more than just ActivityPub. And if the "social web" were limited to being just ActivityPub, and specifically limited to what current fediverse implementations do (or don't do) with ActivityPub, then that's not much of a "social web" and it doesn't exactly inspire hope for the future.

Now, this isn't to say that we should throw away ActivityPub entirely. But I do think we need to broaden our horizons and think really hard about what makes up a "protocol", and which building blocks should be developed to form that "protocol". We have a lot of work to do.