Stream multiplexing (API change)

[Gargron]

A planned development in upstream Mastodon is to multiplex multiple streams through a single connection. For example, if a user has 10 columns with different hashtags in their web UI, that's currently 10 separate websocket connections. That's a waste of resources. Instead, the dynamic nature of websockets could be used to subscribe and unsubscribe from specific streams. The return format would then need to be enhanced to say which stream a given message belongs to.

[codesections]

Thanks for the heads up. Flodgatt should be able to accommodate this, and I already have some ideas for how it should do so.

The exact Flodgatt implementation will obviously depend some on how it is implemented upstream. Is there a tracking issue for this change upstream? I searched the tootsuite/mastodon issues and didn't see one – my apologies if I just missed it.

Would the idea be to support both the current single-channel streams and multiplexed streams though the existing v1 API rather than splitting off a v2 for mutiplexed streams? Both seem possible, and I can think of pros/cons to both approaches.

[codesections]

To support this change, Flodgatt will need to read incoming messages from the WebSocket (which it currently does not, to save CPU). Making this change will also allow Flodgatt to close its WebSocket connections more promptly, which will help resolve a rare/minor UI bug: currently, if a client closes a WebSocket (because the user navigated away from that timeline) and then establishes a new connection to the same endpoint (because the user navigated back to that timeline) and does so before Flodgatt has fully closed the first connection, then the UI will display a "load more" button even though no messages were lost. This happens very rarely, but it will be nice to ensure it can never occur.