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.
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.
The best part about XMPP, or rather "protocol not service" as the OP discusses, is that you can go beyond the intended use case of it.
My favorite example - Arista network switches can be clients on an XMPP server. Control plane's have to be very slim. XMPP enables someone with a network operator to apply wide, symmetrical configurations across a network, without repetition. You can add the "core" switches to a group chat, and query them for information simultaneously.
You would never see Discord as a control plane management option, nor a Slack, Telegram or Signal option. But if all or a group supported XMPP, there would be a low resistance avenue for that (if someone really wanted it).
As it stands, we have product lock in due to each service having it's own system, with limits on interactivity. So I won't be cross-channel quoting outage causes directly from the switch in the company Slack any time soon.
I think the comparison today is more vs the Matrix protocol that is a more recent take at the same ideas, and JSON vs XML isn't the strongest argument.
It's a perfectly reasonable choice: flexible, well specified, well supported, reasonably performant. I think the extreme level of hype 20 years ago was overdone and (just like with anything) there's good ways to adopt it and bad ways. But as a basic technology choice, it's fine. Particularly these days when you can have a coding agent write the parser boilerplate, etc. for you.
XMPP was the first creep towards the bullshit of today. Unlike IRC, it makes you register, leak identifiers, centralise and transfer power over you to third parties. Exposing you to lawfare, downtime and wasted resources. Also, IRC is extendable.
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.
> 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.
The underlying problem to both protocols and non-protocols is identity. Gmail works because Google owns the identity and acts effectively as a proof of humanity.
To go on a tangent - I think that more people having personal public key pairs (via crypto) than ever is actually a positive direction. Atprotocol is another big player in identity at the moment, just as long as "can't be evil" mechanisms are kept alive and have good UX.
Identity is "infrastructure" government should provide via something like mDLS. A lot of work needs to go into make sure it is secure and it can be used in a way that protects privacy. Eg selective disclosure of attributes for verifying age. Pairwise pseudonyms for identity when your online identity doesn't need to be tied to you real identity, which is most of the time. Something like that would go far in dealing with sybil issues in decentralized systems, which is often the source of a lot of headaches for system designers.
You can use a custom domain that you own with gmail. But of course domains aren't that great either as they are only somewhat decentralized and it's still pretty easy to lose your domain.
> And the safest way to do identity is to have it be destructable and remakable on the fly.
It might be the safest, but it defeats lot of the purpose of identity. There is a reason it is a hassle to change your email address... so many services are tied to that identity. You can change it, but you have to change every service that is relying on it as your identity, and you still have to own your old email so you can prove to the service that you are the same person.
I am not sure how you could ever avoid this problem? The purpose of an identity is to be able to tell that one request is made by the same person who made a previous request... persistence is a requirement.
Atproto identity is going in the right direction but I hope they go in that direction harder. For example plc.directory (maps DID to public keys I think?) is heavily centralizing force.
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).
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.
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.
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.
"one-man companies" and "open-protocols" doesn't make a lot of sense. I mean maybe there's a super small chance that one person vibe codes an outstanding protocol definition that the rest of the developer community decides to adopt, but that is vanishingly small bordering on laughable.
When I started coding, the web was just getting started.
I wanted to code in a 'real' language like C. I didn't respect the web technologies. I do now.
It's disservice to yourself to not use the tools available to accomplish your goals. I know the anti-AI sentiment is hot and sometimes for good reason. But there's value here, too.
As for open protocols, there are really two paths. You follow an open protocol that is already out there. Or you can, if you already have some success in your niche, open your SaaS up to be communicated with which can be the start of an open protocol.
With my own software, I'm making it easy for a user's LLM to interact with my software while not providing the AI tool myself. Through a copy markdown button that instructs the LLM how.
This isn't quite an open protocol but has some of the properties of them. It allows people to build integrations ad-hoc without much work. It is on their terms, not mine.
Right now, this seems to be the most ergonomic and transparent way to get integration that allows the user to be in control. And, for my own consumer perspective, the way I hope things go.
Now is a terrific time to be the change you want to see in the world.
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.
why would you hedge yourself with a double-negative here? It was because of (open) protocols and not services that people could easily decamp and setup afresh.
Interoperability has always been paramount, but gets so easily forgotten.
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.
The interesting thing about Nostr (vs each of the other options listed here) is that it works perfectly fine over sneakernet. And that has been impossible to block throughout the world, even in some of the most oppressive nations.
Since the spec includes identity, content (in multiple formats), and authenticity/integrity, this makes it superior to nearly all alternatives for offline use. Once you know someone’s key, you can verify that content comes from them, however you manage to obtain that content.
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?
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.
I always thought SMTP would make a good webhook delivery protocol.
Nostr provides both identity and protocol.
What prevents 100 Billion ChatGPTs from using any protocol?
cost, and we can create policy (shocker)
also what specifically are you worried about these 100 billion chatgpts doing?
Nothing, and that's fine.
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.
The best part about XMPP, or rather "protocol not service" as the OP discusses, is that you can go beyond the intended use case of it.
My favorite example - Arista network switches can be clients on an XMPP server. Control plane's have to be very slim. XMPP enables someone with a network operator to apply wide, symmetrical configurations across a network, without repetition. You can add the "core" switches to a group chat, and query them for information simultaneously.
Found an example article: https://jonw.mayhem.academy/arista-switch-wrangling-with-xmp...
You would never see Discord as a control plane management option, nor a Slack, Telegram or Signal option. But if all or a group supported XMPP, there would be a low resistance avenue for that (if someone really wanted it).
As it stands, we have product lock in due to each service having it's own system, with limits on interactivity. So I won't be cross-channel quoting outage causes directly from the switch in the company Slack any time soon.
Oooh, a new client! between Fluux[0], Spaces coming to Movim[1], and now this, the XMPP ecosystem is getting exciting again.
[0] https://github.com/processone/fluux-messenger
[1] https://movim.eu/
Please do show it off when it's ready! Three cheers for XMPP and the return of protocol oriented thinking.
There is another thread about self hosting an XMPP server today
https://news.ycombinator.com/item?id=47034801
I think the comparison today is more vs the Matrix protocol that is a more recent take at the same ideas, and JSON vs XML isn't the strongest argument.
XML isn't a strength these days, IMO.
It's a perfectly reasonable choice: flexible, well specified, well supported, reasonably performant. I think the extreme level of hype 20 years ago was overdone and (just like with anything) there's good ways to adopt it and bad ways. But as a basic technology choice, it's fine. Particularly these days when you can have a coding agent write the parser boilerplate, etc. for you.
XML is much better than JSON for document-oriented data like messaging and web pages. Use the right tool for the job.
XMPP was the first creep towards the bullshit of today. Unlike IRC, it makes you register, leak identifiers, centralise and transfer power over you to third parties. Exposing you to lawfare, downtime and wasted resources. Also, IRC is extendable.
Consider - why did Discord or Slack win over IRC?
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.
> 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.
They use the email example, but if Google bans me, my identity is also banned and that may be how people contact me.
We also need decentralized identity so my identity can exist independently of service providers, but still be owned by me and not an impersonator.
The underlying problem to both protocols and non-protocols is identity. Gmail works because Google owns the identity and acts effectively as a proof of humanity.
To go on a tangent - I think that more people having personal public key pairs (via crypto) than ever is actually a positive direction. Atprotocol is another big player in identity at the moment, just as long as "can't be evil" mechanisms are kept alive and have good UX.
Identity is "infrastructure" government should provide via something like mDLS. A lot of work needs to go into make sure it is secure and it can be used in a way that protects privacy. Eg selective disclosure of attributes for verifying age. Pairwise pseudonyms for identity when your online identity doesn't need to be tied to you real identity, which is most of the time. Something like that would go far in dealing with sybil issues in decentralized systems, which is often the source of a lot of headaches for system designers.
Only as a last resort. If possible, governments, just like any other organizations, should have absolutely no say about anyone’s identity.
They (like any other entity) can attest, but such attestation should hold as few of any special value as possible.
You can use a custom domain that you own with gmail. But of course domains aren't that great either as they are only somewhat decentralized and it's still pretty easy to lose your domain.
So, (especially after watching Bluesky / ATProto) I'm increasingly convinced that this is not a problem that needs solving.
Email is still a protocol, and the thing that ATProto is doing causes as many problems as it purports to solve.
Mostly because "decentralized identity" is still "identity." And the safest way to do identity is to have it be destructable and remakable on the fly.
> And the safest way to do identity is to have it be destructable and remakable on the fly.
It might be the safest, but it defeats lot of the purpose of identity. There is a reason it is a hassle to change your email address... so many services are tied to that identity. You can change it, but you have to change every service that is relying on it as your identity, and you still have to own your old email so you can prove to the service that you are the same person.
I am not sure how you could ever avoid this problem? The purpose of an identity is to be able to tell that one request is made by the same person who made a previous request... persistence is a requirement.
That exists in the form of domain names.
Which for reputable TLDs is permanent, outside illegal activities.
Country code TLDs are also reputable, but you might lose access if you move or if something happens to the country.
atproto has a very elegant decentralized identity solution imho https://atproto.com/guides/identity
Atproto identity is going in the right direction but I hope they go in that direction harder. For example plc.directory (maps DID to public keys I think?) is heavily centralizing force.
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).
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.
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.
The importance of this cannot be overstated.
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.
"one-man companies" and "open-protocols" doesn't make a lot of sense. I mean maybe there's a super small chance that one person vibe codes an outstanding protocol definition that the rest of the developer community decides to adopt, but that is vanishingly small bordering on laughable.
Vibe coding is not the answer to every problem.
When I started coding, the web was just getting started.
I wanted to code in a 'real' language like C. I didn't respect the web technologies. I do now.
It's disservice to yourself to not use the tools available to accomplish your goals. I know the anti-AI sentiment is hot and sometimes for good reason. But there's value here, too.
As for open protocols, there are really two paths. You follow an open protocol that is already out there. Or you can, if you already have some success in your niche, open your SaaS up to be communicated with which can be the start of an open protocol.
With my own software, I'm making it easy for a user's LLM to interact with my software while not providing the AI tool myself. Through a copy markdown button that instructs the LLM how.
This isn't quite an open protocol but has some of the properties of them. It allows people to build integrations ad-hoc without much work. It is on their terms, not mine.
Right now, this seems to be the most ergonomic and transparent way to get integration that allows the user to be in control. And, for my own consumer perspective, the way I hope things go.
Now is a terrific time to be the change you want to see in the world.
> Great for consumers.
Yeah, I also love my data uploaded to public Firebase buckets.
The implied faith in large organizations to handle your data securely is interesting.
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.
why would you hedge yourself with a double-negative here? It was because of (open) protocols and not services that people could easily decamp and setup afresh.
Interoperability has always been paramount, but gets so easily forgotten.
The interesting thing about Nostr (vs each of the other options listed here) is that it works perfectly fine over sneakernet. And that has been impossible to block throughout the world, even in some of the most oppressive nations.
Since the spec includes identity, content (in multiple formats), and authenticity/integrity, this makes it superior to nearly all alternatives for offline use. Once you know someone’s key, you can verify that content comes from them, however you manage to obtain that content.
I'm using TCP/IP how about you?
We already are. TCP/IP makes it all possible.
If your "protocol" runs over IP (which I doubt you can avoid these days) it doesn't make much of a difference if it's HTTP or whatever.
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?
When it comes to AI, I would say
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.