4 ms·

As someone who's casually been eyeing up CRDTs for two years I've wondered continually what the story for authorization is, and this article seems to suggest (i

As someone who's casually been eyeing up CRDTs for two years I've wondered continually what the story for authorization is, and this article seems to suggest (in line with my own understanding) that a CRDT library on its own like Y.js can't really handle applications where mutations need to be checked for authorization because it lacks a central authority (i.e., the server) while Reflect assumes that a server will be mediating client interactions. Is this all correct?

hem777 3y ago
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.
foota 3y ago
CRDTs can still involve a server, just not necessarily in the middle of everything. Consider you could have connections authenticated by the server, for one. E.g., someone connects peer to peer to you and claims some privilege etc., you could use the server to verify their claim. Also, I don't think CRDT necessarily implies peer to peer, as you can use a central server for message passing, but keep the CRDT model for resolving the current state on both server and client.
aboodman 3y ago
"Can't" is a strong word. You can get auth with a CRDT with effort, for example you can put a server in the middle of everything and have the server reverse any changes it sees which are unauthorized. This ends up being a lot of work to maintain and easy to break as the application gets bigger, and it also defeats some of the benefits of the CRDT in the first place (now the server has to mediate everything and you can't have peer-to-peer sync). Also if there are side-effects of any actions which require auth which aren't undoable, then that gets more complicated. If you already have a server in the middle, it's a lot simpler to just use a protocol that allows the server to reject messages in the first place.
- alpyne 3y ago
  Any thoughts on this approach? (From the Local-First Berlin meetup in June) https://m.youtube.com/watch?v=pBvGeU7bL5A https://m.youtube.com/watch?v=pBvGeU7bL5A
  - aboodman 3y ago
    I think it sounds really cool. I love the p2p side of local-first. Lot to figure out to make it practical, but very glad people are working on that.

hem777 3y ago

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.

foota 3y ago

CRDTs can still involve a server, just not necessarily in the middle of everything. Consider you could have connections authenticated by the server, for one. E.g., someone connects peer to peer to you and claims some privilege etc., you could use the server to verify their claim. Also, I don't think CRDT necessarily implies peer to peer, as you can use a central server for message passing, but keep the CRDT model for resolving the current state on both server and client.

aboodman 3y ago

"Can't" is a strong word. You can get auth with a CRDT with effort, for example you can put a server in the middle of everything and have the server reverse any changes it sees which are unauthorized. This ends up being a lot of work to maintain and easy to break as the application gets bigger, and it also defeats some of the benefits of the CRDT in the first place (now the server has to mediate everything and you can't have peer-to-peer sync). Also if there are side-effects of any actions which require auth which aren't undoable, then that gets more complicated. If you already have a server in the middle, it's a lot simpler to just use a protocol that allows the server to reject messages in the first place.

alpyne 3y ago
Any thoughts on this approach? (From the Local-First Berlin meetup in June) https://m.youtube.com/watch?v=pBvGeU7bL5A https://m.youtube.com/watch?v=pBvGeU7bL5A
- aboodman 3y ago
  I think it sounds really cool. I love the p2p side of local-first. Lot to figure out to make it practical, but very glad people are working on that.