nips
nips copied to clipboard
nostr-protocol
Add closed communities
This is an attempt at superseding https://github.com/nostr-protocol/nips/pull/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 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?
I find it curiois that members need admin's approval to leave a closed community.
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.
Just updated this PR to include a few more things, including some minor changes to NIP 72:
- A new
titletag on 34450s to support changing community names - A new
accesstag on 34450s to indicate whether the group has public or private components - Users may post a note to multiple communities by adding multiple
atags. - 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.
It would be great for privacy if every member of the group would always post with an alias pubkey (although the member list would include the real one). An alias they wouldn't change (atleast not very often).
Then an user can choose to reveal theirself (with a rumor kind for that) to other specific members manually or auto if to their follows (by looking at the member list of real pubkeys).
This would reduce the problem of some suspicious member handling the shared key to the public, cause although outsiders would be able to decrypt messages, they wouldn't know who is talking. Yet we keep a good UX by allowing friends to recognize each other.
I love this since this can be great for privacy even though someone do broadcast the note.
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.
