Thank you for trying it! You should also post this to the Issues on the repo. I'd like to get some more details though... On Keys: keys are unique, meaning the

Thank you for trying it! You should also post this to the Issues on the repo. I'd like to get some more details though... On Keys: keys are unique, meaning they can only point to one thing. When you "forced" it to write to the same key, you changed references, your previous data is still stored, but you'll only be able to find it by looking it up by its soul (its ID) or by scanning for it. Were you experiencing something different than what I just mentioned above? On Network Partition: The clients store their updates in LocalStorage before they send the peers the update or get an ACK. What caused those peers (tabs) to lose their data? For clock skew, please see this reply: https://news.ycombinator.com/item?id=9077969 https://news.ycombinator.com/item?id=9077969 . Most "last write wins" algorithms require a centralized server (a Single Source of Truth) or they diverge on separate machines. That doesn't happen with GUN, you have no SST and they converge (even if it "looks" like last write wins) on both machines in an eventually consistent manner. I'd like to follow up with these things, either here, over email mark@gunDB.io, on the gitter chat, or on github.