[Feature] Different user permissions

[bannmann]

Similar to online conferencing software like Zoom, Google Meet or MS Teams, sshx should distinguish user permission levels. This would greatly increase its usefulness in teaching settings (particularly with larger audiences of 10+ people), or in video conferences with attendees of mixed seniority levels.

Here is how I imagine this could work:

• The first user to connect to the session becomes the host.
• A session starts in "default" mode where every user has "full access" level. When the host activates "limited" mode, sshx moves every other user to "guest access", but still shows their mouse cursors and lets them enter chat messages. Users joining afterwards will also be on "guest access".
  • This way, the host can present stuff and others can point at things or ask questions, but nobody can goof around and disturb the presentation. Also, in case it's a production system, the host does not have to watch out for people doing dangerous stuff.
• While in "limited" mode, the host may change each user from "guest access" to "full access" and back at any time.
  • This is useful if someone from the audience is supposed to take over for a while.
• The host can leave "limited" mode at any time.
• Additionally, there could be a feature allowing hosts to designate other users as co-hosts.

[jankatins]

Another ideas would be a --read-only share and the server on my host printing (and asking) if a command should be run

[webnerdnick]

I think this feature request should be at the top of the list. I think an easy way to quickly implement this at a bare minimum would be a read/write mode that can simply be toggled in the UI by the persons name in the list that appears in the top left. This toggling should only be able to be done by the primary host. An alternative to toggling in the UI may be to list joined participants in the CLI output on the host, and allow selections there for who can read/write.

[luochen1990]

Another related feature is: the host can confirm it before the command output shared to everyone.

The scenario is if the host check logs via journalctl and there is a pwd or token there, you will not hope it displayed to guests