Rendered at 12:53:47 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Conlectus 26 minutes 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.
rixed 6 minutes 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...?
davidcollantes 2 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 45 minutes ago [-]
This is an AI-generated summary of TFA?
BonerWiener 4 minutes ago [-]
It's a copy paste of the readme intro. Don't know why it's left as a comment here
altilunium 2 hours ago [-]
can any layman user simply use it without running their own instance?
davidcollantes 2 hours ago [-]
Yes, you will need to know someone running an instance to create an account for you.
grim_io 2 hours ago [-]
So... no? :)
NoboruWataya 1 hours ago [-]
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.)
jagged-chisel 2 hours ago [-]
Yes, you can try it without running your own instance. You will need to use someone else's instance.
davidcollantes 2 hours ago [-]
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.
user2722 41 minutes 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 40 minutes ago [-]
That seems to be similar on this one. &room is local, while #room is federated.
singpolyma3 29 minutes 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 18 minutes 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.
aunderscored 1 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 40 minutes 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.
I quite like this, but it feels like spam could quickly become a concern.
davidcollantes 2 hours ago [-]
That is always a concern, yes. You can block users, and entire instances, that spam.
2 hours ago [-]
pixel_popping 18 minutes ago [-]
The connection to git.mills.io was interrupted while the page was loading.
davidcollantes 15 minutes ago [-]
Sorry, I am sure it is the HN effect.
padolsey 2 hours ago [-]
Both cool and worryingly convenient for the botswarms we've been warned of...
calvinmorrison 40 minutes ago [-]
I recall this bait and switch. It was called Slack
bigfishrunning 10 minutes ago [-]
Slack is pretty centralized, and also closed. You can't self-host at all.
Slack is a *different* bait and switch.
shreddit 2 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 40 minutes 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 2 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 1 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 52 minutes ago [-]
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.
okwhateverdude 2 hours ago [-]
lol, so XMPP, but instead of XML, it is IRC. Alright, I dig it.
singpolyma3 27 minutes ago [-]
Instead of TCP+XML it's HTTP+JSON
The IRC is just a front end. Could use any front end
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.
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.
(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.)
* 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.
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.
Slack is a *different* bait and switch.
It’s like email just for IM…
I didn't stop using it until I stopped caring about those chat services.
I do wish the Matrix client situation was less messy.
The IRC is just a front end. Could use any front end