Permissions

Design proposal. It's not as simple as I hoped, but I it's the simplest I could come up with that doesn't require hacks for any of our requirements.

Permissions are static, hard-coded identifiers that identify specific actions. Currently, I think we need the following (taken from current examples with a few clarifications):

world:view
world:update
world:announce
world:secrets
world:api
world:rooms.create
world:permissions
room:announce
room:view
room:update
room:delete
room:chat.read
room:chat.join
room:chat.send
room:chat.invite
room:chat.moderate
room:bbb.join
room:bbb.moderate

Roles

Roles represent a set of permissions in relation to either a room or a world, there are therefore world roles and room roles. I'd like to implement roles in a way that makes them user-defined in the distant future, but for now I think we can get away with a set of default rules and no interface to change them.

Every world starts out with the following roles:

user = {world:view}
creator = {world:rooms.create}
moderator = {world:announce}
admin = {world:update, world:permissions, world:secrets}

Every room starts out with the following roles:

viewer = {room:view, room:chat.read}
participant = {room:chat.join, room:chat.send, room:bbb.join}
room_creator = {room:update, room:delete, room:chat.invite}
speaker = {room:bbb.moderate}
moderator = {room:announce, room:chat.moderate, room:bbb.moderate}
admin = {room:update, room:delete}

Explicit grants

A role can be granted to a user explicitly. These could be granted through an admin interface, but in the near future I imagine them mostly being created dynamically through people creating private rooms and inviting others.

User #1234 is granted
  - role room_creator on private room 1, because they created it
  - role participant on private room 1, because they've been invited
User #4345 is granted
  - role speaker on workshop room 1, because they've been granted the role by an admin
User #4345 is granted
  - role wold:announce on the world, because they've been granted the role by an admin

Implicit grants and traits

A room or the world can contain grants that implicity assign roles to users based on traits, arbitrary strings contained in their authentication information. Such implicit grants could look like this:

Everyone is granted
  - role user on the world
  - roles viewers and participant on room 1
Everyone with the trait "pretix-product-1234" is granted
  - roles viewers and participant on room 2
Everyone with the trait "pretalx-speaker-room-3" is granted
  - role speaker on room 3

Ban / silence

I think we should handle banning / silencing separately, as proposed in #14. I believe implementing it as a role or permission (e.g. room:banned) or the lack of a permission (through some kind of "negative" grant?) would make the whole concept much harder to understand and implement than having two separate concepts for it.

Config format

Not touching on actual database design, but just for illustration purposes, the config of a room or the world (with roles and implicit grants) could look like this:

"roles": {
  "viewer": ["room:view", "room:chat.read"],
  "participant": ["room:chat.join", "room:chat.send"],
  …
},
"grants": {
  "viewer": ["pretix-product-1234"],
},

Open questions

Roles add a level of indirection that's not strictly required, we could work on explicit and implicit grants directly (especially if we don't want to expose roles early on), but it would be much harder to configure manually, and I believe it would make migrations harder if we add more permissions going forward.
I'm not sure if we should have "inheritance" of permission, e.g. if it should be possible to set room:update on all rooms through a world-level role. Not having that possibility would make it way simpler to understand who can do what, but would also mean we always have role and grant definitions on every single room, instead of just having them there if we actually need different configurations for rooms.
This is way to much complexity to show to users in a "create room" dialog, so we'd probably have two presets there for the start, "public rooms" and "private rooms", but is that enough? Or is that again a sign that we're thinking to complex here? We could also later allow admins to define their own presets, which I think could make sense since some events might want their users to only create private rooms, others only to create public rooms, others might have other ideas entirely.

venueless / venueless

Permissions #22