Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

Author of the talk here, ask me anything!


view as:

I'm not sure I understand this:

> Clients joining and parting channels and servers didn't have much state

State and state management is the main design problem at the heart of IRC. There's actually a lot of state considering that this is state that has to be replicated across all servers. (All servers have to know about all users currently connected)

Servers are connected in a spanning tree. All servers need to have the same state. State changes are initiated locally at each server and propagated through the spanning tree (which simplifies state propagation a lot). State changes take time to propagate, which means that servers will not have the same view of the world at any given time. Network partitions means the servers on each side of the partition have to forget all the state that belongs to the other side of the partition. When networks join conflicting state has to be resolved and there aren't really any good ways to do this.

Perhaps we have different views on "state". Perhaps you are talking more about the user experience and not the design challenges inherent in the low level design?

One thing that makes me very sad is that XMPP was such a pig's breakfast. It would have been really nice to have a messaging system backed by an IETF standard that wasn't infested with whatever technology was popular at the time of its creation.


> Perhaps we have different views on "state".

One of the common complaints I have heard about IRC is that there's no history if you're not connected (contrast to, say, Slack). In most cases I consider that to be a feature; one of my biggest complaints about the way many teams use Slack is that it becomes both a real-time chat system and the canonical state of truth about decisions and how they were made.

It's a little more work, but I would personally prefer if chat was used to discuss things, and then someone took the time to actually summarize the discussion and conclusion into a document somewhere. Maybe it's Markdown that goes into Git, maybe it goes onto a wiki, maybe it's just a long-form email that people can review at their leisure. But there's got to be some kind of better record than a disjointed Slack chat.


Legal | privacy