Multiple login sessions #59

New issue

Open

opened 2026-09-08 18:24:19 +00:00 by kirsle · 0 comments

kirsle commented

2026-09-08 18:24:19 +00:00

Owner

Research whether BareRTC could support multiple login sessions, instead of the current behavior where your other session is logged off when you sign in from a new device.

Challenges to resolve

Have a method to remotely log off your other sessions.

Currently, if you've forgotten to log out from your desktop, you can kick yourself out of the room by logging on quickly from mobile (which kicks off your desktop session), then logging out on mobile.

There will need to be a new method to log off other devices if multiple sessions are otherwise allowed. Maybe under the Chat Menu, where currently we have a "Log out" link that just links to a static web page. That link could either log out all sessions remotely, or have an option added that would do so.
How to handle webcam sharing with multiple sessions?

Currently, your Who List status (for your webcam being active, and for your chat status like Away/Idle/Gaming) only has to worry about one login session. When somebody opens your webcam, WebRTC messages kick off between you and your watcher to establish the connection.
- What if you are broadcasting your camera from two different sessions? - Somebody clicking to watch your camera might result in both of your devices starting WebRTC negotiations, which could result in one of your cameras being chosen 'randomly' to send to the watcher, or the watcher receiving multiple video streams separately which I'm not sure the chat page can cope with well.
- Have a server-side lock so only one login session can broadcast video at a time? -- if a second device attempts to go live, it can either bounce back with an error saying "your camera is already active on another session" or else it could tell that first session to cut its camera and the new device takes over broadcasting (any watchers from the old session are disconnected and don't automatically switch over to the new one, similar to if you had just turned off and on your camera from a single session).
- Should your Watchers list be synchronized to all devices? -- e.g. you are in text-only chat on your iPad and are broadcasting your camera from your iPhone. Should your iPad show the watchers who are viewing you from iPhone?
  
  Added challenge: the watchers list is updated via "watch/unwatch" commands, and supplemented/corrected by WebRTC peer connections on your local web page. If you log in from iPhone first and get some watchers, and then log in from iPad, the iPad wasn't there to receive the watch commands and won't have as accurate of a picture of who is currently watching your iPhone.
- Could you watch one person's camera from multiple sessions at once? -- Say from your iPad and your iPhone you open Alice's camera on both. Should Alice's screen indicate on the Watching tab that you are listed twice? How does the chat web page keep track of multiple WebRTC peer connections linked to the same username?
How to handle chat statuses? (Away/Idle/etc.)

Maybe have a priority of statuses, so any session with an Idle status is lowest priority (so if one session is Online/Active or has a custom status set, its status is preferred over Idle when broadcasting Who List updates to others). What if two devices have equal priority statuses? e.g. one is Gaming and one is Watching A Movie. Most recent status change wins?

Technical implementation details

On the backend, sessions are often stored in hash maps keyed off the username and pointing to just one WebSocket subscriber. These data structures would need to be changed to store an array of subscribers per username to enable multiple simultaneous connections.

Functions that push messages out to subscribers would need to iterate over the new list, so every logged-in session for a given username receives a copy of most messages (except maybe WebRTC messages for webcam connections, which should only be sent to the specific sessions of the person opening a camera and the person broadcasting the camera -- otherwise clicking to open a camera from one device might result in all of your sessions opening the camera if the WebRTC messages are broadcast to them all).

Research whether BareRTC could support multiple login sessions, instead of the current behavior where your other session is logged off when you sign in from a new device. ## Challenges to resolve 1. Have a method to remotely log off your other sessions. Currently, if you've forgotten to log out from your desktop, you can kick yourself out of the room by logging on quickly from mobile (which kicks off your desktop session), then logging out on mobile. There will need to be a new method to log off other devices if multiple sessions are otherwise allowed. Maybe under the Chat Menu, where currently we have a "Log out" link that just links to a static web page. That link could either log out _all_ sessions remotely, or have an option added that would do so. 2. How to handle webcam sharing with multiple sessions? Currently, your Who List status (for your webcam being active, and for your chat status like Away/Idle/Gaming) only has to worry about one login session. When somebody opens your webcam, WebRTC messages kick off between you and your watcher to establish the connection. * What if you are **broadcasting your camera from two different sessions**? - Somebody clicking to watch your camera might result in _both_ of your devices starting WebRTC negotiations, which could result in one of your cameras being chosen 'randomly' to send to the watcher, or the watcher receiving multiple video streams separately which I'm not sure the chat page can cope with well. * Have **a server-side lock so only one login session can broadcast video at a time?** -- if a second device attempts to go live, it can either bounce back with an error saying "your camera is already active on another session" or else it could tell that first session to cut its camera and the new device takes over broadcasting (any watchers from the old session are disconnected and don't automatically switch over to the new one, similar to if you had just turned off and on your camera from a single session). * **Should your Watchers list be synchronized to all devices?** -- e.g. you are in text-only chat on your iPad and are broadcasting your camera from your iPhone. Should your iPad show the watchers who are viewing you from iPhone? Added challenge: the watchers list is updated via "watch/unwatch" commands, and supplemented/corrected by WebRTC peer connections on your local web page. If you log in from iPhone first and get some watchers, and then log in from iPad, the iPad wasn't there to receive the watch commands and won't have as accurate of a picture of who is currently watching your iPhone. * Could you **watch one person's camera from multiple sessions at once?** -- Say from your iPad and your iPhone you open Alice's camera on both. Should Alice's screen indicate on the Watching tab that you are listed twice? How does the chat web page keep track of multiple WebRTC peer connections linked to the same username? 3. How to handle chat statuses? (Away/Idle/etc.) Maybe have a priority of statuses, so any session with an Idle status is lowest priority (so if one session is Online/Active or has a custom status set, its status is preferred over Idle when broadcasting Who List updates to others). What if two devices have equal priority statuses? e.g. one is Gaming and one is Watching A Movie. Most recent status change wins? ## Technical implementation details On the backend, sessions are often stored in hash maps keyed off the username and pointing to just one WebSocket subscriber. These data structures would need to be changed to store an array of subscribers per username to enable multiple simultaneous connections. Functions that push messages out to subscribers would need to iterate over the new list, so every logged-in session for a given username receives a copy of most messages (except maybe WebRTC messages for webcam connections, which should only be sent to the specific sessions of the person opening a camera and the person broadcasting the camera -- otherwise clicking to open a camera from one device might result in _all_ of your sessions opening the camera if the WebRTC messages are broadcast to them all).

kirsle added the

enhancement

label

2026-09-08 18:24:19 +00:00