> Timestamps are bad, yes (I mention this in the talk as well), GUN uses a hybrid vector/timestamp/lexical CRDT. Lets take your analogy "updating Y when someone

> Timestamps are bad, yes (I mention this in the talk as well), GUN uses a hybrid vector/timestamp/lexical CRDT. Lets take your analogy "updating Y when someone else sees X", a perfect example of this is realtime document collaboration (gDocs, etc.). Even with GUN, you'd not want to have the collaborative paragraph as a value on a property in the node. Each value is treated as atomic, which if two people write at the same time would cause what you are saying: them to overwrite each other. Instead, we can preserve the intent by running distributed linked list (a DAG, actually) on gun, this works quite nicely. See: This is actacly my point. And GDocs is a perfect example of what _I_ mean. The Wave protocol (and operational transforms in general), or I guess they use a decedent of it now, was made for exactly these types of use-cases so that you don't loose data unexpectedly when editing values. > Or alternatively, if you just want users to be informed of the conflict such that they can decide, it is trivial to store both updates and then present them with the conflicting values to choose from, which it then saves. > Does that make sense? Do you see/have any problems with those approaches? Thanks for your input so far. How is it trivial? Do you have array-value types? What's trivial about it? And yes, I do have problems when the default conflict resolution method is to simply select a value and toss the other out. It's a bad default. You have a default that causes data loss, it _will_ come back to bite you. This is perhaps the most egregious thing and honestly makes me have 0 trust in your system. > Lets be clear here, there is a big difference between Master-Slave systems and data guarantees. Databases like Cassandra have better data availability guarantees because they are HA (and gun is the same), despite not being Master-Slave. I never mentioned master-slave. You can set up most SQL databases to be async- or sync- master-master. > You can also reduce your bandwidth costs by having edge peers distribute data to their nearby peers, versus always having to pull from your data center. Aka, the Bittorrent model. Maybe I'm not sure what you mean by edge here. Do you mean it in the CDN sense, or in the client sense? If you're expecting your clients to be part of your DR scheme, I'm sorry, but that's moronic. You can't guarantee client availability. You can't guarantee that all available clients will even have a copy of all data. Sure, it's great that you're using the same protocol between servers, but you can't say that because of that clients can be part of DR.