Every person (or team) runs a small instance for their own domain. Instances find each other through DNS and well-known identity documents, exchange signed messages over HTTPS, and present the whole federated network to ordinary IRC clients such as Lurker, Mango, mIRC, WeeChat, Textual, etc., without the need of any plugins.
Hacker News marketing skills tell people to leave a context comment on Hacker News. Don't complain about it too much, that is our way of figuring out who is lazy in an obvious way!
When someone makes a submission, the text field becomes a comment when the URL field is not empty. (but sometimes not?) It's a poorly designed form that should be redone.
I wish them the best of luck. Federated systems struggle to achieve critical mass, and if they do, large corporations tend to snuff it out. I distinctly remember Google committing to The Microsoft EEE strategy with XMPP. We've left behind lots of great ideas in the last 20 years
Google helped make XMPP quite popular for awhile, then killed their own product and left us with a lot of useful specs they had contributed. So I'm not sure I'd call that EEE
Interesting. Why not use an open link network? These will result in around the same state. Spam _will_ be an issue here, in general. And with a different backend you're going to struggle to use preexisting tooling to handle it.
Using & channels is fun, I'd be interested to see how many bots and clients fall over dead when faced with that particular bit of IRC history.
IRC linking is a mess, in part due to the spanning tree requirement. Also the server to server protocol in the RFC is spoken by zero servers so you have to pick which unofficial protocol you like best. May as well invent your own that actually fits your use case.
Except that now there's yet another standard, which nothing but this thing speaks. TS6 is very well used at the moment as everything in the Charybdis line speaks it, etc.
Cool. I did something like that so agents and people could communicate with a Jira instance using Websocket-aware IRC and a browser-based client based on superchat.
Put the issue context in a #channel and invite external parties/entities, bring the results back to the work.
I have tested it but the complexity didn't justify the results in my experiment. I couldn't get it accepted into Atlassian Marketplace, either.
As someone very critical of mindlessly vibecoded software, I've worked with James (@prologic) years ago and very much respect his craft. AI assisted or not, I wouldn't describe him as a vibecoder. He's a great engineer.
I had a pseudo-plan for something like this but for reasons related to privacy I had two types of chatrooms:
* regular chats, existing only on the server, no leaking the chat transcript except via users, but never via server to server.
* chambers: a global chatroom, located at a server, maybe with a MQTT anyone could subscribe to.
This never left the early planning stages though, but I thought the segregation between federated chatrooms and regular chatrooms was of interest to keep in sync with IRC open but closed nature of chats.
So rooms are "global" between whatever hosts your host happens to know about? So it's one giant netsplit party forever and only your server admin can ban someone?
I am not the owner of the project, I just use it. Federated rooms have no owners, there will be no collisions (they would simply merge). Nicks are tied to their own servers, and hence unique and will not collide.
This has been an issue for as long as IRC itself has existed. There are solutions to resolve such "netsplits" and "netjoins", but they all rely on the servers in the network being trusted and not malicious.
With Parley, where anyone can bring their own instance, and they are not guaranteed to not to be malicious, that could be an interesting issue to solve.
From the screenshot on the project website, it seems "@serv.er" is part of any remote nickname, so I'm assuming the nicks are in per-server namespaces, which prevents any nick collisions.
Although it must wreak havoc on many IRC clients, since the @ sign has a very specific meaning in the IRC protocol. :)
There’s a specific downside to LLM-based development that people can get neck deep in a new project without interfacing with the existing work in the field.
In this case, this is basically a poorly specified implementation of half of XMPP. Of course, I half expect the LLM would have mentioned that at some point, but the repository does not.
I've done this a few times. If I had to gesture at the root cause I'd say: LLMs lack curiosity and are trained to complete assignments, not to question their validity, so both the research phase and the questioning of intent tend to get short shrift prior to building anything.
Agreed, you have to ask them to look for prior work. But then they will do a good job finding it in most cases. I think it’s partly their universal tunnel vision and partly sycophancy.
I'm not sure I agree. Seems to me to depend a lot on how one interacts with an LLM.
If you tell it to "build me an application X to do Y using programming language Z", it will comply.
If you interactively ask "I need X, can you suggest some options? use an existing product ? or build something using a library ? or build entirely myself ? can you suggest alternatives with pro's and con's ? Anything I should think of before deciding ?" then you will get an entirely different answer.
Maybe we need additional modes, aside from thinking mode, agentic mode etc. we need e.g. "sparring mode" ? or does such a thing already exist ?
That is currently still the differentiator between people producing code and shipping something and people who care and actually have years of experience shipping. At the current state how well you steer the LLM and which questions you ask still matters, maybe in the future "build me an app" will give amazing results, but right now you still need to know what you are doing.
In this case, it's just a waste of tokens as something not very unique was generated that doesn't have a real use case, or solves anyone's problem. As with many AI generated projects, I'm willing to bet that OP themselves will not using it any more in a month.
You guys are way too critical and about the wrong things. "Waste of tokens"? Perhaps the author know of the tradeoffs and just wanted to build something.
How you went from seeing somebody's post to deciding they don't care is a pretty big jump, one that isn't warranted. This kind of post seems like the old but now more elaborated form of hating on something that you don't even know what it is.
It just isn't fair to the work that has been put in.
I agree. This is one thing that's gotten me about the new wave of poo-pooing projects made since coding agents have gotten big. Five years ago it was 'just build something!'. I understand the market is more saturated now so building something isn't as valuable as it used to be, but it still shouldn't be treated as a negative. I don't know anything about the creator's background, but even if this project is ultimately redundant and unnecessary, it's still pretty cool that they built something.
or maybe they know about XMPP and prefer IRC. I have always wanted to build one of these on top of IRC. I grew up on IRC and sometimes just the nostalgia of familiar tech is what drives us to build towards it not how good it is.
Matrix turns every chatroom into a blockchain with a distributed consensus algorithm.
IRC (real IRC) solves this by not solving it, and accepting that message order can differ between servers. If two operators kick each other on two different servers at the same time, usually both get kicked - the command is validated on the origin server and the rest of the network takes it as gospel, even if it doesn't make much sense in their own local state.
Unfortunately XMPP is an absolutely terrible protocol. IRC's not much good either, but at least it has the excuse of being ancient and limited in what it wanted to achieve.
I don't know how it just happens that sending text messages to people can manage to result in specs that are painful to implement.
>Unfortunately XMPP is an absolutely terrible protocol
Can you provide more details here? I've never seen an issue with the protocol at all, more issues with feature difference between servers depending on what they have decided to implement or not.
There is zero baggage on NOSTR regarding identities. An npub became the non-ambiguous way to reference anyone regardless of where they are writing from.
Thank you for the reference to that project called anproto, never had heard of it and I'm still without understanding what problem it really solves. Seems to encrypt texts but then contains zero outside metadata to route it somewhere. The website is very scarce on details for someone unfamiliar the scuttle-something they mention.
NOSTR notes are very flexible. For example you can have the json include metadata which is essential to know where it should be going, or you can encrypt everything and send what looks like "garbage" to an open relay that can only be fetched by anyone with a key.
There are dedicated profile notes which define which relays that account/identity prefers to send their messages but everything is flexible. It does forego much of the routing metadata, which in my opinion is an obstacle when you don't know which stations/relays are placed on a given geography but you want the message to "navigate" (sometimes quite literally) to a place/region.
For that type of things I'm a biased fan of https://xprs.dev because it bridges NOSTR identities/signing/encryption with APRS that can use store/forward and the routing follows any possible method include USB drives.
The nostr baggage I referred to is the crypto culture on the network. I appreciate nostr for being sparse as well. ActivityPub doesn't feel approachable re: understanding the protocol.
There's an example ANproto in use at https://wiredove.net it's pretty clean but not very active, yet another experimental social network playground!
I will say that the middle layer is not great. I have an XMPP bot and the "interaction with the network" stuff really is ugly and unfun.
I think the protocol itself is... I mean it's fine, I guess? Protocols are tricky because a lot of stuff is bolted on and it's not really super stateless as a protocol. But like all the Python XMPP client libs (for example) are all real janky.
The protocol is complex enough to where the "simple and easy" client libs require way more up front design.
I once implemented the presence and basic messaging functionality of XMPP for a web site, using a braindead bridge (that I also wrote; so, the meaningful logic lived in the browser).
Considering I'd never hosted an XMPP daemon and didn't know anything about the protocol (I'd used XMPP clients a little bit, but had never looked at the protocol) and got a server (that part, I didn't write), an auth connector for our website's authentication system (so the daemon would authenticate against that instead), prod-ready and the features I wanted all working smoothly and reliably in maybe three weeks of very part-time work (this'd be, like, 3-4 part-time days with LLMs now, tops, from the same starting point)... seems decent to me? I mean I did direct work with the protocol, didn't just glue together libraries, and it was pretty damn good. Also (and I know browsers seem to be retreating on this front, which sucks) being XML made it very nice to work with in a Web context, since you can just ask the browser to turn ~any XML into a DOM for you, and get a bunch of functionality for free.
> I don't know how it just happens that sending text messages to people can manage to result in specs that are painful to implement.
This is what boggles my mind. We're talking: Text. Over the Internet. It should not be a complex, difficult problem! We've been sending text over the Internet from the moment the Internet went online. So how is it that 10 companies have managed to find 30 different ways to do it, which are all incompatible with each other? You have to TRY to fail this badly.
This is what boggles my mind. We're talking decades of arguments and discussions, dozens of different ways to do it, with dozens of tradeoffs that you could start listing with 20 seconds of thought, and still people just pop in like "why isn't it simple??" as if that's some award winning insight.
Come on, try! Start listing some of the core features of the different protocols/clients and answer your own question as to why it isn't simple! Presence. Chat history while offline. Threading. Mobile devices. Intermittent/mobile/cellular/wifi/CGNAT connectivity. Multiple clients on the same identity and presence. Identity establishing and confirming. Encryption. End-to-end encryption. Backing up and restoring chats, encrypted chats, group chats. Federation. Friends/groups/permissions/trust boundaries. Markup, markdown, formatting, images, emoji, unicode, code blocks. Audio, video, broadcast, multicast. Discovery. Extensibility. Federation. Store-and-forward.
> "We've been sending text over the Internet from the moment the Internet went online"
And IRC has RFC 1459, RFC 2810, RFC 2811, RFC 2812, RFC 2813, RFC 7194 and it does almost none of those things.
And you can still use IRC. But IRC is not good. At this point it's either wilfull ignorance of what people use computers for, or it's indistinguishable from deliberate trolling.
Threading? God, I hate threads in a live chat. Is it never not awkward to use? Slack is the example I'm thinking of, though I'm sure it's shit everywhere else too. In Slack, rather than display the one threaded reply just below (maybe indented), it makes me go to another window, but then someone else is replying non-threaded, so I have to bounce back and forth for the next 10 minutes.
I completely agree. Threads in Slack should be a great way to make conversations easy to navigate but damn did they fsck up ever part of the UX:
- opening threads in a new window is in some hard to find and hard to remember location
- threads can’t be inlined (like you’ve described). I actually like how they’re in a pane to the right but sometimes that causes issues (as you’ve described). Sometimes it’s just that the view is too narrow.
- there’s no way to shift non-threaded comments into the thread. I’ve lost count of the number of times conversations have happened over multiple threads and/or non-threaded replies.
The way they implemented it is a complete clusterfuck.
As an anecdotal counter-point, I love threads in a live chat. When used correctly, it means when my idiot friends start having a heated discussion about some random topic while I'm at work, I get one 'ding' from my phone and then never again until I start interacting or they @ me. As opposed to the 427 new notifications I get on my phone about whether Golden Eye was better than Mario Kart 64.
Ultimately the tech is only as good as the humans that use it. If you're chatting with folks that can't understand the difference between a thread or not, that's a meat-bag issue and not anything an RFC can fix.
I have half-wondered many times whether it would be possible/practical to build a chat system on top of MQTT or similar. Chat seems like mostly a pub/sub problem from where I sit.
IRC is good in that it is open, durable, and slow moving. All of those points are intentional features that make it a stable cockroach in a nuclear world.
I briefly entertained building a modern chat experience on top of IRC when I came to this realization.
IRC really is good. It's reliable too, but it really fell behind the times and never pushed forward with additions to the spec and such. When the clients and libraries tapered off too it just felt like it froze.
> I half expect the LLM would have mentioned that at some point, but the repository does not.
The repository does not even mention this software is LLM-generated.
I wonder when/if the collective realization will land that LLM's failure to retain provenance during training means the code it generates exists in an indeterminate state of public domain / IP trap.
Ya, ive stopped interacting with all new projects, the amount of slop written by people who have no business remotely putting something out there for others to use is untenable.
”There’s a specific downside to LLM-based development that people can get neck deep in a new project without interfacing with the existing work in the field.”
That’s because it’s a paradigm shift, not meant to be planned or organized by humans. The prior paradigm was that there were subject-matter experts who were human. The new paradigm is that the only author of all code is to be a machine. This new paradigm requires removing all prior authors (who happen to be human), and removing them simply requires overcrowding their output such that it’s not locatable or trustworthy.
Instead of a separate federated network for a single app, why not implement the app on top of a pre-existing federated network, so that nobody has to create yet another account?
Like, on top of atproto or activitypods or...?
Besides not having C runtime linked (which is great for scratch/distroless Docker images) - any other advantage of using a pure Go SQLite instead of the C binding?
Because throwing UDP packets requires a bandwidth advantage (aside from reflection attacks), whereas application-layer attacks can impose an outsized cost on the victim.
Unless you're running a private server with 10 friends you trust, irc is dead to me, I used to ircop on some big servers and your chats are logged everywhere and its a privacy hellhole. And that was before you could point an llm at a 10 year .log chat to deduce actors. Nothing like joining a room and there being 500+ complete non-chatter bots just idling doing god knows what.
Half of that job was de-escalating real life abusers from abusing their victims who would constantly track them down through irc.
Whats the average age on there efnet and dalnet now? 50-70ss? Or did that cohort move on? All of the recent software chats I've seen have been on discord which is its own ball of worms.
157 comments
[ 0.23 ms ] story [ 58.3 ms ] threadEvery person (or team) runs a small instance for their own domain. Instances find each other through DNS and well-known identity documents, exchange signed messages over HTTPS, and present the whole federated network to ordinary IRC clients such as Lurker, Mango, mIRC, WeeChat, Textual, etc., without the need of any plugins.
It’s like email just for IM…
The IRC is just a front end. Could use any front end
I wish them the best of luck. Federated systems struggle to achieve critical mass, and if they do, large corporations tend to snuff it out. I distinctly remember Google committing to The Microsoft EEE strategy with XMPP. We've left behind lots of great ideas in the last 20 years
Using & channels is fun, I'd be interested to see how many bots and clients fall over dead when faced with that particular bit of IRC history.
Put the issue context in a #channel and invite external parties/entities, bring the results back to the work.
I have tested it but the complexity didn't justify the results in my experiment. I couldn't get it accepted into Atlassian Marketplace, either.
* regular chats, existing only on the server, no leaking the chat transcript except via users, but never via server to server.
* chambers: a global chatroom, located at a server, maybe with a MQTT anyone could subscribe to.
This never left the early planning stages though, but I thought the segregation between federated chatrooms and regular chatrooms was of interest to keep in sync with IRC open but closed nature of chats.
Slack is a *different* bait and switch.
That doesn't answer the question.
How are you resolving things like... user name collisions when the servers reconnect?
With Parley, where anyone can bring their own instance, and they are not guaranteed to not to be malicious, that could be an interesting issue to solve.
Although it must wreak havoc on many IRC clients, since the @ sign has a very specific meaning in the IRC protocol. :)
In this case, this is basically a poorly specified implementation of half of XMPP. Of course, I half expect the LLM would have mentioned that at some point, but the repository does not.
If you tell it to "build me an application X to do Y using programming language Z", it will comply.
If you interactively ask "I need X, can you suggest some options? use an existing product ? or build something using a library ? or build entirely myself ? can you suggest alternatives with pro's and con's ? Anything I should think of before deciding ?" then you will get an entirely different answer.
Maybe we need additional modes, aside from thinking mode, agentic mode etc. we need e.g. "sparring mode" ? or does such a thing already exist ?
In this case, it's just a waste of tokens as something not very unique was generated that doesn't have a real use case, or solves anyone's problem. As with many AI generated projects, I'm willing to bet that OP themselves will not using it any more in a month.
How you went from seeing somebody's post to deciding they don't care is a pretty big jump, one that isn't warranted. This kind of post seems like the old but now more elaborated form of hating on something that you don't even know what it is.
It just isn't fair to the work that has been put in.
IRC (real IRC) solves this by not solving it, and accepting that message order can differ between servers. If two operators kick each other on two different servers at the same time, usually both get kicked - the command is validated on the origin server and the rest of the network takes it as gospel, even if it doesn't make much sense in their own local state.
I don't know how it just happens that sending text messages to people can manage to result in specs that are painful to implement.
Can you provide more details here? I've never seen an issue with the protocol at all, more issues with feature difference between servers depending on what they have decided to implement or not.
My own preference goes to NOSTR, just a set of public/private keys as identity and nothing else needed.
Thank you for the reference to that project called anproto, never had heard of it and I'm still without understanding what problem it really solves. Seems to encrypt texts but then contains zero outside metadata to route it somewhere. The website is very scarce on details for someone unfamiliar the scuttle-something they mention.
There are dedicated profile notes which define which relays that account/identity prefers to send their messages but everything is flexible. It does forego much of the routing metadata, which in my opinion is an obstacle when you don't know which stations/relays are placed on a given geography but you want the message to "navigate" (sometimes quite literally) to a place/region.
For that type of things I'm a biased fan of https://xprs.dev because it bridges NOSTR identities/signing/encryption with APRS that can use store/forward and the routing follows any possible method include USB drives.
There's an example ANproto in use at https://wiredove.net it's pretty clean but not very active, yet another experimental social network playground!
Good protocols are opinionated and make concrete choices.
Extensibility typically leads to compatibility issues like the ones you are describing.
I think the protocol itself is... I mean it's fine, I guess? Protocols are tricky because a lot of stuff is bolted on and it's not really super stateless as a protocol. But like all the Python XMPP client libs (for example) are all real janky.
The protocol is complex enough to where the "simple and easy" client libs require way more up front design.
Considering I'd never hosted an XMPP daemon and didn't know anything about the protocol (I'd used XMPP clients a little bit, but had never looked at the protocol) and got a server (that part, I didn't write), an auth connector for our website's authentication system (so the daemon would authenticate against that instead), prod-ready and the features I wanted all working smoothly and reliably in maybe three weeks of very part-time work (this'd be, like, 3-4 part-time days with LLMs now, tops, from the same starting point)... seems decent to me? I mean I did direct work with the protocol, didn't just glue together libraries, and it was pretty damn good. Also (and I know browsers seem to be retreating on this front, which sucks) being XML made it very nice to work with in a Web context, since you can just ask the browser to turn ~any XML into a DOM for you, and get a bunch of functionality for free.
What's wrong with it?
This is what boggles my mind. We're talking: Text. Over the Internet. It should not be a complex, difficult problem! We've been sending text over the Internet from the moment the Internet went online. So how is it that 10 companies have managed to find 30 different ways to do it, which are all incompatible with each other? You have to TRY to fail this badly.
Come on, try! Start listing some of the core features of the different protocols/clients and answer your own question as to why it isn't simple! Presence. Chat history while offline. Threading. Mobile devices. Intermittent/mobile/cellular/wifi/CGNAT connectivity. Multiple clients on the same identity and presence. Identity establishing and confirming. Encryption. End-to-end encryption. Backing up and restoring chats, encrypted chats, group chats. Federation. Friends/groups/permissions/trust boundaries. Markup, markdown, formatting, images, emoji, unicode, code blocks. Audio, video, broadcast, multicast. Discovery. Extensibility. Federation. Store-and-forward.
> "We've been sending text over the Internet from the moment the Internet went online"
And IRC has RFC 1459, RFC 2810, RFC 2811, RFC 2812, RFC 2813, RFC 7194 and it does almost none of those things.
And you can still use IRC. But IRC is not good. At this point it's either wilfull ignorance of what people use computers for, or it's indistinguishable from deliberate trolling.
- opening threads in a new window is in some hard to find and hard to remember location
- threads can’t be inlined (like you’ve described). I actually like how they’re in a pane to the right but sometimes that causes issues (as you’ve described). Sometimes it’s just that the view is too narrow.
- there’s no way to shift non-threaded comments into the thread. I’ve lost count of the number of times conversations have happened over multiple threads and/or non-threaded replies.
The way they implemented it is a complete clusterfuck.
Ultimately the tech is only as good as the humans that use it. If you're chatting with folks that can't understand the difference between a thread or not, that's a meat-bag issue and not anything an RFC can fix.
I briefly entertained building a modern chat experience on top of IRC when I came to this realization.
It's valid that someone just wanted to build something like this for their own purposes.
The repository does not even mention this software is LLM-generated.
I wonder when/if the collective realization will land that LLM's failure to retain provenance during training means the code it generates exists in an indeterminate state of public domain / IP trap.
The system has broken under the noise.
That’s because it’s a paradigm shift, not meant to be planned or organized by humans. The prior paradigm was that there were subject-matter experts who were human. The new paradigm is that the only author of all code is to be a machine. This new paradigm requires removing all prior authors (who happen to be human), and removing them simply requires overcrowding their output such that it’s not locatable or trustworthy.
Sit back, grab some popcorn.
Half of that job was de-escalating real life abusers from abusing their victims who would constantly track them down through irc.
Whats the average age on there efnet and dalnet now? 50-70ss? Or did that cohort move on? All of the recent software chats I've seen have been on discord which is its own ball of worms.