This is basically how NIP 72 works, the problem is that it puts all the logic in the client, which can be easily circumvented. Relying on a relay to implement the logic allows genuine access control and moderation, rather than a logical layer on top of permissionless events. This may be more or less desirable, depending on your community. The obvious cost is reliance on a relay, but multiple backends can be re-introduced in order to add redundancy of hosting/moderation.
Discussion
ACLs in relays are part and parcel of what NIP-42 is about. in the nip it even mentions the concept of blocking access to a privileged type of event, a DM.
i've built a simple ACL that uses follow and mute lists but the same principle would apply to add checking and caching nip-72 room definition events, you could have both on a relay, and override the check to use these instead of the plain subscriber list for the relay
Yeah, that's a good point, relays could be configured to support certain other use cases, like NIP 72 access control. I imagine control would be spotty at best, especially considering how nostr:nprofile1qythwumn8ghj7anfw3hhytnwdaehgu339e3k7mf0qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzpmhxue69uhkummnw3ezumt0d5hsqgzxpsj7dqha57pjk5k37gkn6g4nzakewtmqmnwryyhd3jfwlpgxtsf4t65r requests community posts from member inboxes as well (for example).
yeah, the admins would need to make sure they send the events that update the access control list to the relays that serve it, but other than that, it's not that complicated. caching that state would probably be more efficient in the sense that it wouldn't need to be fetched from the event and parsed but either way would work.
i don't think amethyst is implementing it correctly then, also. it should be using the specified relays in the community, and picking them up with K/k tags and the "optional" relay in p/P tags should not be optional... hmm looking at the spec superficially it probably needs to be changed to allow multiple relays to be specified there. could be just space separated or something, idk.
i haven't even looked at these things tbh. i think much simpler than this quite verbose spec is just making them relay based and have the relays in a community subscribe to each other for event updates to replicate them.
I am planning to add federation to relay based groups, I agree some kind of progressive enhancement like that makes sense