support for community-exclusive posts

[vivganes]

This PR enables community clients to create posts that don't show up in non-community feeds.

This idea started as a discussion in this thread:

https://snort.social/e/nevent1qqsqsvwpvyjhlydwkrg02qm8phkrg6s6gw2yw9v22vvsqp6chv26sqcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsyg8lylgpev09d76ctqpsd3a6w6asx7ljz8zm2u79de88pj59sa267qpsgqqqqqqsmchvcx

[vitorpamplona]

How is the support for this? Have people implemented it?

[vivganes]

How is the support for this? Have people implemented it?

zapddit implements 4549 event kind at the moment. This is the default kind for any community post on zapddit.

Satellite had a plan to get onboard too.

[vivganes]

@lovvtide do you still see this relevant path for satellite.earth communities? Would love to get your inputs here.

[mikedilger]

I like this. I'm going to start coding this for gossip.

[lovvtide]

@mikedilger Awesome! @vivganes Sorry for the super delayed response, I got distracted with other stuff, yes this is still my intention for Satellite. Will be in the next big update.

[vitorpamplona]

I support this idea as well, but I believe kind 1 clients will prefer to operate in a negative way: by following everything from a user and hiding the communities the logged-in user doesn't want to see.

For kind1s, communities are essentially topics within a user feed. I can follow the user or one of his/her topics. However, the natural instinct of Kind1 clients is to follow everything and then remove the topics you do not want.

For instance, I want to see all of @mikedilger's posts but his gaza opinions. I want to see all of @staab's posts but his religious ones. I want to see all of McCormack's posts but the NewBedford ones. Meaning, I don't want to miss new topics from them. When a new topic shows up in the feed, kind1s that support this feature should provide ways to hide just that community (adding the community to the Mute List?).

This should allow general and very specific discussions blended into the kind1 feed for better dissemination of communities.

[staab]

I'm planning to add some form of communities to coracle at some point, and I think a new kind is a good idea. The k tag feels like a hack, but it's actually probably a good way to do this, because it affords a pretty simple version of nostr-within-nostr without any gift wrapping. I think this is a good change, but I feel like it could have very weird downstream effects.

[lovvtide]

@vitorpamplona My basic idea for the UI on Satellite is to have a checkbox on the "New Post" form like "include this post in my main timeline" that is checked by default (in which case the event will be created as kind 1), and if the user unchecks the box the event will be kind 4549. So it's just cloning kind 1. Communities clients should always pull both kind 1 and kind 4549. Regular kind 1 clients can choose to pull kind 4549 also, and do the selective hiding thing if they want (which I think we agree is good for community discovery) but this way the user at least has control over whether their community posts show up by default on clients that don't know anything about communities.

@staab It's totally a hack. The "k" tag is actually only needed for making community-exclusive-non-kind-1 events. You should be able to publish a kind 4549 without any "k" tag and clients will treat that as a clone of kind 1

[vitorpamplona]

community-exclusive-non-kind-1 events

Do we need this? Kind 1 is the issue because of backward compatibility with old kind 1 clients. The other kinds might not have much support yet to justify it. New work can always ignore events that have a community attached to it.

It's similar to the Generic Repost. There is a Repost event for kind 1 and a generic kind for everybody else.

[lovvtide]

Hmm good point, yeah ok I'm fine with just using 4549 as a community-exclusive version of kind 1 and other clients can sort it out if they want to hide non-kind-1 community posts.

[staab]

I left a comment here referring back to this issue, I think we need to have a bit more of a vision here for future composability. A new kind meaning community kind 1 is all well and good, but how do we plan to do community-specific zaps/events/calendars/chat rooms/profiles/reactions/etc? The k hack seems to cleanly solve all these problems. Another option might be to reserve a range, maybe 100000-199999 which could represent community kind {kind - 100000}. So a community-specific petnames list would be a 100003, a community-specific chat room would be 100040, etc. That way we can do anything in the global namespace, or in a community namespace.

[lovvtide]

Another option might be to reserve a range, maybe 100000-199999 which could represent community kind {kind - 100000}. So a community-specific petnames list would be a 100003, a community-specific chat room would be 100040, etc. That way we can do anything in the global namespace, or in a community namespace.

Adding an additional range that "mirrors" all other non-community events is an interesting idea, but the major downside I see with this approach is that it would require relays to implement additional logic to handle these kinds. For example, would events 110000-120000 would be "community-exclusive-replaceable"? If so, relays have to implement this, which seems like a non starter.

It might work if we restricted the new community-range to only mirror regular events. At that point we only need a range 10,000 wide for community events. So it could be 100000-110000.

There are plenty of events that it doesn't make any sense to have a "community version", but it would nice to be able to make use of new kinds in communities. To leave that option open, instead of 4549 for the kind 1 clone it could be 100001

[staab]

it would require relays to implement additional logic to handle these kinds

