thoughtlede

6 ms·

31.
by thoughtlede 4y ago
Indeed, certain properties of CRDT are invariable to network state. However, it is worth pointing out that in ops-based CRDT “implementations”, you deal with local ops case differently from remote ops case. That is, while the properties are
32.
by thoughtlede 4y ago
Need more time to think this through. A few comments: 1. The problem space being solved in proof-of-history needs special mention. It assumes byzantine faults. (My article does not). 2. If I understood it correctly, the idea behind proof-of
33.
by thoughtlede 4y ago
Right. The flavors of Lamport clocks I stated in the article are used in CRDTs designs I studied. While CRDTs are eventually consistent, I wouldn't dismiss them as such without qualification. They are causal-consistent when offline and
34.
by thoughtlede 4y ago
Author here. Pleasantly surprised to see the article here. Some context behind the article. I studied CRDTs for a few months, and noticed that different CRDT designs use logical clocks in different and clever ways. And I haven't seen a
35.
by thoughtlede 5y ago
This is a gem, for me, for its conciseness: > Crossing a boundary from a pull system to a push system requires polling its state, and crossing a boundary from a push system to a pull system requires materialization of its state.
36.
by thoughtlede 5y ago
Interesting article. Two comments: 1. I have always thought of (eventual) consistency to mean consistency between replicas: how in-sync are the replicas in what they "store". Whereas, internal consistency as defined here seems to