Client will seek to continuously reconnect to the WebSocket when there's a connection issue and server must receive at least one heartbeat in a 60 second window; otherwise it will clean up the WebSocket connection.
We built Supabase Realtime on top of Phoenix Channel, and along with our clients, handles unreliable network connections gracefully, including on mobile.
That back button glitch is specific to the demo. We had to do a few redirects based on Presence sync and load balancing each room. I'm sure there's a better way of doing it and will seek to improve it when I update it. Sorry about that!
We started developing Realtime: Multiplayer version many months ago in a private repo just to experiment with Phoenix's Broadcast and Presence and over time we just added to it.
We plan to move all the code over to https://github.com/supabase/realtime in the next couple of weeks and you'll be able to see the code in its entirety.
> Is server authroity and broadcast permissions handled or left as a task for the user? Can channels be locked down to a list of users?
Broadcast permissions is currently not handled by the server and left to the developer to implement. We have discussed this internally and will prioritize Broadcast authorization accordingly because we've gotten feedback about this from a number of developers.
> Can users be kicked from a channel?
Not at the moment but again we've gotten feedback about this as well and will prioritize it.
> Is message spam/flooding/DDOSing users in a channel protected?
We have built rate limiting and other protections so bad actors don't affect the good in the cluster. A colleague of mine posted these limitations of Supabase Realtime to prevent abuse: https://news.ycombinator.com/item?id=32511586.