So it seems like things could work with NIP-29 for me (and others?) to build on it, but a bit of changes would be needed in my opinion: I don't see how it's good not to have a link to the practical (actual) creator of a group. The relay can remain an 'action' authority, but the creator needs to act as the higher/'actual' authority as a link of sorts. Meaning I'd publish the creation event (mandetory, not optional, and if privacy is a concern then a deterministic derivation from the creator's pubkey can be used) and whatever i change with the rules, or who is allowed to change the rules (admins, moderators) is published by me, and the relay enforces them. This gives a proper view of who controls what, and it would be visible if a relay misbehaves / becomes malicious (if the relay changes the rules and does other enforcements that they creator did not publish, then it reveals for everyone that the relay is misbehaving / is malicious). Regarding the d tag, it shouldn't be <host>'<group-id> but rather <creator-pubkey>'<group-id> where relays must not create a group without seeing a creation event with that same d tag published by the same author as <creator-pubkey>, this prevents a malicious user(s) from preventing a creator from migrating their group from one relay to another because of d tag colision. The cost of doing this, however, is that it would not allow the functionality of forking a group, but that can easily happen fixed by adding a tag to tell relays "this is a forked group, so grab grab posts with this d tag as well". With that in mind, the h tag would also have to have the <creator-pubkey>'<group-id> value. Considering the removal of <host> from the d-tag, we'd utilize the order of the r tag to identify the current relay authority, if that even matters, where we can just have multiple authorities ("enforced") considering that we'd now have the 'actual' authority being the creator. That [private] part is a protection from the general public, but not from the relays, so the solution here is tree encryption / mls-ish (optional). No new kinds, just tweaking the flows and assumptions. This gives power to the user/creator, while complexity and processing remains with relays and enforcement remains on the relay side as well, and there wouldn't need to be a 'migration' because of this anymore, you'd just add/remove relays from the creation event and rebroadcast events. To me this seems like the best of both worlds, but perhaps i'm not seeing something or have misunderstood aspects of it. Thoughts @7fa56f5d…751ac194 @3bf0c63f…aefa459d @Niel Liesmons ?