Never heard of it before but thats such a cool concept!
The main issue I have though with platforms like Element is moderation, so I hope theres good options here to moderate all rooms at once and make people admins and stuff.
And of course someone should make a matrix / discord bridge for this.
Looking further its not what I am looking for yet, but its getting close.
Basically it would need one event that dictates what rooms are in a space, which relays they use and who the moderators are.
Then people can add that note ID as a space to get access to all the relevant channels automatically grouped together.
It would mean we don't have to host our relays just to make a space and it becomes decentral again.
Moderation would be done trough moderation events checked against the verified npubs and if that matches the moderation event is succesfull, or if possible each moderator has their own npub event with all the actions they have taken which can be checked against by the client.
That way if a user is banned it can be done in a decentralized way (and compatible clients of the nostr spec could then keep it in sync with more formal standards).
Maybe I am overengineering the solution here, but you get the idea.
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.
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
