I think I cracked the code on private groups. Long-form post here:

Habla

A Proposal for Private Groups - hodlbod

An elegant approach to private groups - access control based on a shared, hosted private key, rather than cooperative relays.

Instead of relying on relays to implement access control as in this PR (https://github.com/nostr-protocol/nips/pull/566), we could combine the Gift Wrap proposal (https://github.com/nostr-protocol/nips/pull/468) with #[0] 's nsec bunker to create private groups with easy administration and moderation! Gift wrap fixes DM metadata leakage by using a temporary private key to send a DM to a recipient. The recipient decrypts the wrapper to find a regular nostr event inside. This could be another kind 4 as in the proposal, or anything else. Which means you can send kind 1's, 7's, or anything else in a wrapped event. Now suppose you had a pubkey that you wanted to represent a group instead of a person. Put its nsec in a (modified) nsec bunker, and now you can allow other people than yourself to request signatures. A shared private key! Anyone who has access to this nsec bunker could de-crypt any gift wrapped note sent to it. Relay-free read access control! There are lots of ways you could manage this access list, but I think a compelling one would be to create a NIP 51 list (public or private!) of group members and set up the nsec bunker to authenticate using that list. Boom, dynamic member lists. You could also create a NIP 51 list for admins, and pre-configure which event kinds each list is allowed to post using the group's nsec. So maybe members could only publish wrapped kind-1's, but admins could publish wrapped kind-0's (you can now zap a group!), kind 9's for moderation, updated member and moderator lists, normal kind 1's for public information about the group, etc. Gift wrap would support: - leak-free DMs - Fully private groups - Public-read groups (nsec bunker would allow for admin, but everyone would publish regular instead of wrapped events). - Organizations and other shared accounts, with role-based authorization (list/kind mappings)! Of course, no clients currently support this kind of thing, but support would not be hard to add, and it creates an entirely new set of affordances with two very simple applications of the core protocol. There are a few drawbacks I can think of, of course. Gift wrap makes it harder to search notes by tag. You could: - Leave all tags off (other than for DM recipient as in the proposal)- Selectively keep tags that aren't revealing of identity - Encrypt tag values. When a client wants to query a tag, it must encrypt the value using the same pubkey and include that in the filter. This, I think, is ok for the use case above. There are also a number of proposals in the works to fix NIP 04 DMs which are apparently broken from a cryptographic standpoint, so implementing this should probably wait until that stuff is sorted out. But it should be possible however that ends up materializing. So am I nuts? Or is this a galaxy brain solution? #[1]