Parley: Federated, decentralised chat that speaks plain IRC (git.mills.io)

281 points by davidcollantes 12 hours ago

advisedwang 2 hours ago

> No channel modes and no channel operators, which is a decision rather than a gap: a global channel is owned by nobody, so there is nobody to be an operator of it. Blocking is per person and per instance instead

That's completely unworkable. Lets say I create #some_minority, and people from many different servers join. Some shithead comes and starts screaming slurs at us. Now the admin for every server must block that person. Multiply that by every channel, and every admin is responsible for moderating the entire ecosystem. The only way they can do this is with shared blocklists, which have been a nightmare on mastodon.

xingped an hour ago

If this is really distributed, then off the top of my head I imagine you could possibly make some sort of reputation-based filter list wherein trusted admins can subscrbe to each other's filter lists such that when one admin blocks are user, it quickly propagates to other admins' lists. Somewhat similar to how email domain spam block lists work.

conorcleary 2 hours ago

[seemingly negative thing] which is a decision (after hindsight), rather than a gap [scope creep]

blamestross an hour ago

Ownership of namespaces is such a hard problem, our society has had to form global organizations and some of our most secure distributed systems to make it happen.

Working in the p2p space, scalable namespace ownership that doesn't get instantly ruined by perverse incentives is the holy grail. I don't think it is actually tractable in any "central authority free" system. Don't get me started on blockchains that tether names to the most perverse systems available and call it victory.

edflsafoiewq 2 hours ago

> which have been a nightmare on mastodon

Why?

advisedwang 14 minutes ago

I get the impression that every attempt to make block lists ends up getting used to target people an admin of the block list doesn't like. I think the root of it is that the admins consuming the blocklist don't want to have to spend time on moderation and are remote from communities where the blocklist is happening. Also the scope of the blocklist is the instance. Compare that to community internal moderation (e.g. channel mods), where someone close to the community is invested in the health of the community and the scope of the block is the relevant community.

conorcleary 2 hours ago

gestures broadly is going to be one of the common answers from anyone trying to ward off spam

xena 9 hours ago

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?

arm32 7 hours ago

That sounds pretty load-bearing.

y-curious 6 hours ago

Actually it’s a footgun gate

Retr0id 2 hours ago

malcolmxxx 7 hours ago

And then, all galaxies move away from us.

cromka 9 hours ago

This is why we can no longer have nice things...

warkdarrior 28 minutes ago

Online communities are meant to be pharmed..

plq an hour ago

Haha so this project speaks IRC, no less :) This is surely relevant then: https://www.mirc.com/split.html

stinkys 23 minutes ago

Internet drama was so much better back then.

singpolyma3 10 hours ago

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?

davidcollantes 10 hours ago

Bans are per server (for what I have seeing). Federated rooms continue to exist if a server drops off, as no server "owns" them.

esseph 9 hours ago

> Federated rooms continue to exist if a server drops off

That doesn't answer the question.

How are you resolving things like... user name collisions when the servers reconnect?

davidcollantes 9 hours ago

pferde 8 hours ago

stackghost 3 hours ago

Relearning the lessons from the old days, I see. This situation is what created the Eris-Free Network.

threecheese 3 hours ago

Is anyone leveraging IRC/XMPP/etc for agents or A2A communication? It seems like a natural fit; all the "human agents communicating" abstractions and underlying technology pieces are in place and mature, as are methods for dealing with unruly actors.

I've wondered why I haven't seen this everywhere.

ciaranmca 2 hours ago

Oh my pi does it, not sure if that’s something from upstream or just a fork feature but from my experience it seems to work well

davidcollantes 12 hours ago

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.

someonebaggy 10 hours ago

This is an AI-generated summary of TFA?

BonerWiener 9 hours ago

It's a copy paste of the readme intro. Don't know why it's left as a comment here

xena 9 hours ago

theandrewbailey 8 hours ago

altilunium 12 hours ago

can any layman user simply use it without running their own instance?

davidcollantes 12 hours ago

Yes, you will need to know someone running an instance to create an account for you.

