cloudpeers / tlfs

The Local-First SDK
https://cloudpeers.co
MIT License
64 stars 3 forks source link

Permissions as tree #93

Open rklaehn opened 2 years ago

rklaehn commented 2 years ago

When implementing join, I can do many things using very fast radix tree ops. E.g. removing expired from the store can be done with a single tree op instead of a loop.

E.g. this loop

        for buf in causal.store.iter() {
            let path = buf.as_path();
            if !self.expired.contains_prefix(path) && !causal.expired.contains_prefix(path) {
                if !self.can(peer, Permission::Write, path)? {
                    tracing::info!("join: peer is unauthorized to insert {}", path);
                    continue;
                }
                self.store.insert(&path);
            }
        }

can be turned into this:

        let mut store = causal.store.clone();
        store.tree_mut().remove_prefix_with(&self.expired.tree());
        store.tree_mut().remove_prefix_with(causal.expired.tree());
        for buf in store.iter() {
            let path = buf.as_path();
            if !self.can(peer, Permission::Write, path)? {
                tracing::info!("join: peer is unauthorized to insert {}", path);
                continue;
            }
            self.store.insert(&path);
        }

However, operations that involve permissions at present still involve querying permissions for every path.

It would be quite useful if we had a way to produce a tree for a permission and a peer, and then perform bulk operations for that tree. This would not change except when permissions are changed.

E.g.

let writeable = self.writeable(peer, Permission::Write);
store.tree_mut().retain_prefix_with(&writeable);
rklaehn commented 2 years ago

So the Acl contains all the info to decide permissions questions, and it is already a tree.

Currently it is doc.peer.<path> => Rule, right?

dvc94ch commented 2 years ago

Sounds about right

rklaehn commented 2 years ago

Any particular reason it is doc.peer and not peer.doc? It seems that peer.doc.path. would be closer to how the paths are modeled in the store.

dvc94ch commented 2 years ago

Don't recall. If there was a reason it needs to be reevaluated now anyway.

rklaehn commented 2 years ago

So looking at it some more, it seems the reason to have doc first is to be able to subscribe selectively to a doc.