3 ms·

Shameless plug for https://robustirc.net/ https://robustirc.net/, which is also written in Go, and solves netsplits (between servers, and also between client an

by secure 6y ago

Shameless plug for https://robustirc.net/ https://robustirc.net/, which is also written in Go, and solves netsplits (between servers, and also between client and servers when clients use the RobustIRC bridge or a compatible client) :)

dijit 6y ago
Had to check the authors file[0] to realise you're one of the authors. Wow! I'd like to say a resounding thanks. I've been looking at this system recently and I'm going to be including robust IRC access to my network (shameless plug[1]). The code is clean, I think I have a good understanding of how it works and from my testing it does seem to work really well! That said, have you looked at how much of your original problem space is solved by IRCv3? [0]: https://github.com/robustirc/bridge/blob/master/AUTHORS#L10 https://github.com/robustirc/bridge/blob/master/AUTHORS#L10 [1]: ircs://irc.darkscience.net:6697/darkscience
- secure 6y ago
  Thanks, I’m very glad to hear! I had looked at IRCv3 briefly when starting the project, but it looked like IRCv3 didn’t solve netsplits. Have I overlooked anything (or has something changed), or did you just ask out of curiosity? Keep me posted regarding how RobustIRC is going for your network!
  - microcolonel 6y ago
    > ...but it looked like IRCv3 didn’t solve netsplits Darned CAP theorem.
- slingamn 6y ago
  Clarification, I'm the one of the maintainers of Oragono [1], an IRCv3 server project, but I don't speak for IRCv3 as a whole. In fact, I think my take is somewhat controversial in the IRCv3 community. But here goes: 1. Most of the big problems with IRC as a protocol (nicknames, ghosting, missed messages) come from the assumption that the core of the network should be stateless. If the core of the network is stateless, you can't have nickname reservation, you can't transparently attach two clients to the same nickname, and you can't replay missed messages to people who were disconnected (hence the need for clients to maintain a TCP connection to the server at all times, hence netsplits being disruptive, etc.). 2. Conventional IRC setups solve some of these problems by adding a single privileged node, the "services framework" (Anope and Atheme are examples), that stores some persistent state (typically, nickname and channel reservations). This actually abandons the high-availability properties of the original IRC design: it is theoretically possible to design a highly available services framework (using a clustered database or whatever) but AFAICT none of the frameworks that currently exist are HA. 3. Oragono is a single instance that provides an integrated IRC server, services framework, and "bouncer" (history retention and playback). Client connectivity problems are solved by allowing transparent reattach to the original nickname after authentication with SASL, then automatically replaying history. (Client support for this is still patchy [2], but anything that supports znc.in/playback [3], like Textual, will work well; you can also configure Oragono to try and track what you missed and replay it on reconnection.) 4. To make Oragono highly available, it can be deployed in Kubernetes (virtualizing the embedded database file and the external IP, spinning up a replacement instance on failure). [1] https://github.com/oragono/oragono https://github.com/oragono/oragono [2] https://github.com/ircv3/ircv3-specifications/pull/393 https://github.com/ircv3/ircv3-specifications/pull/393 [3] https://wiki.znc.in/Playback https://wiki.znc.in/Playback

by secure 6y ago

dijit 6y ago

Had to check the authors file[0] to realise you're one of the authors. Wow! I'd like to say a resounding thanks. I've been looking at this system recently and I'm going to be including robust IRC access to my network (shameless plug[1]). The code is clean, I think I have a good understanding of how it works and from my testing it does seem to work really well! That said, have you looked at how much of your original problem space is solved by IRCv3? [0]: https://github.com/robustirc/bridge/blob/master/AUTHORS#L10 https://github.com/robustirc/bridge/blob/master/AUTHORS#L10 [1]: ircs://irc.darkscience.net:6697/darkscience

secure 6y ago
Thanks, I’m very glad to hear! I had looked at IRCv3 briefly when starting the project, but it looked like IRCv3 didn’t solve netsplits. Have I overlooked anything (or has something changed), or did you just ask out of curiosity? Keep me posted regarding how RobustIRC is going for your network!
- microcolonel 6y ago
  > ...but it looked like IRCv3 didn’t solve netsplits Darned CAP theorem.
slingamn 6y ago
Clarification, I'm the one of the maintainers of Oragono [1], an IRCv3 server project, but I don't speak for IRCv3 as a whole. In fact, I think my take is somewhat controversial in the IRCv3 community. But here goes: 1. Most of the big problems with IRC as a protocol (nicknames, ghosting, missed messages) come from the assumption that the core of the network should be stateless. If the core of the network is stateless, you can't have nickname reservation, you can't transparently attach two clients to the same nickname, and you can't replay missed messages to people who were disconnected (hence the need for clients to maintain a TCP connection to the server at all times, hence netsplits being disruptive, etc.). 2. Conventional IRC setups solve some of these problems by adding a single privileged node, the "services framework" (Anope and Atheme are examples), that stores some persistent state (typically, nickname and channel reservations). This actually abandons the high-availability properties of the original IRC design: it is theoretically possible to design a highly available services framework (using a clustered database or whatever) but AFAICT none of the frameworks that currently exist are HA. 3. Oragono is a single instance that provides an integrated IRC server, services framework, and "bouncer" (history retention and playback). Client connectivity problems are solved by allowing transparent reattach to the original nickname after authentication with SASL, then automatically replaying history. (Client support for this is still patchy [2], but anything that supports znc.in/playback [3], like Textual, will work well; you can also configure Oragono to try and track what you missed and replay it on reconnection.) 4. To make Oragono highly available, it can be deployed in Kubernetes (virtualizing the embedded database file and the external IP, spinning up a replacement instance on failure). [1] https://github.com/oragono/oragono https://github.com/oragono/oragono [2] https://github.com/ircv3/ircv3-specifications/pull/393 https://github.com/ircv3/ircv3-specifications/pull/393 [3] https://wiki.znc.in/Playback https://wiki.znc.in/Playback