using multiple independent kinds for community-scoped events

[fiatjaf]

Hopefully this supersedes #753.

Adds a table of new possible kinds that can be published inside communities:

Community-scoped Kind	Description	Original Kind	Original NIP
4549	Community post	1	1
10500	Community-scoped user metadata	0	1
10501	Community-scoped follow list	3	2
4548	Community file metadata	1063	94
30500	Community long-form article	23	23

Justification

Why not use a single event kind with a tag indicating what other kind this event refers to (as in #743)?

Why not have a single event kind in the entirety of Nostr and just use tags for everything? The answer is that kinds are a simple way for clients to scope what they want to handle and what they don't want to handle. They can query just what they want and that's it.

But they can query for only the tags they want!

Yes, but this is less efficient querying, and for what reason? For nothing.

But I want FLEXIBILITY

I know, programmers have this natural desire to want flexibility, but in the context of a protocol that wants to remain simple and open, flexibility is actually a heavy tax on everybody. It is much better for the health of us all if we can agree to a standard and hardcode that standard into our apps by consulting a central table of rules while in the process of writing code -- instead of having everything be dynamic and handled at runtime by the clients. Incidentally this also makes apps 0.001% faster and events 0.1% smaller (numbers made up).

The idea is that whenever someone wants to support a new event kind inside communities they come here and add a new row to the table and that's it.

@vivganes @lovvtide @vitorpamplona @mikedilger @hzrd149 @arthurfranca @reyamir

[staab]

I'm impulsively approving this, having had my mind changed 2 minutes ago. I reserve the right to change my mind again (because that's kind of my thing) when I try to implement private communities using this NIP instead of a new one.

Edit: I would expect at least live streams, calendar events, and marketplaces to be community-scoped but we can add more PRs as implementations emerge.

[fiatjaf]

I don't know about private communities. NIP-72 is for public communities, right? For private communities I thought you wanted to gift-wrap all things, then I don't know what to do.

[vitorpamplona]

Either way works for me. I am adding all these event kinds as if they were part of the feed anyway.

[hzrd149]

I think this make the most sense.
However ( scope creep ) would it make sense to have an addition kind for kind:6 repost events in communities? I think there is a good use-case for "reposting" other notes outside of a community into a community

Also I'm going to ask again. but I assume replies to kind:4549, kind:30500 would be kind:1 and follow NIP-10

[staab]

Good point on reposts, those are important for cross posting between communities. I think replies could be either kind 1 or the new kind depending on the user's intent, but the default should be to continue posting in the community.

Regarding encrypted groups I think key management may be orthogonal to community definition, it may be preferable to compose them (using wrapping), but we'll see.

[vitorpamplona]

Classified Listing, calendar, live events and their chats, pin list, and NIP-28 public chats could also be included to receive new event kinds

[hzrd149]

@staab I think it make sense to keep replies kind:1 since most client already know how to handle "reply threads"

@vitorpamplona I think this might be going too far, or we need to revisit what we think communities should be.

Communities as they are implemented now are a single page of moderated content posted by anyone on nostr and approved by the mods. but if we introduce an alternative kinds for all other kinds of events then we are effectively making a "mini-nostr" inside of nostr

If the goal is to have "groups" that span every NIP then I think we should keep the kinds as they are now and clients will have to find ways to either show or hide posts made to these "groups".
However if communities are supposed to be similar to reddit. in that they are a single page of moderated content. I think it makes sense to create a few more kinds.

[vitorpamplona]

The way I originally imagined, communities would be fully fledged groups of people that can share any Nostr event inside its space.

Quite literally a sub-nostr focused on a topic, with moderators.

But I understand if people want to take it into a different direction.

[fiatjaf]

I think it is fine to have a big bunch of kinds -- as long as you're fine with not all clients supporting all them.
Please add more kinds to my PR.

[hzrd149]

Quite literally a sub-nostr focused on a topic, with moderators.

Thanks for the clarification. but couldn't this already be done with custom relays and NIP-42 for only letting certain users in?

[staab]

Replying with kind one brings back the original problem of clients that don't want to care about communities having to sort stuff out in memory.

This is scope creep for communities for sure, which I'm not opinionated about. I am working on a spec for generic (encrypted? may become optional) groups right now (#706). If 72 becomes that, that's fine with me. But I'll continue work on groups if there is a desire to keep 72 focused on reddit-like, which might make sense given the interest from reddit and the number of well built reddit-like clients.

[fiatjaf]

@hzrd149 I share with you the opinion that these communities should be made using custom relays, but people want to do these open communities that use multiple relays, so that's fine. We can have different approaches being tried out simultaneously. This PR is for the relay-independent communities.

[fiatjaf]

