Introducing Sessions & Channels?

while working on live updates for deck utilizing notify_push, I reached some limitations and was generally wondering whether lot of the work could be somehow abstracted from the individual app (I already copied a lot of code from text)

Current limitations / issues

• only possible to target clients by userId, not individual sessions (for example required for excluding the causing session from an update event)
• Each app, which wants to implement something like real-time updates (hopefully many more in the future!), must take care of its own list of active sessions (creation of sessions, closing - not trivial, expiration, cleanup, documentation,...) even though it is always more or less the same task

After much deliberation, I think to abstract/unify this task of tracking active users introducing the following two concepts within notify_push does make sense:

Proposals

1. Concept of "sessions"

• each client could get an unique session identifier (either randomly client generated and sent to the rust backend or generated by the backend and sent to the client)
• IQueue::push() accepts user or session as selector
• notify_push should be responsible for closing the session (an API endpoint which gets called on visibilitychange by the client library or when the session expires by the rust backend), broadcasting an event which an app can listen to:

  $context->registerEventListener(SessionClosedEvent::class, MyParticipantsCleanupListener::class);
  

• After a reconnect (for example when a tab has been paused for a while) for minimized complexity it should be considered a fresh session. This requires the possibility, that an app frontend can listen to this happening and can then call the appropriate api endpoints again.

2. Concept of "channels" (requires sessions)

• option to subscribe sessions to an "channel" identifier

  $queue->subscribeChannel($session, "deck:board:16");
  $queue->unsubscribeChannel($session, "deck:board:16");
  

• notify_push is responsible to keep track of the list of sessions and automatically "unsubscribe" expired/closed sessions
• app is responsible to call subscribeChannel() when it is needed and the client is authorized
• IQueue::push() also accepts channel as a selector

  $queue->push('notify_custom', [
    'channel' => "deck:board:16",
    'message' => "card_update",
    'body' => ["foo" => "bar"]
  ])
  

• Allowing to specify multiple channel could be sometimes really handy. It could be ensured, that a session listening to more than one of the channels doesn't get the event multiple times

  $queue->push('notify_custom', [
    'channel' => ["deck:board:16", "deck:dashboard:admin"],
    'message' => "card_update",
    'body' => ["foo" => "bar"],
  ])
  

Not yet considered

• can this also handle guests without an account?

Start by reviewing the existing IQueue::push entry point and the notify_push session lifecycle. The proposal also identifies registerEventListener(), subscribeChannel(), and unsubscribeChannel() as API surfaces to assess. Done would require an agreed design for session creation and closure, channel membership, expiration cleanup, and user/session/channel selectors.