I wish people who write these posts would tell us, the RobustIRC authors, about it, and would ask us for proof-reading.

> For the entire duration of the partition, users on the smaller half will be paralyzed

No. RobustIRC nodes that are not part of the majority will cancel long-running GetMessages requests and refuse any other requests. The client will switch to a different node.

This is even mentioned as a possibility in a later paragraph:

> I’ll leave the reader to think through some scenarios, such as establishing a temporary domain of consensus on the smaller half, or forcing users to reconnect to the larger half.

Given this piece of information, I’m not sure what the article’s point really is. At least for the current deployments, the RobustIRC design works well in practice. Sure, strictly speaking, RobustIRC cannot _entirely_ eliminate unavailability (nothing can), but in practice you can work around unavailability really well.