Proposal: use Server-Sent Events instead of WebSocket

[0x009922]

WebSocket is overkill for Events and Block Stream APIs - they aren't bidirectional. Server-Sent Events is a simpler and more robust HTTP-native alternative (e.g. used by ChatGPT streaming responses).

Benefits:

• Transport over plain HTTP, supported by any client that supports streaming data. WebSocket requires extra handling often with some external dependencies
• Built-in re-connection support
• Less deployment headache - WebSocket requires some extra configuration, and some corporate firewalls really don't like it

Downsides:

• Only text data - binary-to-text encoding overhead for SCALE data
• WebSocket is more future-proof - if Events/Block Stream APIs become bidirectional communication channels (unlikely?)

[DCNick3]

Text-only seems like a big showstopper to me. One alternative I can see is to use own own event streaming format, with support for binary events (and probably without event id?).

AFAIU, you still can handle that in the browser environment with fetch API. We'd have to implement the reconnection ourselves though..