grim_io 11 hours ago

davidcollantes 11 hours ago

Conlectus 10 hours ago

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.

dale_glass 9 hours ago

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.

monkeywork 8 hours ago

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

packetlost 8 hours ago

nunobrito 7 hours ago

dale_glass 8 hours ago

throwawayffffas 6 hours ago

oooyay 6 hours ago

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.

thinkmassive 5 hours ago

bilekas 4 hours ago

radlad 5 hours ago

alwaysthiserror 8 hours ago

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?

pmlnr 6 hours ago

ryandrake 8 hours ago

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

jodrellblank 7 hours ago

bityard 6 hours ago

edhelas 8 hours ago

Why is it terrible?

segmondy 9 hours ago

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.

jeremyjh 9 hours ago

That’s where we’d expect a mention in the README to play a part.

aidenn0 8 hours ago

dewey 9 hours ago

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.

orangedog 9 hours ago

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.

dlkasajiewo 8 hours ago

MisterMunchkin 8 hours ago

If telling people “build me an app” with no knowledge of technology worked, project managers would be good at their jobs already

RGS1811 9 hours ago

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.

sugarkjube 9 hours ago

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 ?

chrisweekly 8 hours ago

jeremyjh 9 hours ago

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.

j45 8 hours ago

RunSet 7 hours ago

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

Revanche1367 4 hours ago

The AGENTS.md file in the repo with its contents is a pretty clear giveaway though.

j45 8 hours ago

LLMs could be asked to research extra projects.

It's valid that someone just wanted to build something like this for their own purposes.

Forgeties79 8 hours ago

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.

j45 8 hours ago

general_reveal 6 hours ago

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

Sit back, grab some popcorn.

PunchyHamster 9 hours ago

XMPP is massively bloated protocol that is badly managed for last 2 decades

edhelas 8 hours ago

And what are you suggesting as a non-bloated and better managed alternative? :)

nextaccountic 7 hours ago

acedTrex 7 hours ago

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.

The system has broken under the noise.

flymasterv 5 hours ago

I'm searching for a simple, self-hosted chat system that allows me to host unlimited bots and send messages (with notifications) to my iPhone easily.

I currently have an XMPP server running, which is fine, I guess. I've looked into chatMail. I have considered hosting an IRC server.

At this point, I'm considering just setting up my own NTFY server and writing a chat client for it.

Does anyone have any ideas for what the lightest weight, simplest solution might be?

mxuribe 5 hours ago

Curious, why the interest in building your own ntfy client (instead of using the one already built/available)?

By the way, for years now, i have used a little python (cli) app to send messages into a private matrix room. This room has 2 people in it: me and a bot. (The bot is simply the matrix account that sends the messages.) I went this route because i did not want to install another app - such as ntfy - on my mobile simply to receive server notifications, etc. And, since i had ben on matrix already chatting with friends, it happened to be a low-effort approach. To clarify, i am no longer self-hosting my own synapse home server...so i'm simply piggybacking on the matrix.org one...but that has helped at least unify my notifications and comms to a good degree.

Now, if you were to aske me to implement my "notifications system" via a different approach, funny enough, i would gauge between XMPP and ntfy to see which is lighterweight....because i believe them to both be quite light on the need for resources. I don't know which is lighter (sorry, i know i'm not answering your question). however, i *think* the ntfy server is less hasle....Only because xmpp takes a little more work to setup...at least that was my experience a couple of years ago. I cast no shade on either xmpp nor ntfy - because to me boh are awesome...i' m merely saying that resources needs aside, i wonder if ntfy might need less time from YOU.

flymasterv 3 hours ago

I'd build my own NTFY client to enable two-way chat. It's not something I'm seriously considering, because it's obviously a bad idea, but that's about where I am.

rough-sea 5 hours ago

you should look at celld

stackghost 3 hours ago

>I'm searching for a simple, self-hosted chat system that allows me to host unlimited bots and send messages (with notifications) to my iPhone easily.

I do this with IRC. I used to have a blog post up about it, back when blogs weren't just training data providers for LLMs, but I'm afraid it's been deleted.

