NIP-72: Moderated communities

[vitorpamplona]

The goal of this NIP is to create moderator-approved public communities around a topic and provide a simple solution to Reddit clients that might want to come into Nostr.

Let the best curators win.

Read it here

[vitorpamplona]

hum... this can be used by anyone to do content curation by topic. hah.. interesting...

A moderator can add any existing nostr event into the topic (there is no need for the post request).

[olheadinternet]

A moderator can add any existing nostr event into the topic (there is no need for the post request).

what if this was done through nip 51 lists... so any client that has "add to list" can be a place for currating... even if it doesn't format the lists as groups?

[vitorpamplona]

Lists don't work well with lots of items. These communities might have millions of posts each.

[olheadinternet]

Is/can poster submit to just < d-identifier of the community > (/bitcoin)

or poster is separately submitting to /vitor/bitcoin & /bob/bitcoin ?

Contrary to my last comment: Or both, what if I want to avoid /bob/bitcoin by submitting just to /vitor/bitcoin. I think it's a very different thing than Reddit like behavior if it doesn't need a submit sig to either the identifier or the pubkey/identifier

[vitorpamplona]

On Reddit, your topic owner is less visible but you are still fully dependent on his/her decisions. On Nostr, hopefully, we add more weight to the choice of owner. I think clearer is better. But we lose the single topic handle (for the good and for the bad)

[starbackr-dev]

Did you get a chance to look at NIP-29 #566 ? Similar concept but we moved some authority functions to the relay. I am working on a demo now and should be ready by end of this week. You will not be able to achieve full moderation from client side. Control on the relay side actually makes is easier like centralized systems. However, you are not stuck to one relay, the group admins can move them to a different relay anytime with history and group members or even have it on 2 relays at the same time. Best of both worlds...!

Let me know your thoughts.

[vivganes]

Thanks a lot for starting this thread 🙏 I just took a quick glance at the proposal.

Not sure if someone already brought this point up.

There is value in the "communities" aspect irrespective of whether it is moderated or not.

There may be a team managing the community but they may not actively moderate or approve posts too.

We could think about a way to make moderation optional too

Will look at the proposal fully and add comments today.

[vitorpamplona]

Did you get a chance to look at NIP-29 #566 ? Similar concept but we moved some authority functions to the relay. I am working on a demo now and should be ready by end of this week. You will not be able to achieve full moderation from client side. Control on the relay side actually makes is easier like centralized systems.

Yep, we looked at relays as the source of control. It's not ideal as they can also block exporting a community out of them. It creates similar issues Mastodon has. On NIP-172, users can use any relay they want to host their communities. They can spread it far and wide. Relays cannot do anything to stop a community from developing. NIP-29 works great for company workspaces but it's not ideal (too centralizing) for Reddit-style topics.

[fiatjaf]

This is very much like NIP-28, but for generic things instead of just chat.

[vitorpamplona]

This is very much like NIP-28, but for generic things instead of just chat.

Kind of. The difference is the moderator list (28 doesn't have it) and the fact that is positive (every post is reviewed) as opposed to negative (hide all by a user). So, instead of clients having to download everything and then filter out the hidden messages/users (which is a bigger set than actual posts these days for some chats), clients can just download the approved content with a direct filter.

[arthurfranca]

Very good! I see the moderator list has optional recommended relays.

I imagine it would be easier for client logic (both user and moderator client) if this is just for profile metadata (kind 0) so to not rely on NIP-65 config from multiple people (author and mods) to know where to post "New Post Requests" and fetch "Post Approval by moderators".

What do you think of adding this:

{
  kind": "34550",
  ...,
  tags: [
    ..., // d, description and moderators
    // "relay" tag is used on NIP-42
    ["relay", "<relay hosting author kind 0>", "author"],
    ["relay", "<relay where to post requests to and fetch approvals from>"], // not "r" so to not index
    ["relay", "<relay where to post requests to and fetch approvals from>"]
  ]
}

or maybe better this:

{
  kind": "34550",
  ...,
  tags: [
    ..., // d, description and moderators
    ["author_relay", "<relay hosting author kind 0>"],
    // "relays" tag is used on NIP-57
    ["relays", "<relay 1 where to post requests to and fetch approvals from>",  "<relay 2 where to post requests to and fetch approvals from>"] 
  ]
}

[vitorpamplona]

@arthurfranca relays added. :)

