Add closed communities

[staab]

This is an attempt at superseding #706 and incorporating existing NIPs for community definitions and member lists. The design is worse in many ways, but will be more familiar to devs, and less heavy to implement. I've attempted to compose existing pieces as much as possible rather than introduce entirely new concepts. This proposal competes with #566. This PR depends on #876, if you'd like to comment on the key sharing part please do it there.

[Semisol]

LGTM, except it uses gift wraps which I have stated is problematic on multiple occasions. Depending on the privacy of your group, use SimpleX, or, don't use gift wraps.

[staab]

@Semisol yes, I know, we fundamentally disagree on the viability of this approach. I've been thinking it over for three months at this point, and have gotten input from many other devs about what "good enough" means. In the implementation I also intend to support defense-in depth using relay AUTH but didn't want to specify it before I know what it looks like. Would #566's signature stripping be preferable?

[nourspace]

I find it curiois that members need admin's approval to leave a closed community.

[staab]

I find it curiois that members need admin's approval to leave a closed community.

Originally I had them posting their exit request to the group so people could update member lists eagerly. But membership is essentially equivalent to access to the shared key. Once you have it, you can't get provably get rid of it, so in theory you're a member until the key is rotated. UX things like eagerly removing the group from your joined list are another matter, and can easily be done by sending a copy of the exit request to your own pubkey.

[staab]

Just updated this PR to include a few more things, including some minor changes to NIP 72:

• A new title tag on 34450s to support changing community names
• A new access tag on 34450s to indicate whether the group has public or private components
• Users may post a note to multiple communities by adding multiple a tags.
• I loosened up the language around approvals. I would like to support alternative moderation strategies. I made some other stylistic changes to NIP 72 as well.
• I added explicit support for cross-posting to NIP 72.

I've also removed member lists from this first version. Clients can mostly infer member lists based on who posts to a group.

[fiatjaf]

Can we put the shared key mechanism in the same NIP for now? If in the future it becomes apparent that it will be used in other situations then it can be moved to its own NIP. For now it just creates unnecessary complexity and confusion.

[staab]

Sure, just pushed an update

[abh3po]

how do we wrap keys with ephemeral keys? What is meant by an ephemeral key? I'm new to cryptography, anything I could read up on? might be good to expand upon this on the nip?

[staab]

An ephemeral key is just a key that gets generated in an ad-hoc fashion, for example with nostr-tools' generateSecretKey, and thrown away. It's used instead of a user's regular private key when the identifying information of the public key used to sign is not desirable.

[abh3po]

but wouldn't the user need the corresponding pubkey to decrypt the privkey tag? is it shared out of band? also how does the user get notified about being added on the group? is the kind:24 event shared out of band as well?

[staab]

It's all wrapped inside a 1059, which is p-tagged to the recipient. So clients have to decrypt those to find out what is inside. They can decrypt them, because the payload is encrypted for the recipient's private key.

[vitorpamplona]

I think @staab intended to have two kind 24 events, one with admin role with the editing key and one with the member role (terrible name) for the view-only key.

[abh3po]

okay I think I finally got it, hadn't gone through nip-59 It'd be nice to mention nip-59 on this doc. Was not aware of it and was very confused :P

[staab]

Putting this PR to rest. Relay-based groups are where I'm putting my effort for now, and I'm encouraged about Jeff's work on MLS.