Hm, should clients add an nsec field during bunker setup? Not for you to put your real nsec into, but rather one that you know is allowed to post to your relay. Then if the client becomes adversarial the worst they can do is post spam to your relay, which they can probably already do once they have remote signer permissions. This is overbuilt but maybe there is a simpler solution inside. Maybe the bunker URL you paste initially should just include an nsec for the client to use?

Yeah I haven't used it much in the past couple weeks. I've been in more of a refactoring mode and have just been doing one-off prompts or using Cursor's plan mode for that. I would like to get back and try it on some more tightly scoped features though. I should circle back to Claude code at some point but viewing and accepting changes with the Cursor diff viewer is just so ingrained in my workflow now, I think I would miss it a lot.

I guess what I am dreaming of is not really NIP-87 exactly. It's more like NIP-29 plus encryption minus the assumption that the policy engine for the group is running at a particular DNS name. If you decouple the policy engine from the relay/DNS now you can innovate on that separately and create some really sweet trust structures, or not and just keep your group on a single relay.

It seems to me like a rogue relay owner in a NIP-29 group is just as disastrous as a rogue group admin NIP-87? And this isn't in NIP-87 but I don't see any reason you couldn't use FROSTR threshold signatures to publish events from the admin key. In this way a few admins could hold shards or you could even distribute a shard to every group member and have clients collaborate to approve membership changes or other policy changes?

Oh I never thought about this. Yeah you wouldn't be able to filter content by tag or author because everything is gift wrapped? Is that how this worked in Coracle groups ? It seems like spam wouldn't be too much of a problem though. Because all messages are giftwrapped with the shared key the relay can easily tell if a person is a valid member of a group or not by checking the pubkey and signature right? I suppose you would hit rate limits sooner with the shared key on a public relay, but I guess I'm assuming serious groups will have some kind of relationship with their main relays, paid or otherwise.

You wouldn't have to trust them not to accidentally leak messages to the wrong people but they would still need the encryption key in order to service membership changes right? I supposed you could use one encryption key for membership changes and another for content? 🤔

Fun milestone for Keydex today: I had my first successful restore of data. I was able to fire up several copies of the app and create a lockbox, break it into shares, distribute them to peers via Nostr, initiate recovery, approve the recovery request, and reassemble the data. There is still a ton of work to do but having the core flow working makes all the future changes feel small and incremental by comparison.

Keydex is going to be the first Nostr app I'm aware of that uses relays exclusively to relay data from one peer's device to another, not for long-term data storage. I'm going to use NIP-40 expiration tags on all events so that they only live on the relay for a few days, which makes Keydex closer to a peer-to-peer application that uses Nostr as the transport (and identity) layer.

oh interesting, I wonder if I've been hitting these rate limits and that's why I have so much trouble with signers. I also have my own relay but I only allow events from my own pubkey to be published there. 🤔 So I could point clients to my own relay for NIP-46 messages but there's no easy way to add every client key to my allowlist... I guess I am running `nak bunker` on the same machine as my relay. Maybe I could jerry-rig some communication between nak and my relay config? Sounds fragile though.