Real time collaboration

[SCA-ZMT]

Define co-working concept that would allow multiple users to open the same project simultaneously (while allowing only one "active" user at a time to edit it, while the others observe).

WG Lead: @odeimaiz

### Tasks
- [ ] https://github.com/ITISFoundation/osparc-issues/issues/1482
- [ ] https://github.com/ITISFoundation/osparc-issues/issues/1483
- [ ] https://github.com/ITISFoundation/osparc-issues/issues/1484
- [ ] https://github.com/ITISFoundation/osparc-issues/issues/1485
- [ ] https://github.com/ITISFoundation/osparc-issues/issues/1486
- [ ] frontend services should also be lockable
- [ ] disable app mode if multiple users are in the project
- [ ] only allow to join a project if write access
- [ ] allow to enable/disable project sharing via ENV
- [ ] migration of project workbench might be very helpful
- [ ] (migration ui in separate table)

[odeimaiz]

For having more than one user opening the same project, some changes would have to be made in the platform.

• implement the host/viewer concept: open a project, update and close it
• do not let viewers interact with the iframe: shield mouse and key events

The rocket is already, almost completely, a sharable iframe. Only those widgets that have some logic in the frontend, would miss the "sharebility":

• 2d plot?
• ...?

I wouldn't make projects with other dynamic services than s4l co-workable.

[odeimaiz]

@mrnicegyu11

Take the chance to make it more secure. Two solutions:

• Make authentication microservice and use it to authenticate iframe
• Use shuffled (ad-hoc generated) UUID instead of serviceUUID, like a token the backend gives to the frontend, which might be sufficiently secure

[odeimaiz]

Use cases / Targets:

• Real time collaboration
• App Team support
• Real time Demos

Technical gaps:

• oSPARC:
  • Increase iframe security (anyway needed, see notes)
  • Implement PATCH project (anyway needed)
  • Broadcast PATCH to shared users
  • React to PATCH in frontends
  • mouse and keyboard shields for iframes on guest users. is it enough?
  • Allow more than one user to open the same study
• Sim4Life:
  • 1 screen per user: otherwise the 3d view will be deformed
  • Some tools with logic in the frontend might require some love
  • Almost? ready to go for a testing process

Collaboration modes:

• New Open mode: Open and let collaborators join
• Host/Guest on project level
  • Host can edit, Guests can inspect
• Host/Guest on node level
  • When both in the same node: Host can edit, Guests can inspect
  • When in different nodes: Host and Guests can edit (true real time collaboration) (better than remote screen control)

Notes:

• Host selects wallet, therefore pays
• A chat on the side would be extremely helpful

[SCA-ZMT]

Needs final decision after Uetliberg discussion.

• Does it provide any added value compared to a shared remote session (zoom, RDP)?
• Users would anyway need some real-time communication channel to make this effective.
• Is there a concrete use case?

[newton1985]

Just a few comments, if I understood the vision correctly:

• Re: Does it provide any added value compared to a shared remote session (zoom, RDP)? I think the main benefit here is not a "host edits, guest inspects" mode - as @SCA-ZMT points out this is basically a shared remote session, which is already something in my toolbox as a user. Rather, I think main benefit would be to allow multiple users to log in to the same project at once - and work on different nodes. I see the simplest and easiest version as: the study creator gives the "ok" to allow simultaneous collaboration with a list of shared users on that study. Then, the "ok'ed" users always have the option to open the study and edit/inspect a node that isn't being actively worked on by another user. In a slightly more complex version, users would also be able to inspect nodes being edited by another (but not edit simultaneously).

• Users would anyway need some real-time communication channel to make this effective. A chatbox would definitely be nice, but I don't see it as essential. Like the shared remote session, users can already coordinate on slack/whatsapp/email etc. in a pinch.

• Is there a concrete use case? All the time - the issue of not being able to access the most up-to-date version of a shared study because someone else has it open (perhaps they leave it open for long stretches) can be quite frustrating.

In summary, I don't think this needs to be a fancy feature - I would advocate not over-engineering it. The main issue is that collaborators easily and frequently lock each other out of a shared study, which can make collaboration on a study difficult to the point of infeasible. If multiple users could log in to the study simultaneously, and work on different nodes (or inspect nodes being edited by others, in an advanced version), I think this already gets 99% of the way there. Real-time chat/video/coordination etc. is cool, but definitely not required. I suspect that most of the time, one user will open the study, and leave it open for a few hours or even all day (which previously has blocked other users), so the "simultaneous" collaboration won't really be so simultaneous anyway.

@drniiken @odeimaiz