bf7998e780
khatru: OnListenerRemoved wasn't being called in the most common case of a connection dropped.
I think this is mixing different concerns, the ability for a relay admin to ban/add relay members has nothing to do with a group admin's ability to ban/add group members. These actions should be based exclusively on nip 86 management methods (or equivalent rbac that we're planning to add to nip 43). Looking more closely at this whole PR, I am afraid we're creating a confusing mess — room roles should only apply to rooms, not spaces.
Ok, unfortunately on another review I don't think I can merge this PR because it confuses room-level role based access control with space-level permissions. I think we need to take a step back and think about how group owners might actually use this and well as create a working backend implementation on zooid as well to test against.
Why would this ever be true?
This feels both over and under-engineered. The NWC url is just a string field, on write it should be encrypted and stored, when sent to the frontend it should be converted into nwc_is_set or whatever. When we need to use it, we can decrypt on demand.
This should be handled by welshman's thunk stuff (when a thunk is enqueued it optimistically tracks it at all target relays). Are you seeing new events not showing up immediately?
