NIP-C0: Communi-keys

[NielLiesmons]

A simpler and more (backwards) compatible proposal for Communities on Nostr.

I'm building on this in Zapchat.

Read here

[fiatjaf]

This can either be read either as NIP-72 or as NIP-29 depending on the interpretation. In the first case it is a bad idea, in the second it is redundant.

As a community owner how do you prevent unwanted spam in your community if you're not using a special relay?

[NielLiesmons]

1. I wrote about the benefits more here: https://njump.me/naddr1qvzqqqr4gupzp22rfmsktmgpk2rtan7zwu00zuzax5maq5dnsu5g3xxvqr2u3pd7qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcqpd3k7mtdw4hxj6m909esrgk9gp

The existing NIPs introduce redundancy and complexities I don't want without offering me what I do need.
None of them incentivizes running relays.
None of them lets me target multiple communities.
Etc...

2. By running a relay, that's the point.

With the key pair, of course. Building on what services like relay.tools already start to provide. Clearer communication/access specs for the admin's client <-> relay are needed though, definitely would agree with that.

[staab]

I love this idea so much I already built it.

I used to hate NIP 29, and I still do. I used to, because it overcomplicates communities. I still do, because even though it's no longer incompatible with relay-based groups, relay-based groups are so simple they almost don't need to be specified. They're also now rolled into the NIP 29 spec, and so there's no NIP you can use to refer to them without also referring to the (necessary) complexity involved in creating authenticated sub-groups.

Let me define relay-based groups:

• A relay url is the identity of the group
• The relay enforces access via auth and access requests
• The relay advertises supported content types via nip 11 and enforces that using OK messages
• The relay has a pubkey (used to be pubkey in NIP 11, but going forward should be self)
• The relay can use the pubkey to do extra stuff, like:
  • publish notes as the relay (see flotilla)
  • Implement NIP 29 metadata for sub-groups
  • Declare what relays are alternates for the group (see my discarded federation proposal)

To address some points in this NIP:

Current community management solutions on Nostr often require complex relay-specific implementations

Yes, NIP 29 as the baseline is awful. I strongly contend that NIP 29 groups should only be considered "sub-groups" within a relay. In order to enforce permissions to sub groups, you do need all the complexity involved in NIP 29. But permissioned sub-groups are now optional, with the default being "unmanaged" groups. This means that any relay can be used as a relay-based group with no changes. Permissions, both on the top level and on the sub-group level are "progressive enhancement".

lack proper decentralization

Yes, identifying a group with a relay means that groups are dependent on the relay to continue hosting the group. In normal broadcast nostr (which forms organic permissionless groups based on user-centric social clustering), this is a very bad thing, because hosts are orthogonal to group identity. Communities are completely different. Communities actually need someone to enforce community boundaries, implement moderation, etc. Reliance on a host is a feature, not a bug.

This doesn't mean that federation, mirrors, and migration can't be accomplished. In a sense, leaving this on the social layer is a good thing, because it adds friction to the dissolution/forking of a group. But the door is wide open to protocol additions to support those use cases for relay-based groups.

don't allow publications to be targeted at more than one community

First, I'm not 100% sure this is desirable. But I agree it's interesting, and could be very cool. One possible downside is the same as when people spam hashtags #nostr #asknostr #introductions #bitcoin #etc. Another possible downside is that posting to multiple groups simultaneously might fragment the conversation. If some clients fetch replies from other groups, that adds context to the conversation that other more exclusive clients might lack, making things hard to follow for users.

At the same time, I think the objection is completely wrong. It's quite easy to add multiple h tags to a single post (in fact I've seen that in the wild). It's up to the relays/clients to decide whether they want to accept multi-group posts by implementing policy based on how many h tags there are. Another approach would be to use reposts to "cross-post" a broadcasted post into a community. Each repost would have only one h tag, and the conversation would center around the repost, not the original content (unless the client encourages users to join the "global" conversation). I think this is the right way to handle it because it makes it explicit whether the conversation is happening at the group level or the network level.

Any existing npub can become a community

This is the main flaw of this approach, and as @fiatjaf said the main problem with NIP 72 communities. This couples owner identity with group identity in a way that can't be decoupled. Community owners change, and communities might migrate from one platform to another. Using relays recognizes this fluidity, using a key sets a lot of things in stone unnecessarily.

