The reason why I suggested having the pubkey in the d tag is because I'm following along with NIP-29's flow of having the relay as the enforcer/manager keypair, because without that (the pubkey in the d tag and doing a check) then a malicious user create a group a group event with the same d tag then have it everywhere, hogging relays wherever they can which prevents the normal users from having their created group be on other relays as a result of each of the other relays' keypair utilizing the same d tag by the malicious user, resulting in a centralization chocking attack (now that specific group is stuck in the relay or to a small few options, where the only solution now is to create a completely new group). I'm basically trying to push for increasing decentralization as much as I can with the benefits of control brought in by NIP-29's management goals. The desire to have multiple admins that are equal to each other without a creator/super-admin is more complex than having a creator/super-admin above those multiple admins, as that raises the question of who should the relays listen to when there's a dispute? We'd either end up having chaotic battles of constant back and forth changes, or there needs to be a voting system for consensus, and the other issue is if one admin wants to kick another admin, is that respected? what system should handle this? I hope I managed to explain well what the issues of not having a creator/super-admin that relays listen to as the final authority. It's not that there can't be equal admins, but that there must be a super admin (creator) above them to not have such complexities and potentials issues. If there's a desire to fork the group, then that can be done by just mentioning the original group id (d tag) under a new tag, when the new creator publishes their group, and the relay grabs the relavent events.