Add NIP-87 private groups

[staab]

This is yet another encrypted groups draft. It follows #686's modification of #468 and splits it out into a separate NIP that can be used by both group implementations. #686 attempts to solve small groups with no moderation or key rotation, this NIP attempts to solve large groups with moderation and key rotation.

This NIP is inspired by (and very similar to) @earonesty's #580 with the following differences:

• Instead of identifying a group by event id, a group is identified instead by a pubkey.
  • This allows the admin to stay anonymous by not signing anything with his key.
  • This allows the group to publish public events on its own behalf.
  • This also allows for less stateful key sharing and validation.
  • This eliminates kinds 405 and 406, which require clients to stitch multiple groups together in a chain.
  • It ties authorized group-admin actions to event validation, which is simpler than the stateful validation used here.
• It combines 400 and 402 which are both kind 0's for the group.
• It has a broader set of supported use cases - it's not tied explicitly to chat.
• It allows members to request entry/removal, and notifies current users of a key rotation.
• It allows for multiple compatible types of moderation with no elevated permissions for moderators, based on end user preferences.
• It uses @vitorpamplona's version of wrapping, reducing the risk of leaked events.

I also have to credit @water783 for his work on alias exchange and another draft similar to this one. The main difference is that this NIP doesn't require a monolithic member list for key sharing, instead membership is determined by possession of a key.

[vitorpamplona]

Maybe the right name for this is Trusted Groups. Since any member can add any stranger, and any stranger can make the entire group visible, privacy is directly dependent on your trust in the behavior of other members. And maybe privacy is not an actual expectation of the group (because it is so large), which simplifies requirements a lot.

For instance, the Facebook group with 8M people might be closed/private, but everyone knows the admin will not be able to review people when joining. So, I can't say bad things about.. say my family... in the group. They might join in the future. And that will be bad.

On the other side, smaller Facebook groups do have a new member evaluation procedure when joining. The admin puts up some rules and evaluates people on them. It's also not super private. If the group is 3000 like-minded people and the admin is kicking out everyone that misbehaves (or doesn't share the same mindset), I might say things the "other side" might not like in peace. Even if "the other side" people join, I don't care about their opinions anyway. A closed group doesn't necessarily have a strong privacy expectation.

Those two groups require different implementations in my mind.

[staab]

I hid some comments to keep things focused. The summary is there are three kinds of groups:

