Skip to content

Implement contexts and kd#self permission #41

@corrideat

Description

@corrideat

Problem

Invite creators should be able to delete invites they themselves create, but not other invites.

Invite 'managers' (those with such a permission) should be able to delete any invites.

Solution

To make this work, we add a field to OP_KEY_ADD called context. Where permissionsContext is an array of strings of MAX_LEN.

Every group member has a key with the following permissions:

  • ka
  • kd#self - New special permission that indicates keys created by this key can be deleted by this key

And a permissionsContext of ["invites"]. And a ringLevel of 5.

This lets any user create invites that they can delete.

Revoke other invites ("Revoke Invite permission")

Needs to be able to delete invites, but not other keys. So, this means we need to be able to identify invites.

Why don’t we just rely on ringLevel alone? Well, because if we did then that would actually complicate things, because this key would be able to delete all keys in all contexts of equal or greater ring level. And we just want this key to be able to delete all INVITES only, not all keys of equal or greater ringLevel.

We solve this with a context that applies to all invites, let’s call it the "invites" context and we make this permission a lower ringLevel.

Contexts vs Ring Levels

Think of the permissions system as a cone. The cone shape is the context. And how far down the cone you go is the ringLevel.

Or another way of thinking of it: all of the keys can be thought of as living in a pie. A context is the slice of the pie. And the ringLevel is how much of that slice you’re affecting.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions