Fine-grained Permissions / Authorization

[MentalGear]

First off: Kudos for making this open-source library!

After searching the docs, I don't know how to set permissions in a way, for example, if a have a colab notes space, that certain notes would just be read-only for certain members, or not even displayed for others.

Is this possible with the current sweetness ? :P

[paulgb]

Thanks @MentalGear!

This isn't implemented yet, but I do want it in some form -- my current idea is that at the document level you would have either read-only or read/write permissions, and to do what you describe you would separately track who had access to what document and your backend server would obtain Y-Sweet document connection strings as needed depending on the user. Would that work for your use case?

One tricky thing with CRDTs is that permissions at anything more fine-grained than the document level are tough. Not strictly impossible, but definitely easy to mess up, whereas read-only should be pretty straightforward.

[MentalGear]

Thanks for the feedback. Seems like liveblocks is able to do it, but I'm not sure how. Maybe you have an idea what their implementation looks like?
https://liveblocks.io/docs/rooms/permissions/id-token

[hobo1618]

As far as I understand liveblocks doesn't use yjs or crdt other than for @liveblocks/yjs, but I could be wrong about that.

[paulgb]

Right, liveblocks uses a non-CRDT data structure for the main state sync. Although from what I can tell (from that doc), their permission model is still only as fine-grained as the room? In Y-Sweet's terminology a doc is the equivalent to their room, so I think doc-level read/write and read-only access would be the equivalent granularity to what they offer.

One difference from those docs is that Y-Sweet acts more like a document database that is decoupled from your user system, and expects the source-of-truth for who can access what to be your primary application server. With liveblocks, I think they price based on MAU, so they need to have a first-class concept of users.

[MentalGear]

Great input! A central auth/permission system would be alright for me. I'd think a naive approach would be to check, before a new dataset is send from the server to a client, to see if the client's id/role/group (jwt token?) does overlap with a custom property on the data.

But I'm not sure, if the data send by the server a op, how this can be done.

I also found, crdx

As I'm just getting started with Y.js / CRDTs / colab, I'd appreciate your advice. :)

[paulgb]

At least a preliminary version of this, read-only document-level access, is now on the roadmap (#307). With subdocument support (#308), which is also on the roadmap, this will extend to enabling read/write permissions on a per-subdocument basis, which is consistent with how Yjs intends for this to be implemented.