nostr-protocol / nips

Nostr Implementation Possibilities
2.34k stars 564 forks source link

Groups based app with permissions and data encryption #1317

Open bezysoftware opened 3 months ago

bezysoftware commented 3 months ago

Hi, I only recently discovered nostr so my knowledge of individual NIPs is fairly limited, which is why I'm looking for input for my idea of the following groups based app (I already have an existing regular / non-nostr app, but I am evaluating what my options are to move it to nostr). Requirements:

From what I found these are relevant:

NIP-29 is most relevant to the whole group permissioning flow - groups would be private by default with admins able to approve join requests from users. The joining link would basically contain a group_id that the requester would send the join request to.

What I'm totally unsure of is the encryption of data - I am correctly looking at NIP-17? Is that something that can be combined with NIP-29 (I haven't read it too thoroughly)? The data to be stored is not critical (no missiles launch codes) so the limitations mentioned in NIP-44 are fine (just need to be communicated to the user).

I suppose since anyone can run their own relay it's acceptable to have the data unencrypted and readable by the relay, as long as it's not readable by someone outside of the group, but in the long run it would be great to move towards encryption so even the relays cannot read it.

Any thoughts / pointers / directions to proper forums appreciated.

staab commented 3 months ago

You're describing #875, which is implemented in coracle.social, including pretty much everything you mentioned, including encryption and invite links. Key rotation is mutually exclusive with users being able to read old content however, so that's one thing you'd have to decide. I've also created triflector, which is a group-oriented relay built in Go (although I think a re-write is in order). Coracle also supports white-labeling, which allows you to create stand-alone group- or relay-oriented instances for your particular use case. I'd be happy to accept PRs to either project if that's something you want to contribute to.

bezysoftware commented 3 months ago

Thanks, at first glance that does look like everything I'm looking for. So effectively if NIP-87 is merged it would supercede NIP-29? Are there some more side discussions taking place around your proposal (other than the PR)? Or in other words what are the chances of it being merged?

staab commented 3 months ago

87 and 29 are very different approaches to the problem. They might even be solving different problems, since 29 supports "forking" a group, while 87 gives the group admin complete control. The former would be better for something like sub-reddits, while 87 is better for cohesive community groups. Getting it merged depends on someone else implementing it, and so far there has been a lot more interest in 29 than in 87.