So let's do kind 4549 for generic replies inside communities? Or another kind, 4547?

[vitorpamplona]

Quite literally a sub-nostr focused on a topic, with moderators.

Thanks for the clarification. but couldn't this already be done with custom relays

Relay-centric communities don't make any practical sense to me since events can be easily rebroadcasted and lose their context. But somebody can try.

NIP-42 for only letting certain users in?

Communities are publicly read by anyone. The idea is not to make them private but just to link stuff.

If I manage a soccer team between friends, for instance, that can be a community. I am going to have a page, a feed, a calendar, a public chat for the fans, live streaming of events, and classifieds for merchandise.

[hzrd149]

@vitorpamplona I see the use-case for general "groups" or "communities" inside of nostr. But I'm just worried where it could end, we could create alternative kinds for groups but the only purpose that would serve is to keep the groups from cluttering up the other social clients.
I'm concerned about any implementation that would create a nostr-in-nostr situation. I don't think it would stop with just one level. there could be a good use case for groups inside of groups. in which case we would need nostr-in-nostr-in-nostr. etc

I know I'm going off my own interpretation of NIP-72, but I think it makes sense have "communities" stay focused on the simplest implementation. i.e a single moderated page of content. any more and I think we risk clients never adopting them because they would have to implement too many new kinds of events.

@fiatjaf I don't see any issue with using kind:4549 as replies since it would be the communities equivalent to kind:1 👍

[vitorpamplona]

I'm concerned about any implementation that would create a nostr-in-nostr situation.

I don't see any way to avoid it. It will happen no matter what we do. It can be centered on relays (like private workspaces for companies), events (chats, communities, labels) or pubkeys (DVMs, subaccounts, etc).

What I tried to do was to turn the "nostr-in-nostr" situation into a clearly marked context. By allowing any event to cite the a tag to a community, it essentially creates a #hashtag with an owner to the hashtag itself. Compared to relay-centric communities, these events will never lose their context. And in the most generic terms, that is all that communities are.. Moderated "Context" to any event. It's exactly the same as hashtags (no owner), or labels (single owner), but with moderators (multiple "owners" keeping the consistency).

[mikedilger]

I'm in favor.

[hzrd149]

@vitorpamplona Your right. and honestly I don't know what to do about that. there is a legitimate need for fully moderated contexts in nostr
I cant think of any better solution than what you have suggested. although the creation of alternative contextual kinds for every existing kind worries me.

Honestly the only push back I have for this is I don't want to see the simple reddit-style implementation of "communities" as they are now disappear. since I think they are a good way to loosely organize people around a topic

[vitorpamplona]

alternative contextual kinds for every existing kind worries me.

Yep, but we have been creating contextual sub-kinds for a while. So, I also don't think we can avoid it as well. In the end, we are going to deal with a huge number of copy-cat events for different contexts. No matter what we do, there will be more copy-cats than original events in the long run.

Honestly the only push back I have for this is I don't want to see the simple reddit-style implementation of "communities" as they are now disappear.

I am not sure if I understand why. Clients don't need to implement all community features to have communities. One can definitely create a kind1-only community client like Reddit.

In fact, I always thought the opposite would work better. Calendar clients would support community calendars better than Community clients support Calendars. This will happen to every event kind. Community clients might just display a calendar, but people are going to use a Calendar client to browse and RSVP to community events.

Maybe you are assuming that just because there is a community, users of that community MUST use a single client to go through all aspects of the community. That's is not the way to go. Community users will use many clients to help manage each part of their communities.

[hzrd149]

@vitorpamplona apologies, I don't time to respond now and I need to think more about what your saying. I will try to respond when I get a chance. but Ill be traveling for a few days.

[vitorpamplona]

