Project permission management

[YousefED]

Exploring different ideas on how we can implement "Projects": multiple documents with parent / child relationships and permission management.

Must have
User must be able to:

• create a project
• create new pages in a project
• create subpages of existing pages in a project
• move pages in a project to a different location in the project-tree
• share a project with other users

should have

• add pages to the project (or sub tree) that are not created in the scope of the project (i.e.: by a different user, or pre-existing pages). This probably means pages can have multiple parents
• share pages and subpages with users. Child pages should inherit permissions from its parent
• creating projects and moving documents should work offline, i.e. when not connected to matrix

Research re. Matrix permission management

Atm, we can set permissions for Rooms. Matrix has introduced Spaces, but is still figuring out authentication rules around this. Relevant MSCs:

• MSC3083: Restricting room membership based on membership in other rooms matrix-org/matrix-spec-proposals#3083

• MSC2962: Managing power levels via Spaces matrix-org/matrix-spec-proposals#2962

• alternative: MSC3216: Synchronized access control for Spaces matrix-org/matrix-spec-proposals#3216

• 3083 is about having permission to join a room, based on membership of another room. Note that this is only about joining, so this does not "kick" users when the permission is lost. (see this part)

• 2962 is about managing power levels via space / room memberships. Power levels only manage the actions a user is allowed to take. It's unrelated to memberships (joining / reading rooms), so it does not cover our scenario

• 3216 similarly is about power levels (not membership)

Summary: this is not covered yet by Matrix, and part if this (cascading room permissions) was at least identified in 3083.

Brainstorming possible fixes:

1. ensuring the permissions "one by one" when moving a room. Difficulties:
   -- Would need a separate way to track whether a user that has joined, has joined "via the old parent room's permission", or has been invited directly to the child room.
2. Password protecting rooms, and posting the password in parent room (Matrix doesn't support password protected rooms yet)
3. Matrix plugin / application service that manages these kind of permissions
4. Storing "child docs" inside the parent doc. Disadvantages:
   -- diverts from the "typecell model" (documents live as separate entities in a web"
   -- permissions not manageable per child doc
   -- loss of crdt based collaboration when moving child docs to a different parent

Other related challenges:

• if we store parent / child relationships in a document, how do we make sure they are in-sync with each other (avoid race conditions).

---

Maybe the most realistic option for now is to use a Space hierarchy and permission management from MSC3083. Later, we need to extend this (maybe with the help of Matrix folks) to make sure permissions are retracted when moving items to a different parent.

Challenges with this:

• make sure space hierarchy and document rels are in-sync. Ideally it would be possible to move documents around while offline, and sync up to matrix later
• at some point we should fix revocation, or warn the user when moving a document that user access is not revoked.
• How to make sure document power levels are in sync / copied?

[YousefED]

For v1, what happens when a child doc is added / moved:

• Set a parent relationship on the child doc
• Set a child relationship on the parent doc
• Remove child relationship on previous parent doc
• Set the membership access of the child doc using MSC3083

How do we make this atomic / resilient?

When changing a parent:

1. update parent.child
2. update child.parent, remove oldParent.child

We could make a "reactive" system with the following rules.

a. when parent.child exists, make sure child.parent exists (if not, update child.parent and remove oldParent.child)
b. when child.parent exists, make sure membership is ok

This breaks however, when a different client checks step (a) from the perspective of oldParent. How does it know oldParent is "old"? This could be resolved using a relationClock=3, which indicates the version of the relation.

If step (b) fails (because user is offline). We should add the document to a local action-list so it will be loaded + synced + fixed next time we're online.

This approach might be ok for now. Further issues:

• what happens when we create a "parent loop" (https://www.figma.com/blog/how-figmas-multiplayer-technology-works/#syncing-trees-of-objects)
• what if we have more backreferences (e.g.: a document is linked from 1000 documents). How do we scale this?
• how do we make sync multiple rooms efficiently? --> matrix crdt should work with sync protocol