alt.hn

2/16/2026 at 6:44:58 PM

Use protocols, not services

 https://notnotp.com/notes/use-protocols-not-services/

by enz

2/16/2026 at 8:17:44 PM

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.

by ebiester

2/16/2026 at 8:54:46 PM

All you've said here is that you (and many others) have shown in the past that they've valued convenience and rapid feature development over freedom and stability.

That is good to understand, but when that trade starts causing issues, it is important to remember that there was a trade made.

We aren't as stuck as we think we are, unless we decide not to reevaluate our past choices.

by gorjusborg

2/16/2026 at 9:28:10 PM

Yes, essentially everyone on the planet was willing to trade some freedom for chats that work on mobile or could send images.

Matrix has shown how incredibly difficult it is to make a modern service in a decentralised way. Requirements like preventing spam become immensely difficult.

by Gigachad

2/16/2026 at 9:58:39 PM

Preventing spam may not be possible for much longer without verified IDs considering how advanced ai agents are.

Do any fully trustable ID validation services exist? Ones that verifiably never store your ID but just a validity status for a given ID on a blockchain?

by Xss3

2/16/2026 at 10:18:28 PM

Assuming you want ID verification, why would you need a blockchain? Your identity is deeply linked to who you are and we have identity documents and trusted entities to provide them. These entities can absolutely act as a third-party to verify who you are. This can happen with several different parameters: whether your identity is provided to the site you are using, whether the site your are using is known to your identity provider, whether identities across sites are identical or only linkable by the trusted party. But in all those examples (that are currently implemented by some countries), blockchain is not a requirement.

Assuming you don't want actual ID verification, the choices are even larger but with different trade-offs.

by Sayrus

2/16/2026 at 10:13:35 PM

Phone numbers + phone number country + account age + behavior can be used to build a trust score. It might not be bulletproof but it cuts down spam enough for now.

Imagine a messaging app for example, a 1 month old account with a Nigerian phone number cold DMs an account in Australia. The likelihood of this being spam/abuse is extremely high. Vs a 5 year old account that mostly messages mutual contacts cold DMing an account in their own country.

In many countries, phone numbers are a proxy for ID and are difficult to get without having a local ID. The countries which have not secured their phone number system will be less trusted by spam filters.

by Gigachad

2/16/2026 at 10:38:05 PM

Nobody said how hyper the HT in HTML and HTTP had to be, so here we are.

Oh, TLS also. Encrypted connections over HTTP are trivial.

Arguably this has created far more freedom by making encrypted network traffic default and free. Convenience is also freedom when it comes to accessibility.

by ljm

2/16/2026 at 10:09:40 PM

There's also this annoying flash perception that wins. As the big companies abandoned XMPP, less people considered it.

It's pretty good today! Lots of things improved a lot! Some big clean ups!

But think of how much better it would be if people stayed woke, if they didn't just throw up their hands call defeat & say it was never going to work. If there wasn't such a bleak rot in our soul, if we could try to play slightly longer games, I think in the medium & long run it would be much much better for us all.

It feels so easy to spread sedition, to project these fatalisms that only big dumb lumbering central systems win. I'm so tired of this bleakness, this snap to convenience as the only perceived possible win. Let the prophecy self fulfill no more, let us arise from this torpor. A little Ubuntu would be ao good for us all. Ubuntu the old saying (that the distro was inspired by) goes: "If you want to go fast, go alone. If you want to go far, go together"

by jauntywundrkind

2/16/2026 at 10:13:20 PM

[dead]

by cindyllm

2/16/2026 at 9:33:10 PM

Put another way, the services need us more than we need them.

by bigbuppo

2/17/2026 at 12:03:02 AM

Short-term yes, long-term it is often the other way around. In many cases, abandoning an open standard for a closed, centralised solution is surrendering to future enshittification for short-lived instant gratification.

by schubidubiduba

2/17/2026 at 12:09:25 AM

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

by 627467

2/16/2026 at 9:53:03 PM

Comparing IRC-the-protocol to Discord-the-platform is silly. Apples-to-oranges etc

