The Freenode to Libera incident is a great example of how using protocols allows for a community to mitigate most damage from bad actors both external and internal. I'm not saying damage wasn't done by Andrew Lee during his attempted coup. IRC as a whole lost many important FOSS projects due to Lee's channel take-overs. But most of the community of daily users just moved to the new digs and continues to carry on.
The whole replace Discord thing is something I've been thinking about since 2019 and building my own IM platform since 2007. I hear people pitching every platform under the sun, but the one that I think has the most potential is XMPP. I've been building a modern client, nothing worth showing yet, but eventually I'll slap it on my blog and do a Show HN, for now it supports very basic XMPP primitives, adding friends, setting statuses, messaging friends, simple stuff.
Back in the late 2000s and early 2010s Google and Facebook supported XMPP, so you could login to Facebook Chat / Google Talk via Pidgin through an XMPP gateway (if if this was the default protocol or a bridge I'm not sure, its been years).
The biggest strength I see for XMPP is that because the web and even enterprise (think banking etc) uses XML too, everyone's optimized the ever living crud out of HTML so you could get some very high performance libraries to churn through all those stanzas, but also more importantly, its an extensible protocol. There's no reason it cannot have half of the things that exist on Discord, without disrupting the protocols OOTB design, because unlike IRC and other competing protocols, its extendable by design.
In my opinion decentralization and protocols is really the final frontier in software. Sure, we've got AI, but from what I've seen so far it does not alter the scales of power towards individuals. Protocols do. Everything else feels like noise or thinly veiled monopolization.
Edit: actually thinking about it - at the bottom of much of it is identity. We need new identity solutions for the protocols.
LLMs are making software easier to write and releases are increasing. The app stores that were not seeing an uptick last year are now showing the uptick in releases. It is happening.
This means software will be more competitive and lower margin. This sounds like doom but it's actually great. Great for consumers. Great for indie devs that want to compete against big companies. Their margin is your opportunity.
Meanwhile, the kinds of early adopters that you're looking for are very conscious of enshitification and lock-in. So the best way to reach them and get talked about is through making software that the big VC-backed companies would never write.
The winners will be one-man companies who understand and respect their customer. Open protocols show your users respect and could be a great differentiator.
We keep trying to fix this by building better, more open, interoperable services. The deeper fix is decoupling the Identity Layer from the Application Layer. With cryptographic proofs (e.g signing), we shouldn't be logging in to a Discord, or an alternative; we should be associating our cryptographic DID (a Decentralized Identifier, a public key) with a community.
What about applications? federations, or better: relays, would put an end to censorship. Encryption would put an end to surveillance. Cryptographic signing would improve authentication and security at wide as there would be no stored passwords to leak.
Until then, "protocols not services" will remain a privilege for the technical elite.
Especially protocols that allow us to get out of the services entirely! (local first, peer-to-peer). This is the frontier tech I'm interested in right now, not AI (though they might be eventually compatible).
The protocol vs service distinction matters most where version lifecycles create lock-in. When you depend on a service, you're at the mercy of their deprecation timeline — Heroku free tier, Google Reader, Parse. When you depend on a protocol, the worst case is you switch implementations.
The identity point in the discussion is spot on. The missing piece in most protocol-first architectures is a portable identity layer that doesn't just recreate the service dependency at a different level. DIDs and Verifiable Credentials are trying to solve this but adoption is glacial because there's no compelling consumer use case yet — it's all enterprise compliance stuff.
The XMPP vs Matrix debate is interesting but somewhat misses the point. Both protocols work. The reason Discord won isn't protocol superiority — it's that they solved the 'empty room' problem by piggy-backing on gaming communities that already had social graphs. Protocol design is necessary but not sufficient; you also need a migration path that doesn't require everyone to switch simultaneously.
Let me get this straight: is this article saying we should have some kind of AI protocol where work is distributed across all peers in a network in order to process prompts, creating a sort of decentralized AI model free for all forever?
Could workloads really be broken up and distributed like this among many peer machines?
None of this could happen with a protocol. You cannot require age
verification on IRC, XMPP, ActivityPub, Nostr, or Matrix, because there is no
single entity to compel. Each server operator makes their own decisions. A
government would need to individually pressure thousands of independent
operators across dozens of jurisdictions, which is a legislative and
enforcement impossibility. And even if one server complied, users would
simply move to another.
This is wishful thinking. A government would just move to the next layer of the stack and attack the supporting infrastructure, like DNS, payment services or datacenters. To the degree that a protocol is a manner of communication between things (fka services), those things can be made to comply with the prevailing legal authority.
It turns out it's very slow to evolve a protocol. How long did it take for IRCv3 to handle channels having persistent history? How about channel takeovers via network splits? We knew these were problems in the 20th century but it took a very long time to fix.
Oh, and the chathistory Extension is still a draft! So is channel-rename! And account-registration?
And why is it still so painful to use Mastodon?
That's but one of many examples. Consider how the consolidation of HTML and HTTP clients was the only way that we ended up with any innovation in those services. People have to keep up with Chrome who just does their own thing.
I want to want a decentralized world governed by protocols, but good software that iterates quickly remains the exception rather than the rule.
Is Mastodon really hard to use for most people? I guess there's some very specific scenarios it may be.
Also the article presents a false dichotomy in my view: protocols need services to be useful to virtually 99.9999% of humans (or at least they do in the architecture we have built since... email?).
Who uses email without relying on servers? Where is your selfhosted email box sitting on if not in a hosting service?
Even IRC relies on servers for people to talk to. I love to experiment with protocols that do not rely on servers - secure scuttlebut? - but even ssb relied on some seed peer that provides a service to initialize the peering
Under-appreciated factor: the problem with decentralization is that it pushes work on to the end user, who is least equipped to deal with it. People actively want centralization of things like anti-spam because it lightens the load. The fact that this gets paid for in insidious ways rather than directly paying for a service causes all sorts of weird market distortions.
Note that Discord doesn't replace IRC, it also competes with TeamSpeak; there's a whole voice and video sub-feature to it. Not everybody uses it but the fact that it's available in the same software was advantageous to the original market, gamers.
That's why I'm pretty optimistic about the AT protocol: you get the advantages of app-driven innovation (need a new feature? just define a lexicon for it) without requiring data reliant on that feature to live in that application's silo; the records all exist in each users' PDS, under each users' own control, no matter which applications use those records. And of course, if those features prove to be good ideas, other applications can adopt those lexicons and they're immediately interoperable.
> You cannot require age verification on IRC, XMPP, ActivityPub, Nostr, or Matrix, because there is no single entity to compel. Each server operator makes their own decisions. A government would need to individually pressure thousands of independent operators across dozens of jurisdictions, which is a legislative and enforcement impossibility.
I'm very much sympathetic to the post's argument, but I think it should be acknowledged that this kind of claim has an implicit "(for now)" at the end.
The legal system doesn't have good mechanisms for dealing with problems that it hasn't needed to deal with yet, but if most people moved to encrypted & decentralized protocols for communication, it doesn't follow that laws couldn't be amended to give governments powers to legislate or police it at scale if deemed necessary by some sufficiently powerful group (an autocracy, a voting bloc, a national security service, etc)
So I guess the other implicit piece is that one hopes the technological change comes with cultural change to our political expectations - once people get used to privacy and autonomy, they resist efforts to erode those rights again.
Best of luck to everyone advocating for this! Really hoping to see a lot of thriving communities post-Discord in the coming years.
Most normies dont want to set up their own mail server, they just want to log into a "service" that allows them to send/recv mail. Thats how companies insert themselves into peoples lives, as a low friction and often free way to save time and effort (free but you're still the product). How are protocols going to solve that problem? Someone will still have to donate their time and effort to making other peoples lives easier and then you have centralization again. Unless a service is distributed by default I can't see any technical solution.
There used to be a Plan 9 fork called 9ants (forked from 9front actually) which was developed by the late mycroftiv who setup a small grid computing thing for interested community members. The idea was all it provided basic shared 9P community services including a chat service where you would share media using a shared plumber (a message router).
To connect you would run a script called gridstart that mounted the remote resources in that windows namespace then start a sub rio running gridchat, Acme (text editor), page (document viewer) and the mothra web browser that only supports basic html, no js, css, etc. Gridchat was nothing special, it was pretty much IRC with a slight twist. It consisted of a shared buffer living on a 9p message queue server which everyone's client, an rc script, read and wrote to. Some users wrote their own chat client scripts and of course you could completely change how the grid behaved on your end - it was completely within your power to arrange those resources as you saw fit.
The idea was the plumber in that namespace lets a user plumb a message to everyones clients who were listening on that shared plumber. So if you plumbed a url in gridchat it would load in everyone's browser. you could upload an image file to the griddisk, plumb it and it opens in everyones page. Same with source code but Acme would open the file. It was like a primitive slack or discord where you could technically send images, gifs and urls.
All of it was built on Plan 9 tooling using the native 9P protocol and wired up using rc scripts, all of which is available out of the box. I think the only non-standard Plan 9 tool was was the general purpose message queue 9P server that happened to be the perfect tool to host the gridchat buffer. Sadly, Mycroftiv passed away and 9ants is no more but gridchat lives on sans the shared plumber stuff.
It was all about the protocol: 9P. Everything used the same 9P shaped plug and socket and the client was built up from base tooling. You as a client had complete control over the client portion. This was probably the best example of "protocols, not services" that I have ever seen.
I don't understand this take. If government forces these companies to have age verification and they can't say no, then this can be applied to any of these counter-examples given too; Matrix, IRC, etc. There is no difference between forcing a single entity vs. multiple entities. If the punishment for non-compliance is high, no-one will risk doing it anyway. There is no escape here.
nope, because they can be ran outside of those jurisdictions and they can also be ran essentially anonymously - although that can be challenging depending on the service, but it is possible
38 comments
[ 1.9 ms ] story [ 62.2 ms ] threadBack in the late 2000s and early 2010s Google and Facebook supported XMPP, so you could login to Facebook Chat / Google Talk via Pidgin through an XMPP gateway (if if this was the default protocol or a bridge I'm not sure, its been years).
The biggest strength I see for XMPP is that because the web and even enterprise (think banking etc) uses XML too, everyone's optimized the ever living crud out of HTML so you could get some very high performance libraries to churn through all those stanzas, but also more importantly, its an extensible protocol. There's no reason it cannot have half of the things that exist on Discord, without disrupting the protocols OOTB design, because unlike IRC and other competing protocols, its extendable by design.
We also need decentralized identity so my identity can exist independently of service providers, but still be owned by me and not an impersonator.
Use Workflows and Policies, not Agents.
Agents is what they called programs in the Matrix. They were not helpful. Trusting AI Agents is dumb. And Agents can go rogue.
Edit: actually thinking about it - at the bottom of much of it is identity. We need new identity solutions for the protocols.
LLMs are making software easier to write and releases are increasing. The app stores that were not seeing an uptick last year are now showing the uptick in releases. It is happening.
This means software will be more competitive and lower margin. This sounds like doom but it's actually great. Great for consumers. Great for indie devs that want to compete against big companies. Their margin is your opportunity.
Meanwhile, the kinds of early adopters that you're looking for are very conscious of enshitification and lock-in. So the best way to reach them and get talked about is through making software that the big VC-backed companies would never write.
The winners will be one-man companies who understand and respect their customer. Open protocols show your users respect and could be a great differentiator.
What about applications? federations, or better: relays, would put an end to censorship. Encryption would put an end to surveillance. Cryptographic signing would improve authentication and security at wide as there would be no stored passwords to leak.
Until then, "protocols not services" will remain a privilege for the technical elite.
The identity point in the discussion is spot on. The missing piece in most protocol-first architectures is a portable identity layer that doesn't just recreate the service dependency at a different level. DIDs and Verifiable Credentials are trying to solve this but adoption is glacial because there's no compelling consumer use case yet — it's all enterprise compliance stuff.
The XMPP vs Matrix debate is interesting but somewhat misses the point. Both protocols work. The reason Discord won isn't protocol superiority — it's that they solved the 'empty room' problem by piggy-backing on gaming communities that already had social graphs. Protocol design is necessary but not sufficient; you also need a migration path that doesn't require everyone to switch simultaneously.
Could workloads really be broken up and distributed like this among many peer machines?
It turns out it's very slow to evolve a protocol. How long did it take for IRCv3 to handle channels having persistent history? How about channel takeovers via network splits? We knew these were problems in the 20th century but it took a very long time to fix.
Oh, and the chathistory Extension is still a draft! So is channel-rename! And account-registration?
And why is it still so painful to use Mastodon?
That's but one of many examples. Consider how the consolidation of HTML and HTTP clients was the only way that we ended up with any innovation in those services. People have to keep up with Chrome who just does their own thing.
I want to want a decentralized world governed by protocols, but good software that iterates quickly remains the exception rather than the rule.
https://signal.org/blog/the-ecosystem-is-moving/
Also the article presents a false dichotomy in my view: protocols need services to be useful to virtually 99.9999% of humans (or at least they do in the architecture we have built since... email?).
Who uses email without relying on servers? Where is your selfhosted email box sitting on if not in a hosting service?
Even IRC relies on servers for people to talk to. I love to experiment with protocols that do not rely on servers - secure scuttlebut? - but even ssb relied on some seed peer that provides a service to initialize the peering
Note that Discord doesn't replace IRC, it also competes with TeamSpeak; there's a whole voice and video sub-feature to it. Not everybody uses it but the fact that it's available in the same software was advantageous to the original market, gamers.
Of course it was also clear that eventually the investors will want to cash out & we are seeing the results of that.
I'm very much sympathetic to the post's argument, but I think it should be acknowledged that this kind of claim has an implicit "(for now)" at the end.
The legal system doesn't have good mechanisms for dealing with problems that it hasn't needed to deal with yet, but if most people moved to encrypted & decentralized protocols for communication, it doesn't follow that laws couldn't be amended to give governments powers to legislate or police it at scale if deemed necessary by some sufficiently powerful group (an autocracy, a voting bloc, a national security service, etc)
So I guess the other implicit piece is that one hopes the technological change comes with cultural change to our political expectations - once people get used to privacy and autonomy, they resist efforts to erode those rights again.
Best of luck to everyone advocating for this! Really hoping to see a lot of thriving communities post-Discord in the coming years.
To connect you would run a script called gridstart that mounted the remote resources in that windows namespace then start a sub rio running gridchat, Acme (text editor), page (document viewer) and the mothra web browser that only supports basic html, no js, css, etc. Gridchat was nothing special, it was pretty much IRC with a slight twist. It consisted of a shared buffer living on a 9p message queue server which everyone's client, an rc script, read and wrote to. Some users wrote their own chat client scripts and of course you could completely change how the grid behaved on your end - it was completely within your power to arrange those resources as you saw fit.
The idea was the plumber in that namespace lets a user plumb a message to everyones clients who were listening on that shared plumber. So if you plumbed a url in gridchat it would load in everyone's browser. you could upload an image file to the griddisk, plumb it and it opens in everyones page. Same with source code but Acme would open the file. It was like a primitive slack or discord where you could technically send images, gifs and urls.
All of it was built on Plan 9 tooling using the native 9P protocol and wired up using rc scripts, all of which is available out of the box. I think the only non-standard Plan 9 tool was was the general purpose message queue 9P server that happened to be the perfect tool to host the gridchat buffer. Sadly, Mycroftiv passed away and 9ants is no more but gridchat lives on sans the shared plumber stuff.
It was all about the protocol: 9P. Everything used the same 9P shaped plug and socket and the client was built up from base tooling. You as a client had complete control over the client portion. This was probably the best example of "protocols, not services" that I have ever seen.