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.
Supabase dev and the maintainer of Supabase Realtime here!
Meteor was before my time (I was doing product when Meteor was all the rage back in the day and never had a chance to explore it as a dev) so can't speak to that but Realtime scales pretty well since it's an Elixir/Phoenix server listening to a Postgres database.
We've recently added Realtime RLS, a more secure version of Realtime, so we need to continue to tune it to make it more performant. I think a couple hundred is doable for now. You should give it a try and give us feedback.
We have a Supabase user who is running the version prior to Realtime RLS, which is more performant at the expense of security, and they have thousands of users chatting concurrently. Just to clarify these chat messages are being saved to a database and then being broadcast to thousands of users.
We're also actively working on Realtime Broadcast which doesn't need to go through the database. Great for ephemeral chat messages and definitely more performant.