17 ms·
Your concern is that adding CRDT merge semantics somehow prevents a server from implementing access control? That's not the case. The Braid spec does not impe
by toomim 7y ago
Your concern is that adding CRDT merge semantics somehow prevents a server from implementing access control? That's not the case.
The Braid spec does not impede access control — that works just like it always has on the web. A client logs into a server. If a client does a GET request, the server decides whether the client can see the result. If a client does a PUT request, the server decides whether to allow it. The only difference is that these GET and PUT requests can now be broken into granular patches with a version history.
And if you want to build a peer-to-peer network, then you will replace the server with a validation function running on each peer, and authentication with a crypto scheme. But we aren't at the point of trying to standardize that stuff yet.
- sagichmal 7y ago> Your concern is that adding CRDT merge semantics somehow prevents a server from implementing access control? My concern is that this requirement means the state can't be encrypted. > if you want to build a peer-to-peer network, then you will replace the server with a validation function running on each peer, and authentication with a crypto scheme How do you break a GET request of some state blob into "granular patches" if the state is encrypted?