Etcdircd: an ircd backed by etcd(github.com) |
Etcdircd: an ircd backed by etcd(github.com) |
As you mentioned with traditional IRC during actual netsplit (not single node disconnecting, but two large networks separating) you will see two networks that will get out of sync with time. In this case (assuming it is implemented correctly) the etcd will just shut down and not allow anyone use it until netsplit ends.
Another issue here is that consensus protocols (raft, paxos etc) expect to have low latency. It doesn't make much sense distribute them geographically, and that will only result in a bad performance.
The biggest issue with Netsplits is getting out of sync, and the syncing back. Many networks solve this by ownership and channel/nick services.
I kind of like how IRCNet solved this problem without involving services:
- nick conflict - each user gets an unique numeric ID based on server id and connection id, this ID is guaranteed to be unique even during netsplit. On nick collision, servers just reset the nick to that ID
- channels - they actually had two solutions !channels which are designed in somewhat similar way, where it receives an unique ID and after netsplit one might end up with 2 channels with a different ID. Second solution is +R flag, which only works if there's no netsplit and if no one has an operator status it will grant one person matching one of the masks there.
I like that approach, because it tries to solve the problem without central authority, it's still arguable what is better.
[1] https://github.com/heyitsanthony/etcdircd/blob/master/securi...
User's of an IRC server deserve to know whether their operator has started recording messages, added or removed security features, or otherwise be free to review said code.
All chat software should be AGPL.
I don't understand how this is related - it's probably easier to tap messages outside of the software via packet capture or something than to modify the software to record them.
Also, someone who's interested in recording messages without user consent is probably also totally fine with violating the license.
https://www.cs.cmu.edu/~dga/papers/epaxos-sosp2013.pdf
EPaxos was published before Raft and I couldn't find any benchmarks comparing them directly, but in the paper above EPaxos outperforms Mencius (a rotating single leader design) even within a single EC2 cluster. And EPaxos maintains much more consistent performance during latency spikes. So EPaxos may help close the performance gap between LAN and WAN clusters. In the context of IRC where you're geographically distributed _anyhow_, something like EPaxos may impose no appreciable penalty at all, at least if there's sufficient redundancy to ensure a quorum.
Ah, the ambiguity of natural language. Just to make this absolutely clear: Raft is not an implementation of Paxos. The "like" here refers to the "electing a leader" bit.
(I assume you already know this, it's just that the sentence as written is ambiguous and I wanted to clarify. I initially read it the wrong way and felt an urge to 'correct' you.)