On 07/03/15 19:31, Ben Laurie wrote: > On 7 March 2015 at 18:18, Mike Hearn <[email protected]> wrote: >> It might eventually turn into Wave, then? Federated merge resolution with >> signatures sounds very Wave like. > > Yeah, it does. I worked with Wave for a while, which is why I have > reservations about the technique - it leads to some surprising > outcomes and makes some things that ought to be easy (like arithmetic) > impossible. >
For a private dynamic group chat, the merging requirements are not exactly the same as in a collaborative environment like Google Wave: - for a basic application, one does not *need* to merge arbitrary state. The only thing you need to merge is an unordered set (the membership set). - merging unordered sets is easy and a solved problem if you have full history. However, the fact that this set represents "who has permission to see what history" makes the problem hard again, in the context of the other constraints (secure, casually-consistent, decentralised). Merge algorithms require history, but if someone can't see past history (e.g. after joining) then they don't have enough information to execute the merge algorithm, nor to verify others' claimed merges. (This is not necessarily an impossible problem, and indeed is the "last missing piece" in the bundle of ideas I haven't yet written down.) Briefly skimming over their spec: http://matrix.org/docs/spec/ "The state of the room at a given point is calculated by considering all events preceding and including a given event in the graph. Where events describe the same state, a merge conflict algorithm is applied." My impression too is that they underestimate how hard this will be. Also, their security practises are questionable - they do have a list of threats in the spec, but there are no suggestions or even hints on techniques on how they will defend against these threats. I guess they will add this stuff in later, but as I'm sure everyone on this list knows, you can't just "add security later". It sounds like they just did the equivalent of adding partial ordering to a federated protocol similar to XMPP, using TLS "for security", and hoping that everything will be naturally straightforward to conceptually lock down as they write the code. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
