I don't know if I would use this functionality, because I don't really use rooms currently.
Given the end-to-principle of decentralization, I would think it would be preferable to move functionality to the end-nodes, peers, rather than to add functionality to rooms, for what I understand to be an authorization protocol. If it is a concern of DoS, perhaps a special provisional or restricted mode could be added for new connections from unknown peers, where RPC is limited until the user approves the connection/request or the connecting peer authenticates with their token (i.e. the doorknock idea in %j2EJzTS... ). Limiting resource usage use for a connected peer at the socket level should be possible by limiting the receive buffer, i.e. just not reading from the TCP socket. This may mean reworking the stream modules, since the ssbc/muxrpc implementation currently reads continuously and buffers unboundedly. The case where I could see a need for third parties to broker authorization claims would be for privacy: to accept a SHS connection, you must confirm/reveal your public key to the client as part of the handshake; while if you reject during the handshake, it looks the same as if the connection failed because of a wrong public key or network key. In the context of rooms, I'm not sure if this privacy possibility would be realized or useful, since the room might already be claiming that the peer is in the room, and/or the peer might already be publicly self-identified with the room.