Subnostr

Nice, cool project! I'm very interested in putting public/private groups into coracle, so you might be able to take a massive shortcut by forking my work (or just using it as a customer, let me know if you'd like to do that, I'm thinking about doing hosted white-labeling as a business). If you're interested in private groups, take a look at my draft NIP at https://github.com/nostr-protocol/nips/pull/706 — it'll likely change as I continue to work on it. DM me if any of that sounds interesting.

ManiMe 2y ago

Thanks. Indeed, I recognized right away that private (encrypted) groups chats will be a pivotal feature to develop for this project. I also have seen a few implementations, and none yet in the official NIPs. Like this one

https://oi5l5umbjx.feishu.cn/docx/TW7Ndb6Imoj3n7x08MTcleqanad

From denostr… which is a client and a relay seemingly built around this feature. But nobody uses denostr, and the repos are baren of commits.

So yea…

What’s I the state on encrypted groups, and how do I get on the RIGHT ground floor?

Reply to this note

Please Login to reply.

Discussion

hodlbod 2y ago

The current status is here: https://github.com/nostr-protocol/nips/issues/717

(draft) NIP 24 is good for small-scale groups. My draft nip 87 (or 112) could work for larger groups, but lots of detail still needs to be hammered out.

ManiMe 2y ago

Thank you for sharing.

Can’t help but thinking a better solution exists that doesn’t require two group types. Fundamentally, this is a bad idea for end user experience. IMHO

If we all agree that shared keys are less good for any group, and that client “work load” is the only problem to solve for the nip-24 “many gifts” version to scale to large groups … then why not just solve THAT problem?

So, i slept on it, fully expecting a novel (and possibly noob) solution to just “pop” into my dreams. Don’t judge, it actually happened that way.

Good morning.

If “need for moderation” is an identifier of “large groups” then let the moderators unwrap a “gift bag” and distribute the workload of wrapping gifts.

- In a group were “moderators review every post” (recommended setting for larger groups), new messages are delivered wrapped in a “gift bag” only to moderators.

- “Gift bag” could be a type of “gift wrap”, with a list of recipients at the seal or rumor level.

- each moderator (not having “away”status) receives a “gift bag” with a subset of group member pub keys in the recipient list.

- moderators are charged with opening the messages promptly (and possibly marking as either “naughty” or “nice” )

- when a gift bag is opened, the client gets to work gift wrapping the message for each group recipient in the list.

- when the last “gift bag” is opened for a given message, the entire collection of gift wrapped messages are delivered to the rest of the group.

That’s the idea so far.

Useful or useless?

hodlbod 2y ago

This is one model, but not the only one. It would definitely work if a requirement imposed by the group admin was that members would only ever see messages that have passed moderation. But that's inherited from the legacy centralized model, I think a preferred model would be for moderation to be an annotation on top of data users already have access to, and users could choose which moderator to listen to (or even choose their own moderators, not assigned by the admin).

At any rate, the design above doesn't decrease the amount of work necessary to make nip 24 work, it only shifts it to the moderators.