It wasn’t really that we wanted to have a CRDT per se, but as it was implemented on top of an op-based append-only log CRDT, it turned out to hold those properties, which makes it a CRDT. We wanted to have the edits to be able to arrive in any order or after delays due to network partitions (this was for a p2p network).
My non-techie brother has been staking his 1 ETH he bought couple of years ago and has earned today, in his words, “slightly more than from my insurance savings account in the past 10 years”. I think that’s a really nice use case.
One way to do authorization is to sign each operation/message and then verify the signature to match a public key in an access control list. This also enables CRDTs to work in a peer to peer context.
But as aboodman says in a sibling comment, if there’s a server as an authority, it can simply reject messages from unauthorized clients.
Accessing a “home computer” behind a NAT you don’t control or has a dynamic IP, eg. computers/devices that only have mobile connection and many (most?) broadband home connections.
> there are lww registers and multi-value registers
Use a single value register then in place where I said “register”.
> partition means that different subsets of nodes in a single system have different views on reality
Partition means that nodes of a (single) network are (temporarily) not connected.
In the example discussed here, blue and green were in different partitions thus had “different view” to the state. Once synchronized, their view on the state is consistent and both observe both values, blue being the latest state.
> is no longer represented in the history of v when the partition heals
Please review the above discussion again and the original article. You keep saying this but it’s shown in both that it’s is not true.
> there was a period of time where i observed v as blue, right? that observation was invalid.
Not invalid. The observation was correct at that time and place, meaning, in the partition that it was observed. This is the P in AP.
It seems to me that you’re talking about and arguing for synchronization, that is, consensus about the values (=state), which takes the system to CP as opposed to AP.
> there is no straightforward way to module "a value"
I would recommend to look into the “Register” (CR)data structure.
Can you elaborate what do you mean by this? I was arguing that it’s possible as the original argument was “this is not possible in a real system and is only theoretical”.
> provide no meaningful consistency guarantees to users, because they allows "committed" writes to be lost
If I set the (shared) value to green and you set it to blue, what is the expected observed value? What if you set it to green and I set it blue, what is the observed value? More importantly, what is the consistency that was lost?
> "correct primitives" do not by themselves provide a linear order of events
Review the description of Lamport Causal Clock in the article. Note that it carries “additional info” (additional to the example diagram). This “additional info” is what establishes the structure needed for total order.
> whichever concurrent updates you don't choose are lost, and that violates consistency
They’re not lost! The concurrent updates not chosen are still part of the “list of operations”, but the update to the data/value itself may not be observable if the subsequent update (the update that was sorted to be first) updates the same data/value (eg. both operations update the same key in a key-value structure). If the two operations update different data/value, then both updated values are observable. This isn’t cheating, rather it works exactly as expected: it is eventually consistent.