Nip 72 edits

[staab]

NIP 72 is a useful basis for communities, but is too rigid and has some oddities that should be corrected. A summary of changes:

• The intro specifies that communities are moderated, which need not be the case. I've removed that language (see below for other changes to moderation).
• The intro specifies that communities are topic-related, but that's too narrow a view, and not really implied by anything in the spec. I've removed that language.
• Community name equaled the d-tag, which meant communities could never be renamed. This is an unnecessary limitation, I've added an (optional) name tag.
• The community posting process is unchanged, but the language has been changed to reflect that it's perfectly possible for a client to request an unmoderated view of community posts.
• The moderation specification has been relaxed to indicate that implementation of moderation is up to the client, without removing the 4550 affordance for approval-based moderation. This opens up the possibility for clients to provide disapproval-based moderation, moderation based on web of trust rather than a static moderator list, etc. The motivation for this is that nostr communities tend to die when moderators lose interest and stop approving posts.
• Cross-posting is explicitly supported.

A lot of this is motivated by Coracle's implementation, which ignores moderators, relying instead on WoT/mute based content filters. In the future I may re-introduce moderation, but will allow users to choose how it's implemented (moderators list/other list/WoT; approval/disapproval/implicit approval).

[staab]

Could someone tag Stuart Bowman and anyone else involved in communities in this?

[vitorpamplona]

Good improvement.

[staab]

Good improvement.

Phew, I thought I might be killing your baby. Glad you like it.

[vitorpamplona]

Phew, I thought I might be killing your baby. Glad you like it.

As long as we keep it not centered on specific relays, I am good (not that people need my approval anyway).

Relay-based communities are way too centralizing IMO.

[vitorpamplona]

@lovvtide @vivganes

[sant0s12]

I generally like this direction of not so strict moderation, however:

• I think it would make sense to also address the issues discussed in using multiple independent kinds for community-scoped events #848, for which I drafted Community scoped events #1021 based on @fiatjaf's idea. This would also support cross-posting with no modification since the same post can be wrapped into multiple community posts.
• From what I understand, only the approval event would be in the spec as it is, but an explicit disapproval event would also be nice in my opinion. This is different from WoT, since something like disapproving a post for being off topic could also be useful.

Maybe completely decoupling the moderator list from the community creation should be considered. In that case, clients could allow the user to pick which users to trust with moderation. One could also provide a mechanism for users to advertise their own moderator lists that can be then up/downvoted so that new users can quickly get an impression of which set of moderators is "approved" by the community.

[staab]

@sant0s12 I mostly agree with all of that, but we should wait for implementations of those moderation models to happen before adding them to the spec. As for reposts, I'm fine with a new kind, but #848 created a lot of discussion and I don't want to bring that here. Let's keep discussing the issue over there.

Also, @hzrd149 might have some opinions about this PR.

[vitorpamplona]

We should merge this and move on. @fiatjaf