by b00ty4breakfast

2/16/2026 at 10:15:45 PM

I can't tell if you are replying to the comment or the post because the topic of TFA is literally comparing protocols and services. Discord and IRC are both mentioned in the post.

by caseyohara

2/17/2026 at 2:05:58 AM

Pretty sure they're replying to the post that directly contrasts Discord/Slack and IRC.

TFA mentions both, yes, but as a direct example of service/platform (Discord) vs protocol (IRC, XMPP, etc). The comment asks a question that kinda misses the point of TFA.

Discord could be considered to have "won" in that it's got a lot of (new) users and removes some of the limitations of IRC, but that's _because_ it is a service/platform, and comes with all the trade-offs being discussed in other threads here.

Or one could consider IRC to have "won" because as a protocol it simply can't have some of the restrictions possible with a centralized platform.

It's trade-offs all the way down, but protocols will always have fewer restrictions of the kind currently in the zeitgeist, especially decentralized protocols.

by just6979

2/16/2026 at 9:01:36 PM

Totally understand, I am all for decentralized world too. In reality tho most ppl just choose whatever works fast and ships fast and more production-ready I guess, no drafts. Would be great if the world sees an opposite example, by far centralised approach just worked better

by shabatar

2/16/2026 at 7:43:04 PM

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.

by vvpan

2/16/2026 at 8:11:19 PM

I always thought SMTP would make a good webhook delivery protocol.

by pbreit

2/16/2026 at 8:04:48 PM

Nostr provides both identity and protocol.

by iamnothere

2/16/2026 at 9:09:29 PM

It provides a very fragile identity system and a very unreliable and inefficient message delivery protocol.

by treyd

2/16/2026 at 9:28:28 PM

Care to explain what you mean by “fragile”? It is cryptographically sound.

I agree that the delivery protocol could be more efficient, but use of JSON is a tradeoff that provides good extensibility and easier parsing (many well seasoned libraries exist in almost every language).

by iamnothere

2/16/2026 at 11:11:45 PM

Not a cryptography / data format thing. Although CBOR is just as widely supported as JSON and that would have been a better choice there, but that's not really the issue, but the whole approach to identity.

Identities are global and shared across devices. Naturally, if your keys are lost/compromised your identity is lost/compromised.

So the solution they have to this is that your real root identity delegates signing to other identities (generated local to a device) by publishing a note indicating a list of keys allowed to sign on its behalf, and presumably you keep your root identity on a trusted device (like maybe a crypto hardware wallet or a threshold multisig).

But this just reduces the problem and worsens the UX. Your identity still gets lost/compromised if the root is.

There's also an issue with how identity updates themselves work. Since these delegates are really signing for the single root, they need to be synchronized to work properly. There was a common bug (which might still happen) where if you set up your identity on a new device, the app might broadcast an identity update with an incomplete view of your identity and it resets your follows and post history. Since your identity data might be influenced based on every note you've ever sent, and message delivery is unreliable, it's hard to properly sync and reconstruct sent note history. This comes out of a fundamental design issue, where you have multiple "writers" writing to the same state. CRDTs could have helped with this, but it's too late to do that.

This sucks! It forces users to think about key management and has catastrophic failure modes. It's really hard to re-establishment trust after key compromise because there's no notion of identity that lives longer than any one key.

