Your quite right here. Perhaps having something that stands as a demo is the way to go. And then I can also reference this implementation for an Rx specific way to go.
Re your alternative. I like it the goal. But the EventSource API doesn’t allow sending headers, so in the two step case you described above the first fetch must return some kind of token that can be used to start streaming the mailbox. If this was part of the path that is less secure, because servers often log request paths.
I.e. it’s easier for a hack to start streaming someone else mailbox.
The current system with special message uses getting a mailbox to always generate a new one, and uses the built in last-event-id structure to authorize in case of reconnection.
Would it be helpful if the message came through a different callback. The EventSource interface does allow types. so the message wouldn’t have to come in the same eventlistener. i.e.
eventSource.addEventListener('special', doSetup)
