Oddbean

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

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 🤌

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?

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?

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'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.

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.

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

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