I see that roomJoin = true will permit any token holder to re-create a room. Makes sense. I guess it's not too ergonomic for multi-tenancy situations where you have to control how many simultaneous rooms are permitted. Either you: 1. Generate rooms and tokens on-demand, which is fine, but I'd like to generate, store and update them ahead of time. 2. Or, you generate tokens with canJoin === false, but the express service would have to toggle all of those tokens based on the tenant's usage of resources. Gonna go with option 1 for now with short expiration intervals, understanding refresh is automatic once a client has connected.

Ok, so the tokens are immutable. You can update ParticipantPermission and metadata, of course, but a token will get refreshed as its used. Is it possible to invalidate a token or enforce permanent deletion of a room? So far I just see using RoomServiceClient to set max participants to 0. I'm concerned that a customer who brings public, unauthenticated users into a room will try to close the room, but clients will refresh the room. Because LK refreshes the tokens for 10-minute intervals, the customer (and I) would not have control other than to turn off publishing/subscribing/data transmission. But, from LK's perspective, the room would remain open, and it will still count against the metering I apply to the customer. Docs say that a participant who has been removed will still be able to rejoin the room. Say I turn off can_subscribe, can_publish, and can_publish_data, will they still get access to room metadata updates?

Is it possible to prevent a kicked user from getting room metadata updates and data packets from other participants? Other than to point all data packets at specific participants?