In y-websocket-server, why does 1 conn map to multiple client ids?

erin · June 17, 2025, 12:06am

src/utils.js

effa5050f


      
          }
          
          export class WSSharedDoc extends Y.Doc {
            /**
             * @param {string} name
             */
            constructor (name) {
              super({ gc: gcEnabled })
              this.name = name
              /**
               * Maps from conn to set of controlled user ids. Delete all user ids from awareness when this conn is closed
               * @type {Map<Object, Set<number>>}
               */
              this.conns = new Map()
              /**
               * @type {awarenessProtocol.Awareness}
               */
              this.awareness = new awarenessProtocol.Awareness(this)
              this.awareness.setLocalState(null)
              /**
               * @param {{ added: Array<number>, updated: Array<number>, removed: Array<number> }} changes

What is the scenario where one Websocket connection needs to control multiple client IDs? Isn’t it always 1:1?

dmonad · June 17, 2025, 9:40am

Hi @erin,

Good question. There are weird edge cases, which is why I used a Set.

There are two edge cases that may happen:

a client manually resets the clientid (which I don’t recommend doing, but it can happen).
When meshing providers, a client may forward awareness state from other clients. One example would be when you sync through y-webrtc AND y-websocket (or more commonly, syncing document state via tab-to-tab communication via broadcastchannel). So the websocket server may receive awareness state from different sessions (webrtc connected clients, state from other tabs) via different providers.