Add feature detection for unmanaged groups

[staab]

Feature detection for unmanaged groups has to exist on two levels:

• On the group level, so that clients can toggle the richer NIP 29 behavior on or off. Feature detection based on NIP 11's supported_nips field isn't sufficient, since a relay implementation might support NIP 29, but the actual relay may not.
• On the relay level, since clients need to be able to know whether users can post events to groups that don't yet exist, or whether they have to send a create-group event instead.

The default (obviously) has to be that unmanaged groups are allowed, so unmanaged group support is opt-out.

[staab]

I removed the nip29.unmanaged setting because it's annoying, and would be complex to have unmanaged groups live alongside managed groups. This just clarifies what is already the case, and edits the copy to be clearer.

Feature detection based on NIP 11's supported_nips field isn't sufficient, since a relay implementation might support NIP 29, but the actual relay may not.

The NIP 11 document should probably be for describing what a particular relay instance offers rather than anything describing the implementation. I was wrong about this.

[fiatjaf]

I am confused. Can you give some examples of what does it look like to be a relay that supports both unmanaged and managed groups?

Is that a community relay (with already some form of whitelisting and internal rules) that happens to have special rules for some "rooms" -- or is it a relay that allows pretty much anyone to make a random managed group, but also somehow allows ad-hoc unmanaged groups to exist?

[staab]

Either one I'd say. My thought was for community relays, rooms would be unmanaged by default, but users could create NIP 29 groups if additional metadata or access controls were desired. But since unmanaged groups provide a subset of the functionality of managed groups, and private nip29 group support implies general nip29 support, it seems pointless to allow unmanaged groups on nip29 relays, since you might as well use the richer, supported groups. In that sense, unmanaged groups are totally orthogonal to nip29 and should probably be their own NIP ultimately.

[fiatjaf]

I don't think it's totally orthogonal, I think the community relay that evolves to have rooms with permissions is a very good use case.

But also maybe we can have another NIP for unmanaged groups, this doesn't prevent the two NIPs from being compatible at the edges, and then we can have the features explicitly signaled via NIP entries on supported_nips.

But maybe what we should actually do is create a new NIP-11 field called features where we could write ["nip29.unmanaged", "nip29.managed", ...].

[staab]

I don't think it's totally orthogonal, I think the community relay that evolves to have rooms with permissions is a very good use case.

I mean in the sense that the migration will probably happen at a point in time, since a relay can upgrade unilaterally, so there's no reason to support both modes at once.

But also maybe we can have another NIP for unmanaged groups, this doesn't prevent the two NIPs from being compatible at the edges, and then we can have the features explicitly signaled via NIP entries on supported_nips.

At this point this is my preference, although unmanaged groups are kind of a weird case, since they're supported unless the relay opts out. So we'd need an unsupported_nips array or something. Anyway, I don't think any of this matters at the moment.