tl;dr IRC works great, but you need to wire up push notifications. For android I used pushbullet, for iOS I am still evaluating the alternatives but pushover looks okay. IRC itself is nice because the protocol is shit simple, to the point that if you can type fast enough to respond to the pingpongs you can cosplay as a bot using nothing but telnet. As a text protocol it's easy to inspect and doesn't require binary decoding of packets for debugging.

I recommend the Ergo ircd. It ships as a single binary (golang), can support tens of thousands of clients, is at the forefront of the ircv3 modernization initiative, and is under active development.

aunderscored 11 hours ago

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.

someonebaggy 10 hours ago

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.

aunderscored 9 hours ago

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.

someonebaggy 20 minutes ago

user2722 10 hours ago

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.

Fastidious 10 hours ago

That seems to be similar on this one. &room is local, while #room is federated.

user2722 9 hours ago

Did not see that. Thanks for pointing that out! Will re-read the page.

myaccountonhn 11 hours ago

I quite like this, but it feels like spam could quickly become a concern.

davidcollantes 11 hours ago

That is always a concern, yes. You can block users, and entire instances, that spam.

someonebaggy 10 hours ago

Vibecoded?

bigfishrunning 9 hours ago

clearly.

nateb2022 2 hours ago

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.

rixed 9 hours ago

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

RobotToaster 9 hours ago

Or matrix

WorldMaker 6 hours ago

A lot of the design reads like almost but not quite ActivityPub.

ad_fontes 5 hours ago

This is pretty much just a reinvented Matrix protocol. Nearly identical.

mxuribe 4 hours ago

To be fair, if i recall correctly, some of the folks who started up matrix protocol (and associated project) came from/and loved the IRC world (e.g. the rooms concept, etc.)...so it stands to reason that matrix and irc have at least some *conceptual* similarities, and hence other stuff that spins off from or leverages IRC may also appear similar to matrix.

Marlinski 10 hours ago

Give me a day and I'll implement it in my agent-oriented IRC server https://github.com/marlinski/airc !

itomato 9 hours ago

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.

padolsey 11 hours ago

Both cool and worryingly convenient for the botswarms we've been warned of...

mococa 9 hours ago

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?

Klonoar 4 hours ago

> "Scrollback that follows you rather than your client"

This form of LLM speak annoys the absolute shit out of me. It's a bot trying to emulate the worst reassuring sales copy you could imagine.

shreddit 11 hours ago

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…

zaik 10 hours ago

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.

yvdriess 11 hours ago

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.

Athas 11 hours ago

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.

doubled112 10 hours ago

jagermo 9 hours ago

is there a list of public instances one could join somewhere? I kind of want to dip into irc again. it was peaceful.

davidcollantes 9 hours ago

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.

sailfast 6 hours ago

Parlay?

tonymet 7 hours ago

IRC is popular because it’s bad. I don’t believe there will ever be a replacement for this reason.

lnxg33k1 8 hours ago

But isn't IRC already federated?

davidcollantes 8 hours ago

You can link servers (Libera, for example, has many), but they are not federated, nor decentralised (services are used for registration, etc.).

ptman 6 hours ago

Closed federations. Only trusted servers

pixel_popping 10 hours ago

The connection to git.mills.io was interrupted while the page was loading.

davidcollantes 10 hours ago

Sorry, I am sure it is the HN effect.

okwhateverdude 11 hours ago

lol, so XMPP, but instead of XML, it is IRC. Alright, I dig it.

singpolyma3 10 hours ago

Instead of TCP+XML it's HTTP+JSON

The IRC is just a front end. Could use any front end

okwhateverdude 4 hours ago

I see. So more similar to ActivityPub.

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

singpolyma3 2 hours ago

calvinmorrison 10 hours ago

I recall this bait and switch. It was called Slack

bigfishrunning 9 hours ago

Slack is pretty centralized, and also closed. You can't self-host at all.

Slack is a *different* bait and switch.

0x1bparty 8 hours ago

Different use case no? I thought slack was enterprise focused from day one.