• Small groups (NIP-17 (old 24) Sealed Gift-Wrapped Messages for Private DMs and Small Group Chats #686)
• Large groups where members trust each other not to reveal their membership (or where membership is not sensitive information)
• Large groups where membership is protected by admins requiring Shamir's secret sharing where you can do M out of N decryption (?)

This PR targets use case number two.

[staab]

I have removed NIP 44 and 59 from this PR, please see #715 and #716 for discussion on those.

[manimejia]

I hid some comments to keep things focused. The summary is there are three kinds of groups:

• Small groups (NIP-24 Sealed Gift-Wrapped Messages for Private DMs and Small Group Chats #686)
• Large groups where members trust each other not to reveal their membership (or where membership is not sensitive information)
• Large groups where membership is protected by admins requiring Shamir's secret sharing where you can do M out of N decryption (?)

This PR targets use case number two.

Maybe I don’t get it … but it looks like the end user is gonna have to choose from (now) three not-obviously-different types of group, BEFORE a group is created (whose size or moderation needs might change any time in the future)? That alone is a recipe for disaster IMHO. To boot… am I right in thinking there is gonna be a secret key that group members need to remember or “carry” with them to get in … and one that will change periodically as people are booted from the group?

Sorry if I’m being dense… (or seemingly pessimistic, cause I really am not) but the UX scenario I’ve described above will not fly well IRL.

Please tell me I’m mistaken.
Help a poor noob to understand.

[staab]

The client developer will be the one to choose the implementation based on the user experience they're shooting for. Coracle will support both small and large groups, but with different interfaces. The third option in that list is theoretical, hopefully someone smart will make it a reality.

The shared key management is a relevant question, but it's not any more difficult than securing your regular key, and will only need to be done by people administering groups, so I don't think it's a big problem.

[manimejia]

Thanks. How can key usage be more transparent to the end user, who may have 5 or 10 (or 110) groups that she belongs to? Would this require her to “manage” separate keys for each group … (with like a nos2x kind of experience) If so… maybe we’re forcing dependence on a bunker style key management tool across the board for users?

(Cause private groups WILL be big and used in multiplicity by everyone.)

[manimejia]

What I’d LIKE to see (that is IF group access is NOT provided by a user’s own npub, which IMHO would be best for all cases) … if users need to have separate keys for each group, their application should be “automagic” and behind the scenes. This is what (I imagine) a key bunker could do. Yes?

[staab]

Group access being related to the user's own npub has the same metadata leakage problems NIP 04 has, so it's a non-started. Bunkers are one solution, another one is just a good backup solution for group keys — they could be encrypted by the user's own key and stored in nostr, downloaded as a standard encrypted file, backed up to a key manager, Google Drive, whatever. That's not a hard problem to solve, and can exist in the application layer.

[vitorpamplona]

How about a simplification of this NIP? What's the absolute minimum a Client can do to create private groups?

"Voting on a post" seems unnecessary at first glance.

Are we going to have Group Managing-clients and clients that simply participate in groups? Something similar to Moderated Communities?

[staab]

I was thinking about that yesterday. I think you're right, existing NIP 72 facilities should be re-implemented inside groups. A group could also have an optional moderated community attached making it a private view of the community.

On the other hand, it's hard to remove because groups do need moderation outside of the NIP 72 case, so unless groups are tightly coupled to a community, it's hard to re-use NIP 72's moderation.

In my ideal world, moderation would be a separate concept that could be applied to any event. Something like this:

• I publish a moderator list with an e or a tag pointing to an event I created (could be a note, community, group, NIP 28 chat room, whatever)
• People can ignore it, or listen to moderator opinions about that event (hide/show replies, community posts, group notes, chat messages, whatever)

NIP 72 is much too rigid in my opinion, because it couples the moderator list to the community creation event. Should I write this idea up as a separate NIP?

[vitorpamplona]

Well, I was kinda hoping for the opposite: a very simple moderated group chat.

My use case is short-term projects: Billy, Chris, and I have to coordinate the party tonight. I create a private chat. Add them to it. We do our thing and that's it. The group will just fade away from my contact list.

[staab]

Isn't that use case supported by NIP 24?

[vitorpamplona]

Isn't that use case supported by NIP 24?

Somewhat. Have you used Slack before? It's the difference between DMing 3 friends directly and making a little private group to discuss the "project". Direct DMing is loose, the second has a purpose/finality. It's a different vibe.

I imagine the same tool can be used for class projects in school.

I am realizing now that this PR is not focusing on these types of groups. This is for much larger endeavors. True Communities.

[manimejia]

I'm a nobody, but I don't see a problem with any of this.

Let NIP-72 moderated communities BE the defacto standard. ADD opt in functionality for group creators (and users) via additional NIPs. Clients and relays can support incrementally (and hopefully transparently).

Want possibility for "default" mod list to become "opt in" list for group user to pick (one or min number of) mods? It's a NIP

Want possibility for group users to "suggest" new mods by adding their name to a (linked by mod) NIP-28 list? It's a NIP.

Want possibility to make group metadata and content private by "gift wrap" encrypting for each group user, using their own npub? It's a NIP. (Cause gift wrapping events in general should be its own NIP)

Want possibility to scale your group to thousands of users? "Gift bag" (it's back) group messages for (assigned or elected) mods to then "gift wrap" for the rest of the group. Make sure your clients and relays implement this NIP.

[manimejia]

But wait ... maybe we DO start with a whole new group architecture? One that scales just as readily (extensible by NIPS as my above comment) but is based on an npub. Representing groups of npub users, this architecture actually does make sense for the possibility to do the same things with groups of people that one might want to do as a single person.

[staab]

Somewhat. Have you used Slack before? It's the difference between DMing 3 friends directly and making a little private group to discuss the "project". Direct DMing is loose, the second has a purpose/finality. It's a different vibe.

Yep, I get that. Sounds like the proposed (and ditched) "subject" tag would have been enough? You could potentially hack that together by adding another recipient too.

But yeah, this is definitely intended for bigger things.

[staab]

I am going to close this for now in favor of #875.