This is true, but I don't see any other generic way to implement community-specific replaceable events. The simplest thing from a relay standpoint (other than re-specifying everything using community specific kinds in the replaceable range) would be to add versions of 4549 that are replaceable and parameterized-replaceable. At this point maybe we're trying too hard and re-specifying everything with a new kind would make the most sense

There are plenty of events that it doesn't make any sense to have a "community version"

Give me an example (other than NIP 98 auth)? I bet almost everything would make sense in a community context.

[vitorpamplona]

Give me an example (other than NIP 98 auth)?

There is no "main feed" for other events. A Reaction of a community post will likely be only seen at the community level anyway. Same for zaps, labels, and reports. NIP-46 and 47 don't have community versions of them. DVM ranges also do not need an exclusive version. NIP-65, kind3, kind 1, nip-15, Mute List, Pin List, People List don't need exclusive versions. Not even NIP-28 chats need protection from a general feed. Calendar events fit inside a Calendar and the Calendar Event itself can be a community calendar today already.

So, I am on the opposing side. I don't see any use case today that will justify another community-exclusive kind. But if it happens to exist, it would be easier to just make that a new kind, instead of duplicating all event kinds straight out of the gate.

[lovvtide]

Somehow I imagine there would be a lot of resistance in convincing people (especially @fiatjaf haha) that it was worth it to modify NIP-01 just for communities. Tbh I'd rather go with the original k hack thing than make it more complicated to implement a relay.

As for the events that don't need a community version - I'd say profile, contacts, delete. All those should probably remain strictly global things, otherwise stuff we run the risk of things starting to get super complicated in subtle ways

I think @vitorpamplona has a good point that backwards compatibility is only really an issue for kind 1 (and I would add maybe long form posts and kind 1063 media) at the moment because those are already implemented on some kind 1 clients to dump them in the main timeline, which is thing we actually need to solve here (otherwise we could just use all the same kinds)

[vitorpamplona]

Somehow I imagine there would be a lot of resistance in convincing people (especially @fiatjaf haha) that it was worth it to modify NIP-01 just for communities.

I think that is settled. We will have a special kind 1 just for communities. I believe the debate is on the other events. And how many future needs we can actually predict.

[staab]

There is no "main feed" for other events.

• I might want to see a user's reactions (and zaps) scoped to a community. Coracle has a likes feed.
• Labels might be scoped to a community — in fact, open moderation could be implemented using labels
• Reports might be scoped to a community — maybe the content violates stated community guidelines
• Kind 3 could mean "follow in community" but not global
• Kind 1 might mean "this is my profile in the community"
• Marketplaces might be scoped to a community
• NIP 28 messages don't need to be scoped (because they already are), but chat rooms might be

I don't really think NIP 46/47 are relevant to the discussion. DVMs are weird, so I'm not going to argue that one. Lists probably don't need to be scoped (except for moderation use cases potentially).

So while most of the actual events above don't need to be shielded from global filters, they do make sense as concepts, even for reddit-style public communities. For private communities, many of these things take on a lot more utility. Of course, we might need a different primitive for those, but hybrid public/private communities would make sense too.

Just to focus in on one, I might want to be known as a different name in a particular community, without obscuring my global identity. In a starcraft forum I might be @zergbob, and in my private church community I might use my real name. Globally, people don't care about my starcraft vanity handle, and shouldn't know my real name.

[fiatjaf]

I agree with @hzrd149 on #847 (comment) that this k tag is a horrible hack that breaks everything. Let's make different kinds for each post that people want to display exclusively inside communities.

[staab]

Let's make different kinds for each post that people want to display exclusively inside communities.

Maybe I have a different idea of what communities should encompass, but this will result in duplicates of 40 or so existing kinds, and many more to come. Taking one at random, what if you wanted to post a kind 1311 Live Chat Message only to a community? A similar justification could be made for almost any part of the spec.

Edit: I guess I'm just repeating myself, sorry. But I haven't heard a compelling argument for why the 37+ kinds that aren't currently supported by communities shouldn't be.

[fiatjaf]

@staab each of these kinds will have to have support manually added by clients for them to work inside communities, right? Then in the process of adding such support the clients may consult a kind conversion table and hardcode that into their app, why not?

[staab]

Then in the process of adding such support the clients may consult a kind conversion table and hardcode that into their app, why not?

Yes, you're right. Re-specifying everything isn't elegant, but it isn't a lot more work. The dumb approach wins again.

[fiatjaf]

I've added more kinds and more context to #848. Let me know what you think.

[vivganes]

I've added more kinds and more context to #848. Let me know what you think.

@fiatjaf I like your approach because this simplifies the client implementation for both community and non-community clients

Thanks for the inputs.. Shall I close this PR in favor of the one you created #848 ?

[fiatjaf]

@vivganes if you like it then I think yes, you can close it.

[Semisol]

Bad idea. Community exclusive kind 1 notes should not share the same kind as something else that is community exclusive.

[vivganes]

Retiring this PR in favor of #848