Re-evaluating using SSE for external event subscriptions

[DefiDebauchery]

I understand the thought process that went into choosing SSE/EventSource for broadcasting and consuming event data, but I think it may be causing more problems than it solves.

I've spent much of the week running various tests and tools in Python, JS, and the CLI to track down why I was having such issues with SSE; specifically, the closing of connections when no data is sent over the wire. While some minor adjustments can be made through server settings -- for instance, somewhere in the network stack, Safe Events is currently closing connections after 30 seconds, whereas other public services like Wikimedia will wait 60s -- it won't be enough to keep a connection open long-term, and having to reconnect repeatedly (possibly missing events in that timeframe) negates the point of a streaming event system.

Members of the WhatWG (the working group that defines web standards) have even generally mentioned that they aren't likely to improve on SSE as a whole, stating that other modern streaming technologies, such as websockets, are superior.

I would like for Safe to re-evaluate whether SSE is a good long-term solution.
One possible stopgap in the interim would be to send a heartbeat message (which only needs to be :, signifying a comment) every x seconds. It's negligible data, and it should prevent the transport from being closed.

[Uxio0]

Your reasoning looks good, it seems we didn't make the right choice. Refactoring into websockets shouldn't be so complex, we will work on it