👀 View quoted note →

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 View quoted note →

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?

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? View quoted note →

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 View quoted note →

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:

GitHub

Add closed communities by staab · Pull Request #875 · nostr-protocol/nips

This is an attempt at superseding #706 and incorporating existing NIPs for community definitions and member lists. The design is worse in many ways...

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 View quoted note →

Which NIP is used for these groups?

GitHub

Add closed communities by staab · Pull Request #875 · nostr-protocol/nips

This is an attempt at superseding #706 and incorporating existing NIPs for community definitions and member lists. The design is worse in many ways...

Feedback is welcome