[staab]

The problem I see (and hey, maybe it's a feature) is that clients don't have any way to avoid requesting notes posted to a community, since any kind can be used normally, and there are no negative filters (don't give me anything with an a tag). I think a clean solution to this problem would be something like #468 but without the encryption (content is just the wrapped event's JSON).

There are a number of problems solved by that NIP. For example, you can post any kind to a group by wrapping it; you can then moderate by un-wrapping and re-wrapping as a moderator. This keeps the original content of the event intact, but allows different special purpose channels to exist.

TL;DR, NACK on this NIP, I'd like to see it folded into #468 and/or #580 by making encryption optional.

[vitorpamplona]

So, similar to the issue of clients not being able to request only non-reply kind-1s, right? I agree it's a pain.

I am not sure if wrapping is a good solution for that. Otherwise, we might get to a point where everything is wrapped.

Somebody could duplicate kind 1 (like nip-28 channel messages) if people wanted a kind that does not show up in the timeline.

[staab]

I prefer wrapping to duplication (nip 28 was a mistake), since you get to keep all the same tools you use for regular nostr, with just an extra utility to unwrap. I think wrapping will be very easy to add support for, and it supports basically infinite use cases (anywhere where you want a different signature, or selective metadata).

[arthurfranca]

@staab: there are no negative filters (don't give me anything with an a tag)

@vitorpamplona: So, similar to the issue of clients not being able to request only non-reply kind-1s, right? I agree it's a pain.

What about pushing for this addition: ["REQ", <subscription_id>, { "kinds": [1], "count": { "#a": 0, "#e": 0 } }]

I suspect relay databases won't have a hard time storing and indexing one-letter tag occurence count.

[staab]

We shouldn't push core changes in an ad-hoc way. Adoption of that syntax may take months to get implemented (cf COUNT, AUTH). Can we solve this problem using the tools we already have?

we might get to a point where everything is wrapped.

I'm ok with this. But we won't wrap everything, because non-wrapped notes are already the standard, and imply "public, broadcast". Wrapping makes sense for relay-agnostic sub-networks: public group post; private group post, public DM, private DM. Wrapping could even remove the need for many existing kinds, and reduce the number of primitives clients have to implement. I.e., people are already zapping and quoting DMs, what if DMs, kind 42s, and kind 1s worked exactly the same way and could be cross published between scopes (private, group, public)? Clients would only have to special case the user's ability to decrypt a given message, and you would automatically have much richer content available in non-kind 1 contexts.

Maybe this is not the place to hash out wrapping, but the more I think about it, the more it makes sense.

[jinglescode]

This is awesome, thanks for starting on this, I just started this app a few days ago, and now going into communities.

I could prototype this concept and lets see how the moderation process feels like.

[arthurfranca]

🚀️

[bigOconstant]

I am not a native english speaker; chances are I overlooked or mis-read something.

So, this is just to clarify:

* Each Community - or, curated topic - must have new posts approved - and, ALL posts - by a moderator?

* Since Nostr has no such things as a name, just an ID, we'd use a new scheme like `ncom1` to find them (which could potentially be embedded in QR codes et cetera)?

After that, here's some things that stuck out to me while reading all the comments here.

* While "moderation god complex" is an unfortunate side effect of giving someone power (which reminds me a lot of Megadeath's "Symphony of destruction" first few verses), it also feels like a neccessary evil. Leaving a community unmoderated can often lead to chaos. Moderating it can give some people too much power. A community is built on trust and expectations. So: Moderators should be allowed to be reported. I noticed that in Snort, I can even see all reports sent from other people, referencing the very events that offended them. This method of public reporting could be used, to inform the community creator/"admin", that certain action should be taken.

* Why is every post approval-first? Many communities, like the meme-focused ones - thrive on fast posting; which becomes very difficult if each and every post has to be verified. And, someone would have to do that. One moderator can only do so much at a time... A community, or curated topic, should have an option to declare the posting schema: approve-first (each post needs approval), approve-after (if a post is deemed unfitting or otherwise to a community, it may immediately be dropped per delete event), freeform (everyone can post and those are seen as approved and are handled in post by up- or downvotes).

* And, in terms of searchability: NIP-05. I am surprised this hadn't been brought up yet. But communities could be made much more searchable by using NIP-05, indicating the authenticity of a certain community as a whole.

As for a little side-tangent: Nostr as a Reddit alternative ought to work out better than Lemmy. I tried it, even run my own instance, but the super seemless nature of Nostr is just much easier to use. Make a keypair, and off you go. Pick a few relays that sound nice - or that advertise topics you want - and start posting. No crazy instance finding and cross-instance configuration. I am all for this NIP PR! =)

Voting has little chance of success in nostr where anyone can generate a public key.

[staab]

@vitorpamplona is there a way to avoid getting community notes in a filter? In the current form, it seems like {kinds: [1]} would include community notes as well as regular ones. This may or may not be exactly necessary, but is, I think, desirable. Again, wrapping would solve this very cleanly by effectively namespacing events of any kind. Let me know if you're interested in more details on that approach, we can chat elsewhere.

[Giszmo]

On the concern of scalability with the requirement for approvals: With multiple approvers, these could also take roles such that automatic approval would not result in all getting the message. For example with levels. Group members only see level 5 approved content by default. Moderators (and users of course) can choose to see level 1 and above, with bots giving level 1 approval.

Then it's also less dangerous to grant level 2 or 3 approval permission lightly. The founder/owner could be level 10 with moderators by default being level 5 etc.

So for example:

• bot1 gives L1 approval to all messages that don't contain links or "airdrop"
• bot2 gives L3 approval to all messages by premium members
• passionate group members with L4 moderation level pre-filter bot-approved content and raise it to L4
• even more passionate group members with L4 moderation level reading all the sub down to un-approved messages discover non-spam with links or discussing the problem with airdrops
• few select L5 moderators approve L4 to L1 and unapproved content in that order

[bigOconstant]

Why should we put the responsibility on bots for auto approval though? Shouldn't we just add some moderation functionality to the relays?

If the user doesn't like the moderation of the relay they can just switch relays.

[vitorpamplona]

Why should we put the responsibility on bots for auto approval though? Shouldn't we just add some moderation functionality to the relays?

Not on bots, but on Community Management clients. Relay operators do not have the knowledge of each of their Communities' topics to moderate them correctly. And forcing each community owner to also run a Relay is unnecessary. This proposal splits the moderation responsibilities between relay operators and moderators to help decentralize the power granted by users of such activities. If a relay is moderating too much or not enough, community owners can take their community elsewhere. If moderators are doing a bad job, any other person can close the community and start doing a better job. Relays operators don't get additional responsibilities.

[bigOconstant]

If moderators are doing a bad job, any other person can close the community and start doing a better job. Relays operators don't get additional responsibilities.

What do you mean any person can close the community? Could you describe that more?

Not on bots, but on Community Management clients.

so you might have a service running with a public key that is a "moderator" that is scanning for new community post. It auto approves new post? that is like a bot to me but might work . how would banned users work?

[vitorpamplona]

What do you mean any person can close the community? Could you describe that more?

Sorry. I meant cloNe the community.

so you might have a service running with a public key that is a "moderator" that is scanning for new community post. It auto approves new post? that is like a bot to me but might work . how would banned users work?

You could have a client that implements a NIP51 list of people with auto-approval status into the community. Or the opposite, a list of people that the client will always reject. More importantly, the same client can then provide tools for users to review what the bot is doing. As @Giszmo said, you can have multiple layers of approvals before you get into the community.

My point is that none of that needs to be part of this NIP. It can all be developed organically as we move forward.

[bigOconstant]

Might I ask, how would a user discover new communities? How would the experience be if there were multiple communities with the same name? What if I the user wanted to get all the post from community "Mustang" ran by moderators:[1346432,3957820] and also community "Mustang" ran by the other moderators[096866432,09788604] who disagreed with moderators [1346432,3957820] about something trivial?

I feel like if a community was just a name then a user could pull post from that name from as many relays as they wanted. But if you make a community like this you are going to get lots of over lap. 15 pics communities all with only a few users and their approval bots would all work differently.

Just trying to understand the flow here.

[vitorpamplona]

Might I ask, how would a user discover new communities?

Clients have this magic thing of filtering and/or sorting by the number of posts, authors of those posts, follows, zaps, reactions, reports, citations, bookmarks, geolocations, and other kinds. Some of us can even run emotion extraction engines to select only happy communities. :)

I feel like if a community was just a name then a user could pull post from that name from as many relays as they wanted.

You can definitely do that. There are no ties to any relays or any protections from copying it. You can even get all the approved content AND the non-approved ones and then approve everything yourself. I don't think a lot of people will follow you on that journey, but you can do that.

get lots of over lap.

We will. And the bigger the overlap we get, the better curation will work (from a user's side). You don't need to follow just one Bitcoin community. You can follow all of them. And if the same post gets in all of them, it means that it is really good and should definitely be seen by you.

[bigOconstant]

I like it. Thanks

[armstrys]

There is a third interesting option here to approve by both the a and e tag. This gives the benefit of ii but would also allow the client and moderation tools to easily flag replaceable events that have changed since approval without losing the connection to the community immediately. An alternative wording that could describe this:

Suggested change

	Replaceable events can be submitted for approval in two ways: (i) by their `e` tag if moderators want to approve each individual change to the repleceable event or (ii) by the `a` tag if the moderator trusts the original post author to not modify the event beyond community rules.
	Post-approval for replaceable events MAY include an `a` tag in place of or in addition to the `e` tag to ensure that the event remains connected to a moderated community after being edited. Clients SHOULD indicate that replaceable events with an approval on the `a` tag, but a conflicting `e` tag have been edited after approval.

[vitorpamplona]

Good point, but we might need to spell that out as a third (preferred?) option

[armstrys]

That makes sense. Something like this?

Suggested change

Replaceable events can be submitted for approval in two ways: (i) by their `e` tag if moderators want to approve each individual change to the repleceable event or (ii) by the `a` tag if the moderator trusts the original post author to not modify the event beyond community rules.

Post-approval for replaceable events can be submitted in three ways (i) by their `e` tag if moderators want to approve each individual change to the replaceable event, (ii) by the `a` tag if the moderator trusts the original post author to not modify the event beyond community rules, or (iii) preferably with both the `a` and `e` tag so that clients can indicate if a post has been edited since approval.

Reasoning for changing that first line was that I had some confusion initially reading the spec whether it was the original post or the moderator approval post that these rules applied to. It is of course obvious once you understand the spec.

[vitorpamplona]

Just committed a change as well. See if you like it

[armstrys]

@vitorpamplona your latest changes LGTM!

[vivganes]

Here, Can we add an 'optional' tag suggestion like this 👇

//optional information while forking a community from an existing one
["forksource", "34550:<source community event author pubkey>:<d-identifier of the source community>", "<Optional relay url of source community>"]

This would provide a clean mechanism for

1. Any client to show unmoderated feeds for 'forked communities' based on the user preferences [This is not possible without this additional information]. Client can simply follow the 'forksource' tag and show the events from old community, before the timestamp of forking.
2. Ability to see how many people have forked my community. This creates a very similar feeling of joy when someone creates a fork of my open-source repo. This provides motivation for moderators to create a quality community.

[vitorpamplona]

how do you know the time stamp of the forking since the created at event will change every time the community has a new moderator?

[vivganes]

Ahhh my bad! Good point.

How about adding this suggestion instead:

["forksource", "34550:<source community event author pubkey>:<d-identifier of the source community>", "<Optional relay url of source community>","<optional timestamp of the fork>"]

This can be considered similar to creating a new git branch from a specific commit

[vitorpamplona]

There is an ambiguity to solve in mentions.

When a Kind 1 mentions the community in the text, the post is supposed to be sharing a community with to the followers and not a post to be approved by the community.

Amethyst posted with a "mention" marker, but the filter to download post approvals must remove mentions if this is the way forward.

{
  "content": "Super active art community. Follow bellow.\n\nnostr:naddr1qqp5zun5qgs0fk6jwz7ejxchh6s7d5p473w7uwffr8pfga9m4sgrgtfz836wp5qrqsqqpphkqfarxc",
  "created_at": 1689305952,
  "id": "119a56648b87c56ba9eb27aa7e571719cd977d2b749888a0e3f96a3165fac16f",
  "kind": 1,
  "pubkey": "460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c",
  "sig": "4abc30e65fd58f6ea838f94f7e76779872ad5b5f3d8b4cbce3c1f47727a131d52689c6e3f263326792ed33cd5fbcc08f4a70823f253abd2cdfa6643d9e7d492a",
  "tags": [
    [
      "p",
      "f4db5270bd991b17bea1e6d035f45dee392919c29474bbac10342d223c74e0d0",
      "",
      "mention"
    ],
    [
      "a",
      "34550:f4db5270bd991b17bea1e6d035f45dee392919c29474bbac10342d223c74e0d0:Art",
      "",
      "mention"
    ]
  ]
}

[arthurfranca]

Probably better to use another letter for "New Post Request". Similar to how quotes are going to use "q" instead of "e".

Edit: In fact, as NIP-27 states, the a tag is optional and should only be used if you "want the referenced event to recognize their mention as a reply" (but now with "q" tag it shouldn't really use "a"/"e" anymore). The only problem would be if reviewing communities throught kind 1 events with a tags becomes a thing using "root" marker, then a new tag letter for "New Post Request" would be better than introducing a new marker.

[mplorentz]

I love this NIP and it's great to see it already implemented in 3 clients in just a few weeks. We are strongly considering adding support for it in Nos. I want to suggest two modifications that are important to me:

• I agree with others that curated communities with pre-approval moderation and approved-until-revoked moderation are similar enough that they should both be accounted for in this NIP. An approvedUntilRevoked flag in the NIP and an example of an approval-revoking event (kind 4551? 1984?) are enough to support this use case, and will lower the burden on small teams of moderators and improve the user experience for certain communities.
• I would love to specify a kind other than 1 for notes intended to be shown "in" a community and not to my accounts main feed. I want to post freely in communities about my niche interests and hobbies without annoying all my followers. I think kind: 11 would be cute as it would have the same semantics as kind: 1, it just isn't intended to not be shown in the main feed. (This kind could be reused for future types of communities that want the same feature, and could even be used to i.e. create topical feeds under your own profile using hashtags. Maybe it deserves its own NIP and could just be referenced here?)

[vitorpamplona]

pre-approval moderation

How would one manage the list of approved people? Would you add 100s of users in the community definition event that are approved to post directly? Maybe a reference to a NIP-51 list? Maybe a separate membership list entry event to avoid creating massive lists? Looks like the filter to get posts could be massive (10,000+ people) if we include all members of a community.

I would love to specify a kind other than 1 for notes intended to be shown

I am starting to think this is a must. But looks like kind 11 is already been used for something else. Any other cool number suggestions? :)

Probably better to use another letter for "New Post Request". Similar to how quotes are going to use q

The use of the a in Kind 1 should represent a reply to a, which is actually not that wrong for community posts: a reply to the community. If the app has a tab for new threads and another for replies, the post should appear in the reply tab instead of the main new threads one.

The issue is when the user just wants to quote it and not reply to it.

Ambiguity

I am not sure what to do here. I feel like this is a bigger problem with quoting any replaceable event kind, since there is no q for them. q is supposed to be used only for id hexes and not for a tag assemblies. We will need a new q to quote replaceable events.

[arthurfranca]

We will need a new q to quote replaceable events

Don't see much problem in setting an event address (instead of id) to q tag when quoting a replaceable event.

[bigOconstant]

After playing with it a bunch on Amythest we definitely need approve until revoked. Just so people can get started really quickly. For more complicated moderation we can write client bots. Most of the clients that have implemented it like flycat, zappit all have show unmoderated options because the flow is just to slow without it. But that would make spam a problem.

[mplorentz]

@vitorpamplona

How would one manage the list of approved people? Would you add 100s of users in the community definition event that are approved to post directly?

I wasn't imagining a list of approved people. Rather a pre-approval community would display all notes from all users, unless a note has been explicitly removed from the community by one of the moderators (maybe via a NIP-32 label?).

However a list of approved community members in a list is another valid style of moderation. But I feel like supporting groups with membership is starting to diverge from the reddit-style type of group and into another type (Discordish), which probably should be in a separate NIP.

No ideas yet on a replacement number for kind 11. But I don't see anything merged with kind 11 yet so maybe there is still a chance it could happen. I think I'll write up a separate NIP for this and see if it gets any traction.

[vitorpamplona]

Folks, since we have so many clients already implementing this NIP with some variations, I'd like to merge this as is in order to facilitate new PRs from everyone else that wants to modify it/add new types further.

@fiatjaf @staab

[fiatjaf]

Gonna change this number.

[fiatjaf]

Moved to https://github.com/nostr-protocol/nips/blob/master/72.md