Relay-based communities don't preclude the use of signatures either. The self field in NIP 11 allows relays to publish events as themselves (rather than their owner), which allows for publishing metadata, moderation events, invite codes, all in a neutral or automated way.

Simplified relay operator implementation compared to other community proposals

Just to re-iterate, Flotilla's flavor of relay-based groups allows every aspect of community management to be completely optional, from AUTH to sub-group permissions, to allowed content types, to multi-h allow/disallow, to relay management API support.

Hopefully this is helpful. I should probably write a detailed how-to for relay-based groups, because they're so un-prescriptive as to be invisible. I think that's the way to go, but it makes it hard to spec, because nothing is actually required.

[NielLiesmons]

I'm okay with most of this and am probably prepared to follow you.

Open questions I have:

1. How does a community switch relays then? While keeping their identifier (that everyone stored) as usable, of course.
2. How can I edit an h-tag after publication of a non-replaceable event? I need targeted publication to not have fixed targets forever.
3. Cross posting content is not a solution for me. You don't send a mail to one person and then forward it to the other people you wanna send that mail to. I want to enable to users target content in a straightforward way. I'm not gong to ask a dev of a photography app to publish their release in one community and then cross-publish (what is that even then?) it the other communities he wants to target.
4. I like, a lot, that you're building on NIP-11 and NIP-29 didn't lead me to that understanding in the slightest
5. I naively thought (and probably still think) that relays need keys as identifiers, regardless of any community proposal
6. What's a benchmark for where you see community owners change? As in: communities, with the same id, where the leaving moderator poses an actual threat by knowing the private key. I don't find examples of that myself.

[jeremyd]

Here is a brief outline of how I think communities relate to relay access control schemes in the modern nostr world. Comments welcome on the gist and editing may happen until I can clarify how I see the relationship between communities and relays.

https://gist.github.com/jeremyd/6d52e4d14d513cd3a6f55d982259e772

[luigi1256]

A simpler and more (backwards) compatible proposal for Communities on Nostr.

I'm building on this in Zapchat.

Read here

You can add relays to a NIP-72 community
The communities list is kind 10004
you can already post a note that refers to a NIP-29 chat, in NIP-72 communities

[NielLiesmons]

Community owners change, and communities might migrate from one platform to another. Using relays recognizes this fluidity, ...

If you make Relays the authority, how did you not just shift the same problem to the relay?
https://njump.me/nevent1qvzqqqqqqypzp22rfmsktmgpk2rtan7zwu00zuzax5maq5dnsu5g3xxvqr2u3pd7qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcqyzr3h77k7xxzx00kkklfzzulpunzs9t84saexegu4yrk49cvyf7yywjes3k

[bitkarrot]

I wrote some thoughts down on a gist here about communities, primarily it being too narrow a definition. If there isn't a consensus in the next month, we'll just use the NIP72 tag to signal communities.

https://gist.github.com/bitkarrot/c2b27afe4809fbabe929e8af8c7a2b58

[jeremyd]

@staab what would I need to support flotilla's mod features, same as nip29 with the relay key stuff? If you have a proposal let me know, I am getting closer to doing this nip29 feature I think, I really just want groups to be able to moderate in-app. chachi and flotilla are the only nostr apps that have implemented any kind of moderation features, so it is a bad look to have them not working for my relays that don't understand nip29 yet. #soon

[staab]

Here's the guide I promised: https://habla.news/a/naddr1qvzqqqr4gupzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezqqxnzde5xyersd33xscrwwfh5ekns6

Communities should require very little special relay support outside of "rooms" (NIP 29 groups), which should be totally optional. A combination of NIP 56, LIMITS, and NIP 86 would probably be enough to do moderation (and in my opinion should replace the stuff currently specced in NIP 29, because it would end up being a superset of functionality), but no one has done it yet.

@bitkarrot I think you're aimed as something very different, but I don't think there's any reason why an organization shouldn't have its own distinct key and profile. I just wouldn't overload a profile with a group. It's a neat idea but I feel like it runs afoul of the object-oriented programming advice to "use composition over inheritance".

[bitkarrot]

The only point I am making is we should not label businesses as communities.

This is incorrect categorization and therefore "communities" is the wrong word to use, it should be updated to organizations.