Matrix is not a comparable kind of protocol, but its identity management story is a lot better. Each device has a local key that never leaves the device, and when you add a new device you cross-sign it from another device you have. Homeservers maintain a list of identities tied to a user, and other people can decide to trust the device cross-signing or manually verify each of them. This can be built in a fully decentralized context (which Nostr is not, for what it's worth).

by treyd

2/17/2026 at 12:41:24 AM

Isn’t this just an implementation/UX issue? Ideally the root key should live somewhere secure (offline) and delegate keys live on connected devices. As the ecosystem matures I would expect this to become easier. A hardware wallet means the risk of key loss would become negligible.

I think CRDTs are great, but Nostr has always presented itself as a potentially lossy medium, purposefully. Unlike SSB and Matrix where state synchronization became a complex bottleneck, Nostr is more IRC-like. Relay owners may have to delete individual posts due to legal reasons, or identities may selectively publish different posts to different relays. The devs didn’t see this as a problem since full state synchronization is heavy and requires long term retention of data. I agree that it’s not perfect, the tradeoffs make it harder to reconstruct a full history for a given identity if you’re trying to reach way back in time. But for new content it works really well, and I think this is why they chose this approach. If you publish to a lot of relays, your message will get through to the people who want to see it, although the process is messy.

by iamnothere

2/16/2026 at 11:50:10 PM

> in a fully decentralized context (which Nostr is not, for what it's worth).

May I ask you to elaborate on this point?

by dtonon

2/16/2026 at 7:45:32 PM

What prevents 100 Billion ChatGPTs from using any protocol?

by andai

2/16/2026 at 7:53:11 PM

Nothing, and that's fine.

by kgwxd

2/16/2026 at 10:08:45 PM

If you are trying to stop monopolization, then having a large organization/government swarm the protocol gives them an effective monopoly. Being able to put a drop of clean water into an ocean of corruption is not really a working system.

by shafoshaf

2/16/2026 at 7:53:51 PM

cost, and we can create policy (shocker)

also what specifically are you worried about these 100 billion chatgpts doing?

by css_apologist

2/16/2026 at 8:57:32 PM

Cost is irrelevant if they get more out of doing it than the processing costs.

by coldtea

2/16/2026 at 9:31:08 PM

Do they get more out of it than it costs, or are they still in the "people are just giving us money in the hopes that one day it turns a profit even though we're not charging nearly enough to make a profit" phase?

by bigbuppo

2/16/2026 at 10:44:04 PM

You're describing the AI companies and their business model.

I'm answering to that cost being a problem regarding "what prevents 100 Billion ChatGPTs from using any protocol?" - the context I have in mind for the above being scammers, political manipulators, spam, and people like that using ChatGPT/LLMs to take advantage of various protocols for profit (and the 100 billion figure being a figure of speech meaning "very many").

by coldtea

2/16/2026 at 7:19:11 PM

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.

by giancarlostoro

2/16/2026 at 8:12:29 PM

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.

by quadrium

2/16/2026 at 9:50:26 PM

Discord/Slack/Telegram get used for botnet command and control, and this method has been used since the irc days.

by esseph

2/16/2026 at 7:50:56 PM

Please do show it off when it's ready! Three cheers for XMPP and the return of protocol oriented thinking.

by glenstein

2/16/2026 at 9:11:30 PM

> The biggest strength I see for XMPP is [...] XML

It's an advantage, sure, but to me the serialisation format is the least interesting thing. Others are similarly optimized too. I think the extensibility and approach to standards is far more interesting than the fact it uses angle brackets instead of braces.

by RadiozRadioz

2/16/2026 at 9:17:28 PM

Are they still sending the entire stream as an element? Thereby making dealing with that xml a lot more painful than it needs to be.

Back in the days, I had to write my own parser, existing xml parsers couldn't handle the case well.

by codr7

2/16/2026 at 7:45:23 PM

XML isn't a strength these days, IMO.

by candiddevmike

2/16/2026 at 7:55:34 PM

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.

by dpe82

2/16/2026 at 9:34:48 PM

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

Absolutely with you up to here, but...

> Particularly these days when you can have a coding agent write the parser boilerplate, etc. for you.

Absolutely not. Having seen the infinite different ways a naive implementation of XML goes wrong, arguably being one of the main causes of death for XHTML because browsers rightfully rejected bad XML, "Don't roll your own XML implementation" should be right up there with "Don't roll your own crypto".

I don't feel like it's going out on a limb to say that if someone needs to defer to a LLM to implement XML they're not qualified to determine if it's done it right and/or catch what it got enthusiastically wrong.

by wolrah

2/16/2026 at 7:49:30 PM

XML is much better than JSON for document-oriented data like messaging and web pages. Use the right tool for the job.

by stickfigure

2/16/2026 at 9:35:57 PM

IM messages aren’t really documents. They are text with some very minimal formatting that could be expressed with markdown. Any media attached isn’t embedded in the document, it’s attached externally / rendered at the bottom.

The only example I can think that messages are expressed as documents is Microsoft Teams. And it’s as much an example of what not to do as anything.

by Gigachad

2/16/2026 at 11:48:57 PM

IM messages seem to be documents just as much as email or many things you'd normally call documents. A reasonable definition IMO would be:

    A self-contained rich formatted text file/package that optionally contains attachments or media.

by SahAssar

2/17/2026 at 12:00:53 AM

I'd disagree with that for most messaging apps. If you think about Discord or Slack for example. You have a plain text message and then media attachments externally. This could be very well expressed with JSON.

Very few messaging apps let you go beyond plain text and let you start embedding media or complex layouts inside a message.

by Gigachad

2/16/2026 at 10:41:13 PM

Eh, XML is a machine-readable generic markup language. Why would you prefer using a less powerful format like markdown in a context like message representation? XML with inline tags seems the perfect fit.

by idle_zealot

2/17/2026 at 12:05:03 AM

Less powerful also means less complex and less exploitable. You can very easily grab a markdown renderer rather than trying to decode a .docx for messages.

Pretty much no messaging apps let you create messages more complex than markdown anyway.

by Gigachad

2/16/2026 at 7:36:35 PM

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.

by ZiiS

2/16/2026 at 7:38:03 PM

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.

by coretx

2/16/2026 at 9:26:22 PM

oh please do show it! I love XMPP and the clients are few and far between. Does it do jingle?

by rainmaking

2/16/2026 at 8:25:49 PM

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

by ikesau

2/16/2026 at 7:22:05 PM

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.

by PretzelPirate

2/16/2026 at 7:36:04 PM

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.

by Seattle3503

2/16/2026 at 8:08:25 PM

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.

by drdaeman

2/16/2026 at 9:12:45 PM

> Only as a last resort. If possible, governments, just like any other organizations, should have absolutely no say about anyone’s identity.

An unusual position, as historically governments have provided birth and death registries [0], passports, identity cards, etc, etc

[0]: or, earlier, in the West at least, the church

by davidgay

2/16/2026 at 9:13:17 PM

We've seen ~20 years of people trying to solve identity without the government. We've seen plenty of solutions that can provide stable identities over time, but we haven't really seen anything that provides meaningful sybil resistance. As computer systems become more and more "autonomous", sybil resistance is increasingly the most important feature of any identity system. Any identity system that doesn't solve that problem pushes to the application layer, where it usually has UX impacts that have serious tradeoffs with adoption.

by Seattle3503

2/16/2026 at 7:37:33 PM

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.

by jrm4

2/16/2026 at 7:45:10 PM

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

by cortesoft

2/16/2026 at 9:53:26 PM

Yes. And as much as I hate "well, users should just be smarter and deal with inconvenience," I think it may fit here.

Identity is always hard, and I strongly doubt there is any great way that makes it "easier" and still safe.

Aka, yes please kill passkeys, or at least be super upfront and informative.

"When you use passkeys, you are giving your keys to Apple or Google, and they cannot guarantee safety."

by jrm4

2/16/2026 at 10:58:22 PM

It may be that different types of identity are preferable for different use cases, rather than converging on a single system.

> "When you use passkeys, you are giving your keys to Apple or Google, and they cannot guarantee safety."

Not true with hardware passkeys, which also add a true second factor. Central passkeys are a problem, though.

by iamnothere

2/16/2026 at 7:27:25 PM

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.

by voxic11

2/16/2026 at 7:51:00 PM

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.

by vvpan

2/16/2026 at 7:31:02 PM

That exists in the form of domain names.

Which for reputable TLDs is permanent, outside illegal activities.

by paulddraper

2/16/2026 at 8:03:51 PM

Country code TLDs are also reputable, but you might lose access if you move or if something happens to the country.

by watermelon0

2/16/2026 at 7:26:36 PM

atproto has a very elegant decentralized identity solution imho https://atproto.com/guides/identity

by wilg

2/16/2026 at 7:53:41 PM

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.

by vvpan

2/16/2026 at 11:43:46 PM

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.

by larnon

2/17/2026 at 12:34:35 AM

The "impossibility" of enforcing legislated constraints on thousands of providers point is hand waving. We're all legislated to not harm each other. Throwing the small fraction who do in jail, is sufficient to keep the vast majority away from harming others, and there is also moral alignment.

If 10% of hosts (maybe even less) are penalized, the rest will likely start complying. much like self managed compliance of thousands of companies. A protocol is only as good as the entities that participate in the community using it.

by sriku

2/17/2026 at 12:50:03 AM

I find that my iPhone is a bit of a barrier to this. Don’t really want a tunnel/vpn due to battery so mTLS auth would be good but that doesn’t seem well supported by apps like matrix etc. Similar issue with trying to get access to openclaw. Would love a self host interface like mattermost but can’t find a mTLS/open combo that can also do notifications

by Havoc

2/16/2026 at 11:35:50 PM

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.

by MisterTea

2/16/2026 at 7:55:32 PM

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

by laurex

2/17/2026 at 12:08:34 AM

We implemented something similar last month. The key insight was focusing on the Use Protocols, Not S aspect first.

by poketdev

2/17/2026 at 12:00:52 AM

We implemented something similar last month. The key insight was focusing on the Use Protocols, Not S aspect first.

by nimbus-hn-test

2/17/2026 at 12:16:34 AM

Protocols over services is a solid pattern - worked well for our team.

by poketdev

2/17/2026 at 12:17:13 AM

Interesting approach! I've been working on something similar.

by poketdev

2/16/2026 at 7:45:16 PM

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.

by throwaway13337

2/16/2026 at 7:49:28 PM

> Great for consumers.

Yeah, I also love my data uploaded to public Firebase buckets.

by therein

2/16/2026 at 7:57:53 PM

The implied faith in large organizations to handle your data securely is interesting.

by throwaway13337

2/16/2026 at 9:06:45 PM

If I had to choose between a large organization and a single person vibe coded app, I'd choose large organization.

by srdjanr

2/16/2026 at 7:58:25 PM

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

by WD-42

2/16/2026 at 8:08:39 PM

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.

by throwaway13337

2/16/2026 at 7:51:32 PM

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.

by hirako2000

2/16/2026 at 8:02:54 PM

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.

by matheus-rr

2/16/2026 at 7:01:56 PM

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.

by superkuh

2/16/2026 at 9:40:16 PM

Is it a good example? That incident was pretty much the last nail in the coffin for IRC. Most open source communities have moved to Discord now.

by Gigachad

2/16/2026 at 7:07:22 PM

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.

by gjvc

2/16/2026 at 10:01:27 PM

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.

by globalnode

2/16/2026 at 11:11:15 PM

To me, this is what it ultimately comes down to. It is a normie world: sure, they care now about the ID and face scans, but the reason it even got to this stage is because everybody wants to be on the platform that everyone else is on, and the platform that has the most eye-catching features is the one that gets picked. Not the one with the most robust protocol that prevents centralization but can’t save a chat history, get channels renamed, or has no voice support.

by NewsaHackO

2/16/2026 at 8:15:15 PM 

  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.

by adolph

2/16/2026 at 8:35:12 PM

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.

by iamnothere

2/16/2026 at 8:13:31 PM

We already are. TCP/IP makes it all possible.

by 0xdeadbeefbabe

2/16/2026 at 8:04:28 PM

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.

by moralestapia

2/16/2026 at 9:41:42 PM

Only non IP protocols I can think of are proprietary zigbee protocols for local communication with devices, and lora mesh radio protocols like MeshCore.

by Gigachad

2/16/2026 at 7:43:29 PM

[dead]

by engelo_b

2/16/2026 at 7:37:44 PM

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.

by EGreg

2/16/2026 at 8:04:16 PM

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?

by deadbabe

2/16/2026 at 8:13:51 PM

I'm using TCP/IP how about you?

by 0xdeadbeefbabe