---
tags: Dev, Collaboration Real Time
---

# Real time collaboration on Alkemio

As we move towards full roll out of real time whiteboards on Alkemio we need to make some decisions related to how users interact with them.

Key points:
* Collaboration in real time is different than being able to create / read / update data
* Rights to be able to collaborate in real time need to be managed carefully
* User experience has to be simple

Note: I am talking about real time collaboration in general, so whatever approach we choose here can also be used as we move to support real time document editing.

## Real Time Collaboration modes
The suggestion is to have multiple roles for how a user is interacting:
* Viewer: for viewing what is happening
* Contributor: for actively participating

The set of events that are accepted, and broadcast, by the collaboration room is then collaboration mode specific.

There could in the future be additional modes.

## Collaboration privileges
The suggestion is to have separate real time collaboration privileges:
* REALTIME_VIEW: for viewing what is happening
* REALTIME_UPDATE: for actively participating
* REALTIME_SAVE: for saving a snapshot

Currently we are using READ for view only access, and CONTENT_UPDATE for actually collaborating.

There could in the future be different privileges for e.g. being able to bring people to you etc.

To be able to participate in a room as a Viewer requires the REALTIME_VIEW privilege.
To be able to participate in a room as a Contributor requires the REALTIME_UPDATE privilege.

## Settings + License

The realtime entity being worked on, for now just the whiteboard, allows people to participate in roles based on:
* who is allowed to participate in what role (entity)
* this could be just the creator, also admins or also contributors (in the wider context)
* how many users are allowed in each role (license)
* likely primarily license based for now, potentially also by the settings on the entity

In particular the license for the space could determine that only a single user is allowed to be in the Contributor role - even if many users have the REALTIME_UPDATE privilege.

## User interaction
When opening a whiteboard, the interaction option shown to the user should try the following in order:
* Check the REALTIME_UPDATE privilege, if present then *attempt* to join as a contributor
* If the prilege is not present, or the joining as contributor fails, then check the REALTIME_VIEWER privilege. If present then *attempt* to join as a viewer
* If that privilege is also not present / fails, then if the user as the READ privilege then display the latest saved snapshot of the whiteboard.

## Saving a copy of the state
The saving of the state of the whiteboard is currently triggered by manual user action.

The saving of the state should:
* Not impact in any way the currently state of the room
* So it must not take the data back from the server / update the local cache
* Not generate visuals / images
* We need to make this an explicit setting / action by a user with the UPDATE privilege (later)
* The saving of the state should be done via a separate mutation, that only takes the content and nothing else.
* This mutation should only return a boolean to indicate if the operation succeeded.