Sorry, I am pressing buttons in the wrong PR. :(

[hzrd149]

@vitorpamplona I've had some time to think about this. I'm probably still missing something but here goes.

Your idea for "communities" would be a contextual moderated overlay that covers most of the existing NIPs. of course it makes sense to start with kind:1 text events, but you see it expanding in the future to most common event kinds where nostr apps would have support for a "community" selector that would let a user select either "global" (nostr as it is now) or a specific community.
This would allow users to essentially have smaller moderated versions of "nostr" ( the social network ) inside of nostr the protocol.

The way I see "communities" is similar to reddit. where they are a single page of moderated content.

From what I can tell our ideas aren't incompatible. as you mentioned it would be possible to build the reddit-style communities inside of your idea of communities.
However I think where our ideas differs is in the complexity. Ill try to explain.
Going forward Ill stop using the word "communities" and instead refer to them as "moderated contexts"

I theory I think it could work. however in practice I think only a few apps will implement it.
Putting aside the small inconveniences of having two kinds for most events defined in existing NIPs. I think the complexity comes from the moderation. If switching between "global" and moderated contexts meant just adding a {"#a": ["34550:<pubkey>:<d>"]} to all requests a client made to relays it would work.
However if a client wanted to handle the "moderated" part. It would have to load all the approval events.

And approval events is where all the complexity is. to efficiently load the approval events a client must first load the "community" creation event. get the list of existing moderators. then load their latest approval events, or filter down to the specific event ids ("e" tags) the client is looking for.

So an existing app that uses {"authors": ["<pubkey>"], "kinds": [1], since: <ts>} to load a users "social feed" now has to have an additional mode that loads the mod list (via community creation event) then the approval events relating the the user being viewed. then aggregate the approvals so it can hide events that are not approved.

Its not like this couldn't work, but IMO one of nostr's strengths is its simplicity. I was able to easily load and display many of the existing NIPs in noStrudel because in most cases it only took one query. building the existing community views were at least twice as hard due to needing to load the approvals (moderation)

TLDR; if my summary of your idea is accurate. then I don't think I can support it.

Back to this MR. I support changing NIP-72 community posts to a new kind, only because It makes sense to not clutter up the kind:1 feed with posts users are intending to post to a specific community.

Sorry for the long message and I hope I understood your idea correctly.

[vitorpamplona]

Makes sense, but approvals will always exist independent of using new exclusive event types or not. If you don't want approvals, then just use user labels like Coracle does. You don't need the complexity that NIP-72 needs. All new event kinds that are exclusive to Communities should also be approved by moderators.

[arthurfranca]

So let's do kind 4549 for generic replies inside communities? Or another kind, 4547?

Yes, please another kind. If kind 1 had say kind 11 for replies it would've been possible to fetch just follows "root" events as many clients want (people asking for "e" tag absence filter feature).

10500 | Community-scoped user metadata

Imo nack. If one wants a different identity, the most simple path is to use another privkey + kind 0. Same identity should be used throughout the nostrverse.

10501 | Community-scoped follow list

Maybe nack. NIP-72 wise, people are expected to follow communities (we need a list for that) not users? They may become "friends"(?), though, to message each other. Like with this event example using @vitorpamplona Relationship Status NIP paired with Unbounded List NIP's "n" tag. Edit: I get now that 10501 is for a tags (forgot clients were using kind 3 for that).

The rest ack.

[fiatjaf]

@lovvtide @reyamir what do you think? Can we agree on this and merge?

[reyamir]

I'm in favor

[vitorpamplona]

Not to be annoying about this but I would like to see 2 clients implementing some of these new types before merging. I think this "rule" of ours is important.

[reyamir]

Not to be annoying about this but I would like to see 2 clients implementing some of these new types before merging. I think this "rule" of ours is important.

yup, I'm already working on it for Lume

[vivganes]

Yes, please another kind. If kind 1 had say kind 11 for replies it would've been possible to fetch just follows "root" events as many clients want (people asking for "e" tag absence filter feature).

I agree with @arthurfranca as this would help us treat the community comments (like reddit) different from the root level posts into the community. This also helps us avoid that additional filter to see if a 4549 event is a reply to something else.

I would like to see 2 clients implementing some of these new types before merging

@vitorpamplona - 4549 is already implemented in zapddit. All the replies are kind 1 though. Do you think we need to implement long form event kind also in order to merge this PR?

[fiatjaf]

Reading this spec more closely I realized that there is a much better way to do this (maybe):

Since the moderator approval of any event requires embedding the entire "post request" event inside the content of the "approval event", why not make the requests also be enveloped like that and use a separate kind for that envelope only?

This way the envelopes won't show up in anyone's feed, and when browsing a community clients already have to query the kind:4550 "approval events" anyway, so they can easily disassemble the encoded original events from their .content.

This is probably similar to a gift-wrap and @staab's closed communities idea, except it's without any encryption?

[basantagoswami]

Probably a dumb idea, but we can probably solve a lot of issues, if "normal" posts, such as kind 1 events and blog posts intended to be shown to your followers had some kind of single letter tag to denote that it is meant for your followers. For example:

{
  "tags": ["j", "timeline"]
  ...
}

Now a client can get all posts from people you are following, short notes, blogs, or anything else, without replies, or posts to communities, public chat (we don't need a different event kind for public chat then), etc. You can even write posts publicly to people without it polluting your followers feed, like how you could write on other people's wall on Facebook.

It might be dumb, because relays now have to index a lot more, and old posts stop appearing in people's feeds if clients decide to show only posts with the timeline tag on them by default.

You would also be able to post something (say a blog post, or NIP-94 file event) to a moderated community, a job board and your followers as well at the same time if you want.