On 10/03/15 08:00, Joseph Gentle wrote: > Well, it depends what your use case is. If you just want group > messaging, that should be fine. (Hi! I worked on Google Wave back in > the day, helped opensource it at google and reimplemented a lot of the > tech in ShareJS.) > > Wave's federation protocol was super complicated because the algorithm > we used required a unique global ordering of all messages. Newer > algorithms (like CRDTs) don't need that. They just need a partial > order kind of like a git's commit log. Each commit (or message) > specifies the head(s) of the tree from that client's perspective. But > this only matters for collaborative data editing - as Trevor said, if > you just want to do federated messaging, clients can just pick a local > order for messages and (I think) it shouldn't matter much if two users > see slightly different histories. >
Hi! CRDTs sound very interesting. Do you have some links to good introductory papers/resources in this area? (You can assume I know how and why the git recursive/octopus algorithm works.) Has there been any research on merging when only *partial* history is available, even when different users have different subsets of the history? (Yes, I also agree that it's not a problem if two users see different topological orderings of the same partial order. This has been a point of contention with UI people in the past though. But my argument was that in a non-secure scheme you have no guarantees about ordering anyhow.) X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
