Need help?
<- Back

Comments (97)

  • Conlectus
    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.
  • xena
    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?
  • singpolyma3
    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?
  • rixed
    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...?
  • aunderscored
    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.
  • davidcollantes
    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.
  • user2722
    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.
  • myaccountonhn
    I quite like this, but it feels like spam could quickly become a concern.
  • tonymet
    IRC is popular because it’s bad. I don’t believe there will ever be a replacement for this reason.
  • mococa
    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?
  • Marlinski
    Give me a day and I'll implement it in my agent-oriented IRC server https://github.com/marlinski/airc !
  • someonebaggy
    Vibecoded?
  • padolsey
    Both cool and worryingly convenient for the botswarms we've been warned of...
  • anon
    undefined
  • shreddit
    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…
  • jagermo
    is there a list of public instances one could join somewhere? I kind of want to dip into irc again. it was peaceful.
  • anon
    undefined
  • lnxg33k1
    But isn't IRC already federated?
  • pixel_popping
    The connection to git.mills.io was interrupted while the page was loading.
  • okwhateverdude
    lol, so XMPP, but instead of XML, it is IRC. Alright, I dig it.
  • calvinmorrison
    I recall this bait and switch. It was called Slack
  • elkamiliyoussef
    [flagged]
  • MMTlover
    [dead]
  • corbinvachal
    [flagged]
  • nahid-fahh
    [dead]
  • thomasreiminger
    [dead]