-
Notifications
You must be signed in to change notification settings - Fork 578
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add closed communities #875
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@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. |
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. |
e048963
to
c7387f0
Compare
166eafd
to
077fc5a
Compare
003065c
to
a220953
Compare
Just updated this PR to include a few more things, including some minor changes 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. |
I love this since this can be great for privacy even though someone do broadcast the note. |
@arthurfranca interesting idea, I'll play around with that. |
c3b9c25
to
ae455f8
Compare
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. |
Sure, just pushed an update |
|
||
## Key Sharing | ||
|
||
Keys are shared via a `kind 24` rumor sealed by the `admin` key, wrapped using an ephemeral key, and addressed to each group member individually, as well as to the admin's pubkey. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
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.