Here's another preview of private groups coming soon to Coracle — super excited to release this.
https://v.nostr.build/maAK.mp4


you are awesome

you are awesome


From: nostr:npub15f0lnlxujj05a8cr7emhsz9cszcjalaq0su6rymvw22zuth0h9fs7cqrdx


👀

nostr:nevent1qqsqs5fe4menkzaxqjyryvsc7de8ltsvh3m62xu542p6908mk78uyvqppamhxue69uhkummnw3ezumt0d5pzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezqvzqqqqqqyz9z760


i watched this video, this is incredible.  what do you think about deleting messages?  time-based deletion and/or deletion by moderators.  with that and what you have, we're skipping the moon and going straight to mars #groups


Time based is easy with an expiration tag, mods can delete either by implementing nip 72 moderation (I skipped that for now) or by simply not hosting messages


Private groups gonna be huge

nostr:nevent1qqsqs5fe4menkzaxqjyryvsc7de8ltsvh3m62xu542p6908mk78uyvqpp4mhxue69uhkummn9ekx7mqzyztuwzjyxe4x2dwpgken87tna2rdlhpd02va5cvvgrrywpddnr3jyqcyqqqqqqgst6shm


Timed deletion (post expiration) as an option for the group would give affordance for some level of “post compromise” security, yes?  #skipthemoon


I’m so on #teamhodlbod !!

But I do see a major UX challenge ahead in handling key rotations. Asking all members to (I’m not even sure…) confirm some dialogue every time a key is rotated? That’s not gonna work.

Do I have this right? Any thoughts?


encrypted groups demo rocks!!

encrypted groups demo rocks!!


well, if you want to support deleting, the best i've come up with is a specially crafted 1984 with the event id only, when the relay sees this from a moderator, it just deletes..  im a fan of deleting, not all info should last forever.  if you want that, break out the papyrus 🤌


chi ha bisogno del web2.0 o 3.0, quando hai il protocollo #Sticazzi.0?

nostr:nevent1qqsqs5fe4menkzaxqjyryvsc7de8ltsvh3m62xu542p6908mk78uyvqpz3mhxue69uhkummnw3ezummcw3ezuer9wcpzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezqvzqqqqqqy9vp3uz


They just have to receive the key and start using it, it's completely handled by the client


I at least think key shares should expire, which would achieve this


But this looks to need acknowledgment from the user of accepting the new key? That’s gonna be problematic… if rotating keys is an essential (possibly daily or more) aspect of group management. Is this right?


Nope, only the admin has to care


The client is automatically picking up the new messages with the keys right?


The easiest way to create private groups using Nostr
nostr:nevent1qqsqs5fe4menkzaxqjyryvsc7de8ltsvh3m62xu542p6908mk78uyvqpzpmhxue69uhkummnw3ezuamfdejsygyhcu9ygdn2v56uz3dnx0uh865xmlwz675emfsccsxxguz6mx8rygpsgqqqqqqsqztspn


Correct


This is exciting! Love seeing the other tabs (calendar, market, ...) in there.

Also, group members can make certain post public and others private within the same group? 🤔


Are you using the simple mechanism that I used with Indra - the messages include a return address, in this case a pubkey to use in a reply? It just seems so obvious to do this, and clients and relays store all the messages, it's really a client side thing to implement.

The state is on the relay this way, no need to complicate the client, it just looks for the events tied to the pubkey, finds messages, decrypts them, finds other keys to use to find DMs, requests them, etc.

I don't see the exact reason for the need of any other complications other than anonymization, which I think is best kept out of the protocol, because anonymous relaying is very easy to abuse (see recent Tor hidden service spam problem).

With a scheme like this, only the relays are privileged to know who is asking for what pubkeys. This is the thing that Tor defends against (or other proxy/VPN). It does not expose chains of messages to casual inspection by querying for DMs for a pubkey.

It would also be quite simple to have relays require auth on the pubkey to fetch DMs, also.

I don't follow your work that closely but I always appreciate it and use your client religiously. Nobody else makes it as well, although there's a few abandoned pieces in the interface you maybe should remove until they get actual use (soviet memes are dead lol).


I think the chicken and egg problem is solved by a consistent scheme to mutate from your nsec to a chain of new keys to use in replies. It could be as smiple as an identifier used alongside the new pubkey that informs the client how to mutate the nsec to make a new nsec to get a new npub that lets it find the reply.


I'm not quite sure what you're describing here, the summary is that I use the inbox model to send shared keys to members. Those invites have relay hints to help them find the group. Everything is wrapped using the nip 59 draft. You can read the spec here: https://github.com/nostr-protocol/nips/pull/875

Thanks for liking coracle! The new release removes several old features which I hope to revisit later.


In theory, currently I don't have a affordance for that. I think it's most useful for group admins, e.g. a discussion post for a publicly released podcast episode vs for a member q&a.


oh, this is not related to DMs and encryption schemes.


Something like this
nostr:nevent1qqsqs5fe4menkzaxqjyryvsc7de8ltsvh3m62xu542p6908mk78uyvqpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsygyhcu9ygdn2v56uz3dnx0uh865xmlwz675emfsccsxxguz6mx8rygpsgqqqqqqsv9zrv7


Which NIP is used for these groups?


https://github.com/nostr-protocol/nips/pull/875

Feedback is welcome