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
