thenostrworld (npub1nst…rg5l) elidy (npub1a7n…vfnu) #[3]quoting nevent1q…sxzfWhat should hackers BUIDL?
Just updated nostr.world with details on the thenostrworld (npub1nst…rg5l) Hackathon, including some Track project ideas.
https://nostr.world/hackathon/index.html
BUILDING PRIVATE GROUP CHATS on NOSTR — a MICROAPP proposal
1/ Why?
Because we don’t want to use other corporate junk + it needs to be permissionless + users need to control their data + open sources + no CEO … 5 things that you can't get elsewhere even from bahamas-located Tether-controlled Keet.
Because once we have this we have build freedom’s best friend (thus fiat government’s worst nightmare): permissionless ability for citizens to self organize in groups and in turn for groups to federate. It’s the path towards private islands and island nation states.
2/ Key ideas and considerations
a private group chat is a GROUP PRIVATEKEY and PUBKEY pair
if you belong to a private group then this is an extension of your identity, like another layer or branch. No reason it can’t be done with Nostr client-side, no need for relay specifics
today when you belong to a private group chat (e.g. whats’app) it is just a shared secret in the sense that you all can decypher the msgs. This is done with GROUP PRIVATEKEY. We can leave the admin thing on the side for now. What’app/Signal/Telegram: you can’t really prevent bad actors anyways from leaking stuff, so we are not going to try tackle that here, just focus on the building private groups
there is no reason it can’t be done with Nostr client-side, no need for relay specifics.
POSTING: today when you post to private group chat, it knows it came from you and displays accordingly. Achieving this with NOSTR: you encrypt your msg with your personal PRIVATKEY then embed it within a message to the group using GROUP PUBKEY. Basically it is a DM with a public post inside. That way only pple with knowledge of GROUP PRIVATEKEY can read and there is no ambiguity as to who is posting. just need to define the encapsulation specifics but there is no reason it can’t be done with Nostr client-side, no need for relay specifics. (Open Q: can you DM yourself with Nostr ? )
outside interference and inference: outsiders don’t see private DM. outsiders can spam the GROUP if they know the pubkey (which is possible since the GROUP should be able to broadcast to the outside world as a GROUP (a moral entity) ). But I guess there are ways to deal with that: on client side (block?) and on relay side (private relay ?)
GROUP LIFECYCLE: there are 2 ways to approach this:
the simplest way: there is no admin role, it is all organized (aka setup) out of band by individuals who DM each the GROUP key pair. Super simple and good enough for many use cases. Obvioulsy there is no GROUP level key pair rotation, so you can’t ban someone (once in) and once disbanded the group history is “as is” … stored on some relays (if backedup + keys not lost). Obviously there is no out of band “tracking” who is in the group: group members infered on the client side by reading msgs. There is no way to prevent a bad actor from leaking and no way to recover. A good culture/hygiene would be for groups to have a clear policy: such as finite lifetime (e.g. 1or 2 years, once expire up to the group to create new instance and possibly upload old messages), msg rentetion policy (e.g. expire after xx months)
the more complex way: there is a group ADMIN with a MASTER GROUP KEY PAIR seed and who derives then multiple CHILDREN GROUP KEY PAIR (for example meant to be used for a period of time) and does the group lifecycle management. we can imagine a variety of permissioned/permissionless method to distribute keys, and in return have key features such as: delete member, refresh group key pairs etc… open question: how does it look to outside world when group is posting and keys have changed (only post from MASTER PVTEKEY but then gated by admin ?)
Cheers, pv