<div dir="ltr">To try to summarize this thread so far, Michael proposed paring down requirements slightly, specifically allowing O(N^2) communication for each message and collision-resolution semantics, with the goal of keeping the protocol simple. Kurt suggests that the requirement of having a consistent total ordering on messages for everybody is the hardest goal left. Ximin suggests partial ordering with flags to indicate partial ordering to users. Moxie suggest that we can already do this with a simple protocol but the UI (threaded messages) is then too complicated for a small screen (Tom later provided some nice examples). <div>

<br></div><div>There appears to be a tension between UI from protocol complexity here. We can imagine designing a simple protocol that requires a baroque UI with messages threading and rejoining, or a very complicated protocol that allows a simple UI (linearized messages).</div>

<div><br></div><div>Personally I'd lean towards the latter approach. This seems to be what Michael's original thinking was, admitting a lot of messages and some latency to allow for a simpler UI in the end. Though it's definitely worth trying to design both cases, or consider if there's anything in the middle.</div>

</div>