Feature: Unified access control definition

[ShishKabab]

Motivation: When dealing with data accessible by multiple users, there needs to be some access control logic. In traditional back-ends, an application server has a knows which user is logged in and checks rights before modifying the database. BaaS like Firebase services tend to have their own way of specifying access control. When dealing with decentralization, either P2P or Blockchain, logic also must be defined, sometimes in a specialized language. However, there are common denominators of access control that can be distilled across all these platforms, allowing us to declare access control rules before deciding on a backend.

Design considerations:

• 90% of the use cases should be able to be done declaritively, 10% of specialized cases through code. This allows us to compile the logic into other languages, like Solidity for Ethereum, or custom formats for databases like Firebase.
• Some decisions can be made per-write, some on a higher-level storage logic layer. Somehow we must be able to integrate the two.
• Should be integratable with most application backend frameworks, like Express and Koa, and maybe even things in other languages

Questions:

• What are some of the logical components of access control mechanisms portable to these different backends? Identities, ownership, membership, sessions, groups, grants?
• How opinionated should this thing be of your data model?

Vague concept:

{
    project: {
        ownershipField: 'owner',
        membershipField: 'members',
        rules: [
            {role: 'owner', relationships: ['members'], grants: ['add_connection', 'remove_connection']},
            {role: 'member', fields: ['title', 'description'], grants: ['write']},
        ]
    }
}

Steps:

• [ ] Figure out common patterns in access control, and note them down here
• [ ] Define declaration structure
• [ ] Implement enforcer for Node.js back-ends
• [ ] Implement compiler for Firebase

[blackforestboi]

Terminology used:

• Collection: A list of items (pages, social posts, notes/annotations

Here are some use cases that we should foresee:

Prio 1 (everything that needs to work for initial version)

Backups & Sync:

• [x] Device(s) have read/write access to same sync log
• [x] Devic(s) have write delete access to log (delete entire log, in case of offered storage)

Collections:

• [x] Admin privileges (create subcollection, edit, delete items/collections)
• [x] Read privilege (view (sub)collections)
• [x] Read privilege to specific user
• [x] Read privilege to anyone with the link
• [ ] Subscription privilege (receive updates via push or pull)

Prio 2 (everything that needs to work for later (e.g. collaboration)

• [x] Edit privilege (add items to collection, delete from collection)
• [x] Add-only (use case for crowdsourcing things
• [ ] Comment-only (use case for having discussions about content)
• [ ] Privileges for specific user and/or anyone with the link

Open questions

• [ ] how to enforce deletions in a collaborative environment? In an offline-first environment anyone could just "keep" a post. How do we handle that?

[ShishKabab]

Thanks for the list, really useful :)

how to enforce deletions in a collaborative environment? In an offline-first environment anyone could just "keep" a post. How do we handle that?

We don't. There's no way to guarantee that everybody is really deleting data locally, ever, using any technology currently available. The best we can hope for is that they're using an unmodified version of whatever client they're using.

[ShishKabab]

Now included in https://github.com/WorldBrain/storex-pattern-modules