Community scoped events

[sant0s12]

Alternative to #848, basically my interpretation of #848 (comment).

The basic idea is to wrap posts into post requests instead of defining a lot of new kinds. This way one could wrap any existing kind into the new community post request wrapper kind:11.

I'd also like to revisit something like approvedUntilRevoked from #602 (comment), since people expressed support in favor of having the option to approve posts by default. This would maybe require adding a new kind for moderators to remove the default approved posts (like kind:4550 but in reverse). However, this might make more sense as a separate PR.

[fiatjaf]

I like this solution, but I also think eventually everybody will realize NIP-72 is fundamentally broken.

[staab]

This leans into the worst part of communities, which is the single moderation model. Client should be responsible for how moderation is implemented, because there are many valid approaches to moderation. This will break Coracle's implementation of groups, which ignores moderation as specced.

[sant0s12]

I like this solution, but I also think eventually everybody will realize NIP-72 is fundamentally broken.

@fiatjaf In what way?

This leans into the worst part of communities, which is the single moderation model. Client should be responsible for how moderation is implemented, because there are many valid approaches to moderation. This will break Coracle's implementation of groups, which ignores moderation as specced.

@staab How do you think moderation should work? Tbh I think covering the use case of approve or disapprove by default should be enough but maybe I'm missing something. What is Coracle's approach?

[staab]

How do you think moderation should work?

Coracle ignores nip 72 moderator tags right now because it's not really necessary with WoT filters and such, which hide obvious spam. I do think there are use cases for the current version of approval-based moderation, but there are also use cases which would benefit from disapproval-based moderation. It's also reasonable that the user might want to choose their own moderators based on WoT or an explicit nip 51 list. Anyone could then issue moderation events.

I've drafted an update to NIP 72 at #1024 with slight modifications to to the language that relax the current requirements. The reason I consider this not a breaking change is that it simply shifts the burden of moderation from the protocol to the client/user, which is sort of the point of nostr anyway. This leaves us an opening to evolve how moderation works without contravening the spec, while allowing current implementations to continue working.

The key thing that is broken with NIP 72 though that can't be changed is that a group is forever tied to the person who created the group, and they can change relays/moderators/metadata at any time. That can't be solved without trashing the entire NIP, but this one has enough adoption I don't want to do anything backwards-incompatible.