Thank you, I think I get it now. I think your scheme works, but I don't think it is better than the current NIP-29. I think it has one advantage, but sacrifices other things. Overall I'm glad we're pretty close to agreement here. I think you're approaching it from a perspective that the relays will all be running the exact same software and will be blind about who is creating groups in them. That can't be true: relays will have to authorize and monitor who has groups. If someone can spam all relays with groups with the same "d" tag those relays have serious problems and can't be trusted anyway. The market will select for relays that offer a nice service, that can't be easily spammed and therefore have more staying power, that can exclude bad actors and delete their squatted groups. A squatter won't have access to all relays in the first place, it won't even know what are all these relays. For example, just now there exists 10+ #pyramid relay instances out there with NIP-29 group support, but only a few members can host groups in them. Some people are members of more than one of these, so if one of these goes offline they can migrate the group to the other. (That brings me to another point I forgot to mention: that you can easily publish to more than one relay, as a backup, in the current NIP-29, we just need the tools to do it right, but should be doable in a few minutes once there is demand.) Your comments about there needing to be a voting system or stuff like that also reflect this idea that all relay will be the same: they don't have to be. There could be relays that are hardcoded to support multiple group owners, others that don't, others that do something else entirely; relays that charge for groups, others that don't; custom implementations done only to allow a certain group to have weird custom admin rules; and so on. The groups will have to pick and choose the relay that better suits them to host their group.