|
|
|
|
|
|
by Meekro
684 days ago
|
|
|
Pretty interesting! I find these attempts to remake IRC fairly intriguing. I've read your description, and it's really cool how you've re-invented server-to-server routing. Unfortunately, it wasn't clear how services operate, though. Just a couple thoughts: 1. Is there still a benefit to having more than one server? My understanding is that IRC networks had multiple servers partially because because having >50k open network sockets was difficult on 1995-era UNIX-like operating systems. That's not really a problem anymore. I guess multiple servers is a way to achieve load-balancing and fault-tolerance for servers going down, though. But then again, the services database still has to exist somewhere, right? That's probably still a single point of failure? 2. From a user perspective, an IRC replacement ought to compete with Discord. That means support for posting images and videos, audio/video chat, offline history, easy switching between desktop and phone, deep and granular admin controls, etc. I'd love for there to be an open source & open protocol option here, but I'm terrified to even imagine an RFC that implements all of this in a way that works in practice. |
|
|
It's also not clear for us! We're considering using a regular replicated database backend with multiple service nodes accessing it. Making the service nodes replicate directly through the network is also an option.
> Is there still a benefit to having more than one server?
Good question. I'm not a staffer at Libera so I don't know, but they believe they need multiple servers. If nothing else, it keeps latency low between clients and servers no matter the client's continent.
> That means support for posting images and videos, audio/video chat, offline history, easy switching between desktop and phone, deep and granular admin controls, etc. I'd love for there to be an open source & open protocol option here, but I'm terrified to even imagine an RFC that implements all of this in a way that works in practice.
There are already specs for most of this stuff. Images and videos are through sharing URLs freely and there's https://github.com/progval/ircv3-specifications/blob/filehos... to tell client where they can upload media (I wrote it as a joke, but there are a couple implementations now???). Video/audio chat won't happen, because it's just too hard. https://ircv3.net/specs/extensions/chathistory for offline history already has a decent number of implementation. And easy switching is going to be tough but there has been work on it from https://soju.im/ (read markers, synchronizing PMs) that we can reuse.
"deep and granular admin controls" is probably going to be through non-standardized commands as is tradition, so servers can freely innovate and there isn't much to gain through standardization. https://github.com/ircv3/ircv3-specifications/pull/484 would help build GUIs for new custom flags, though.