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? :)

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

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

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.

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

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.

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

Vibecoded?

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.

I recall this bait and switch. It was called Slack

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.

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?

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.

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.

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.

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

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

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

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?