Skip to content
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

Groups based app with permissions and data encryption #1317

Open
bezysoftware opened this issue Jun 18, 2024 · 3 comments
Open

Groups based app with permissions and data encryption #1317

bezysoftware opened this issue Jun 18, 2024 · 3 comments

Comments

@bezysoftware
Copy link
Contributor

bezysoftware commented Jun 18, 2024

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:

  • Users can create groups with metadata (name, image, other app specific data)
  • Users should have permissions in those groups (admin / readonly / write / etc)
  • Only permissioned users should be able to read group metadata + content
  • Permissioned users can post notes / likes & other content (currently not covered by any NIP) to the group
  • There should be a mechanism for new users to join existing groups (invite link). E.g. user (admin) creates a group with an invite link, shares that link with a friend and that friend can then join the group (with some default permission).
  • It should be possible to invalidate / rotate this invite link so no more users can join
  • Group data should be encrypted (optional but very nice to have) - data sent to groups should be encrypted so that even the relay cannot read the content of events.
  • But importantly users joining the group later must be able to decode past events
  • Users can decode events on other devices

From what I found these are relevant:

  • NIP-29 (groups)
  • NIP-17 (encrypted DMs, but there is a mention of chat rooms)
  • By extension of NIP-17 also NIP-44 and NIP-59
  • NIP-104 (E2E encryption proposal which however specifies that groups are out of scope)

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
Copy link
Member

staab commented Jun 18, 2024

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
Copy link
Contributor Author

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
Copy link
Member

staab commented Jun 18, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants