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.
Presumably if the protocol becomes popular you will have public instances that anyone* can sign up to, the same way other federated services work now.
(It's approximately as hard for a layman user to sign up to a Mastodon instance as it is to sign up for X. The fact that most layman users don't do that is a separate issue.)
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 used Bitlbee until not that many earth rotations ago - it's an IRC daemon that provides bridging of various other chat protocols. It worked way better than you would expect, especially back in the day when you could use XMPP to connect to the various proprietary chat services.
I didn't stop using it until I stopped caring about those chat services.
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.
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.
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.
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.
Most times I've seen complaints about it, it boils down to "XML being yucky" and the extension component model being difficult to write clients for, which is true but not really a fault of the protocol, it's more of an inherent tradeoff of supporting opt-in extensions at all
* It's hard to even parse, XMPP uses an uninterrupted XML stream.
* The contents are often baroque and complex
* Standards are a mess, and stuff that should be in core isn't
* Data loss is possible
* Protocol wasn't made for mobile devices
* Multiple devices are terribly supported
* Data loss is possible
From my attempts long ago, and other testimonials, writing an XMPP client is a full time job of solving weird problems that shouldn't exist in something better designed.
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.
But it's not just for their own purposes. They shared it with the public which means they will get feedback, good and bad. No one forced them to post to HN.
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?
Parley is a chat network with no centre.
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.
can any layman user simply use it without running their own instance?
Yes, you will need to know someone running an instance to create an account for you.
So... no? :)
Yes, you can try it without running your own instance. You will need to use someone else's instance.
Presumably if the protocol becomes popular you will have public instances that anyone* can sign up to, the same way other federated services work now.
(It's approximately as hard for a layman user to sign up to a Mastodon instance as it is to sign up for X. The fact that most layman users don't do that is a separate issue.)
If you (top and child commentator) want to try without running your own, please send me an email: david dot collantes at gmail dot com.
This is an AI-generated summary of TFA?
It's a copy paste of the readme intro. Don't know why it's left as a comment here
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 quite like this, but it feels like spam could quickly become a concern.
That is always a concern, yes. You can block users, and entire instances, that spam.
This is exactly what i was thinking about for the last few weeks (but am too stupid to implement myself).
It’s like email just for IM…
Many earth rotations ago, I was IMing through an mIRC bot because I refused to install MSN. This kind of reminds me of that too.
I used Bitlbee until not that many earth rotations ago - it's an IRC daemon that provides bridging of various other chat protocols. It worked way better than you would expect, especially back in the day when you could use XMPP to connect to the various proprietary chat services.
I didn't stop using it until I stopped caring about those chat services.
These days I run a Matrix home server with bridges to Slack and WhatsApp so I can use fewer chat clients.
I do wish the Matrix client situation was less messy.
You're in luck: Some people already thought of this, submitted an RFC to the IETF and implemented it. It goes by the name XMPP.
Both cool and worryingly convenient for the botswarms we've been warned of...
lol, so XMPP, but instead of XML, it is IRC. Alright, I dig it.
Instead of TCP+XML it's HTTP+JSON
The IRC is just a front end. Could use any front end
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.
Give me a day and I'll implement it in my agent-oriented IRC server https://github.com/marlinski/airc !
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.
Vibecoded?
clearly.
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.
That seems to be similar on this one. &room is local, while #room is federated.
Did not see that. Thanks for pointing that out! Will re-read the page.
I recall this bait and switch. It was called Slack
Slack is pretty centralized, and also closed. You can't self-host at all.
Slack is a *different* bait and switch.
Different use case no? I thought slack was enterprise focused from day one.
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?
Bans are per server (for what I have seeing). Federated rooms continue to exist if a server drops off, as no server "owns" them.
That doesn't answer the question.
How are you resolving things like... user name collisions when the servers reconnect?
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.
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 ?
Matt Pocock's skills library includes "grill-me" which is precisely this. It's excellent.
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.
If telling people “build me an app” with no knowledge of technology worked, project managers would be good at their jobs already
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.
That’s where we’d expect a mention in the README to play a part.
https://www.bitlbee.org/
XMPP is massively bloated protocol that is badly managed for last 2 decades
And what are you suggesting as a non-bloated and better managed alternative? :)
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.
Why is it terrible?
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.
Most times I've seen complaints about it, it boils down to "XML being yucky" and the extension component model being difficult to write clients for, which is true but not really a fault of the protocol, it's more of an inherent tradeoff of supporting opt-in extensions at all
Other people provided some info:
https://news.ycombinator.com/item?id=9772968
https://news.ycombinator.com/item?id=31133082 (article and discussion)
But TL;DR:
* It's hard to even parse, XMPP uses an uninterrupted XML stream. * The contents are often baroque and complex * Standards are a mess, and stuff that should be in core isn't * Data loss is possible * Protocol wasn't made for mobile devices * Multiple devices are terribly supported * Data loss is possible
From my attempts long ago, and other testimonials, writing an XMPP client is a full time job of solving weird problems that shouldn't exist in something better designed.
Regarding the part part: https://www.process-one.net/blog/stop-telling-us-xmpp-should...
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.
What's wrong with it?
LLMs could be asked to research extra projects.
It's valid that someone just wanted to build something like this for their own purposes.
But it's not just for their own purposes. They shared it with the public which means they will get feedback, good and bad. No one forced them to post to HN.
Agreed, and the vast majority of personal projects that are released as open source don't get attention, traction, or contributions.
In this case, someone shipped something that works for their use case, which is a great deal more than talking.
The connection to git.mills.io was interrupted while the page was loading.
Sorry, I am sure it is the HN effect.
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...?
Or matrix
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?
is there a list of public instances one could join somewhere? I kind of want to dip into irc again. it was peaceful.
The idea (what's encouraged) is that's so simple you can run it yourself. If you email me (email on profile), I can create an account for you on mine.
How do you plan to handle bad actors creating biblical amounts of servers dynamically and then spamming at line rate from all of those servers?
This is why we can no longer have nice things...
But isn't IRC already federated?
You can link servers (Libera, for example, has many), but they are not federated, nor decentralised.