Evan Prodromou

2023-10-06 19:39:05

I have some strong feelings about the social web (aka “the fediverse”) right now. I don’t aways communicate them well, because they feel so essential to me, which can be frustrating for my friends, colleagues and allies. I want to set out some steps for my reasoning.

• I think the social web is very important. Distributing the locus of control on social computing from monolithic services to individuals, families, clubs, civic groups, universities, coops, and a competitive market is important for everyone.
• We are at the cusp of exponential growth of the social web. The current time is like no other we’ve ever had.
• We get exponential growth based on having one protocol, not a half dozen. I think Blue Sky, Nostr, and others are a threat to ActivityPub breaking out and becoming ubiquitous. There can’t be multiple winners. I often reference Metcalfe’s Law in this regard; one big connected internetwork is much better than 3 or 4 disconnected ones.
• ActivityPub has a claim to being The Social Network Protocol, because it was standardized by the W3C. Protocols are not a meritocracy; it’s not like the best protocols always win. Usually, just the opposite. Protocols with a claim to official sanction, and wide adoption, win.
• Keeping a clean line of legitimacy for AP, and a good relationship with the W3C, is key. The SocialCG is the designated steward of the spec. People know to come to the CG to participate in the spec. That’s good. We want that to keep happening.
• Any proposals that talk about taking AP away from the CG, or forking it, or making experimental versions, are really, really bad for the fediverse. There is no improvement you could make to ActivityPub that justifies breaking backwards compatibility, undercutting the protocol’s legitimacy, and splitting the network. Everything needs to be incremental, backwards compatible, W3C- and SocialCG-led, and support rather than inhibit growth.

A lot of people don’t agree with me on these. They may think that it’s great to have lots of protocols competing, in the same way it’s great to have lots of vendors competing in a market; that competition makes protocols better. But that’s not the case; standards aren’t about competition. They’re about cooperation. A compatible, connected internetwork makes all implementations more popular and better used; see the aforementioned Metcalfe’s Law. We need to agree on standards, and compete on implementations.

Some people also think that changing the way a Collection is represented in ActivityPub will make the whole thing “better” because if you are reading the JSON-LD on the wire, it will be more elegant and conceptually sound. This is a bad definition of “better”. “Better” for ActivityPub should mean, it helps more people connect to more other people they care about. And sometimes that means using the existing, well-implemented methods, even if they’re not as beautiful to you when you’re writing code as your own ideas are.

Others think that there’s still time for incompatible changes to AP — hitting the big “reset” button and getting the dozens of implementations on the fediverse today to rewrite their federation code to reject Note objects and only accept Microblog ones, or something similar. There is not, in fact, time for that.

Finally, some people think that a casual specification, without a standards organisation behind it, will be more responsive to developers and users. I definitely think there is room to develop experimental protocols on top of AP, but we have an extension mechanism for that. We can have a stable, dependable core, and have cool, new, fast-moving extensions. They’re not incompatible.

I want to see ActivityPub win, so we can have a great social web. I’m going to keep trying to make AP, the SocialCG, and the social web stable, dependable, and iteratively developing. I hope others agree and will do the same.

https://evanp.me/2023/10/06/activitypub-the-socialcg-and-the-social-web/

the idea that quality does not necessarily increase with functionality

^{Contributors to Wikimedia projects (Wikimedia Foundation, Inc.)}