You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
The text was updated successfully, but these errors were encountered:
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.
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?
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.
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.
The text was updated successfully, but these errors were encountered: