Subnostr

So you don't have to download a bazillion giftwraps from a spammer before learning it was all spam, for example, or to do what Vitor said above.

jb55 1y ago

so would the outer receiverPubkey be the key you share with the trusted relay and friends, while the inner receiverPubkey is your root pubkey?

for the dm management thing to work you would have to give this wrap-decoding nsec to your relay that you run yourself?

Reply to this note

Please Login to reply.

Discussion

fiatjaf 1y ago

Hmm, yeah, that sounds right, my point above was wrong because I actually do not want to involve the user's main nsec in any encryption operation whatsoever, so I guess we would need two independent nsecs for this to work, one for the giftwrap and the other for the encrypted content.

But my bigger point is that I believe we could make it work easily with existing NIP-17 clients by just making them use these alternate nsecs when encrypting instead of the target's main nsec. And then people could opt to just use their main nsec by default or to signal that they are now accepting DMs to these other nsecs.

(I didn't think this too much so I'm probably missing something again.)

jb55 1y ago

seems fine but I think it leads to device keys because I doubt users will want to manually manage another nsec

fiatjaf 1y ago

Yes, I'm talking in the context of having device keys and then these secrets are shared seamlessly across devices.