ActivityPub, the SocialCG, and the social web

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.

25 thoughts on “ActivityPub, the SocialCG, and the social web

  1. @evanprodromouI fought in the Network Protocol Wars.Many competing protocols for the same use case is an interoperability & usability mess, and very costly to run & develop for.It fractures the user & developer base and destroys the network effect. A unified protocol approach is key to enabling the network effect.We see the same battle now in Home Automation & Social Web – just two more in a long series of proprietary vs open standards wars.Plus ça change, plus c'est même choise.

  2. @evanprodromou > changing the way a Collection is represented in ActivityPub will make the whole thing “better” > reject Note objects and only accept Microblog ones, or something similarAre these real examples of serious proposals? I feel like I've become pretty involved, and I have no idea what these points are referring to.

    1. That’s OK! You’re kind of illustrating the point right now. Those minor technical differences at the protocol level are not at all important to people who use the network.

  3. > 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.

    This is why bridges are so important to me. I firmly believe in the potential of the ActivityPub protocol (and the full Fediverse set, including WebFinger and HTTP Signatures aka Authorized Fetch) and I firmly believe that, in due time, it will eclipse both centralized platforms and its other decentralized brethren, like ATProto, Nostr, and SSB/Scuttlebutt. However, if i.e. Bluesky works better for someone, they should be able to continue to use it _as a part of the bigger network._ Ergo, bridges.

    The situation with the public Nostr bridge at mostr.pub, where many servers and people block it because it’s impossible to moderate, is unfortunate but it is one of the pitfalls of bridges. I feel like that itself is, or should be, a huge draw to the bigger network, although to be fair it’s a pretty big draw to other networks as well where defederation and admin-run blocking just isn’t a thing. Many people on Bluesky say they went there instead of Mastodon because they can’t follow the people they want to because of the fediblock culture. It’s incredibly frustrating to newcomers and veterans alike.

    > Finally, some people think that a casual specification, without a standards organisation behind it, will be more responsive to developers and users.

    Formal standards organizations don’t feel welcoming at all to passers-by or newcomers; not by any fault of any organization, but by it being The Formal Organization. It’s like joining Congress to get a bill passed. It’s overkill.

    Super formal processes slow down development, which to be honest might kinda be the goal. That’s why the Signal developers oppose protocols and federation so much: they feel like their ability to innovate and improve on their own product is hampered by the pace of formal processes (notoriously slow!). Hell, it might be part of why XMPP is so far behind centralized chat platforms; they prioritize getting it standardized before implementing it. For example, reactions were standardized in an XEP years ago (2019?), and only recently are some clients gaining support for it.

    Having the ability to “move fast” without “breaking things” is CRUCIAL. You’ll be stuck in the past, much like XMPP, if you can’t move fast, and you’ll break everything if you move _too_ fast or without due regard for (backward) compatibility.

    1. Lastly, it’s unconscionable that the BS team is outsourcing this responsibility to volunteers. They raised US$13M this year. Nobody should be doing free labour for BS.

  4. @evanprodromouCompetition in a market is good, but this isn’t a market. Supply and demand don’t really apply. Users don’t buy a protocol, and you aren’t being paid when it’s adopted. If anything, it adds more demands on you.Social protocols don’t operate in a market. They’re infrastructure. And “Move fast and break things!” is a terrible philosophy for a plumber.@ntnsndr

  5. @evanprodromou Evan explained some of this to me years ago. He invested more in standards, me more in implementation. There is room in the social space for both a river and a garden. We will get there. Lead on Evan.

  6. @evanprodromou People apparently cannot remember when FriendFeed was a thing. We don’t have a burning need to go back to that messy hack for dealing with a ton of silos and smokestacks.

  7. “standards aren’t about competition. They’re about cooperation.”

    Welcome to the hill I keep dying on.

  8. @evanprodromou i like the way you define standards in relationships with the market.In other words we need rules to avoid the mess of excess if "free" market.I think about that with your text

  9. @evanprodromou Excellent observations! You’ve persuaded me completely to your point of view. This is very much like the aphorism about not letting the perfect be the enemy of the good. A brilliantly designed, beautiful protocol is nearly worthless if the vast majority are not using it. And can actually be damaging to the ultimate goal (tech history is full of such examples).

  10. A lot of people […] 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. https://evanp.me/2023/10/06/activitypub-the-socialcg-and-the-social-web/

  11. @Evan Prodromou if you want to help AP beating Nostr you have to finde a standard which does not tie the ID in the Network to just one server.

    1. It doesn’t have to beat Nostr. It’s already the standard.

      ActivityPub IDs work like the rest of the web: with domain names. It’s a great system that has worked amazingly well for over 30 years. The most successful naming system in history, bar none!

  12. @evanprodromou A common framework that embraces diversity in execution. Compatibility is key, allowing us to converge on standards while thriving in a landscape of implementations.

  13. @evanprodromou > We need to agree on standards, and compete on implementations.Well said!

  14. @evanprodromou I agree. What if there were three HTMLs? Anyone remember when different browsers didn't work on various sites? It's fine to experiment, but one important thing:
    The future of anything like Bluesky will depend on how it's funded and I don't see it being donations.

  15. @evanprodromou

    Is there any software that is really 100% AP compatible to the spec ?
    Can we choose a microblogging software from a list ?

    Each time i see something that does not work properly outside of mastodon, i never know if it's mastodon doing it's own way, or poor implementation from other software, that could also be likely, they're even less funded.

Leave a reply to Blake L Cancel reply