Still trying to wrap my head around this.

How does device A differentiate this public key from a random other signed public key?

fiatjaf should do a master class on how to "explain it to me like I'm five-years-old" because this shit is fantastic.

Looks kinda gay to me

I do not fully understand how device A knows of Device B if each device has a different device key pair...

The way I understand it, these are internal key pairs for the device only. You’d be publishing their pubkeys with your normal nostr keys, so you’d find the other devices pub key cause it would be an event signed by you.

Device A knows about device B as soon as A sees another public encryption key in a Nostr event signed by the same user. So A and B do *not* have a different Nostr keypair. This is about syncing encrypted data on different devices for the same user I believe.

Because A only cares about new encryption keys signed by the same Nostr keys it has for the user. Same nsec, different devices.

Tales from the Crypt? 🥴 View quoted note →

I’m working on a prototype where I was nip44 encrypting the content directly (and not feeling comfortable about it), so this couldn’t have come at a better time 🙌

Right, I assumed that must be it. The title of the diagram, inferring that the diagram itself deals with identity keys, is probably why several people (incl. me) were confused?

Thanks. I assumed the devices had no shared secret. But if they already have the same nsec then all is good

Why didn't you feel comfortable about it? That's what everybody does. I do think people should migrate to this scheme I'm proposing for other reasons, but if you have different reasons I'd like to learn about them.

Signing and encrypting are different operations. The assumption here is that all devices can sign with the same key, but not encrypt.

I’m experimenting with building a simple wealth tracker, where you save encrypted records of your assets’ value to a local relay (indexedDB), and sync to a trusted relay. If your nsec is compromised, the ideal would be for the data to not be revealed without an extra key. If I’m not mistaken, the scheme you shared allows me to achieve this, since you’d need the device as well to decrypt. And I would add a passphrase, for when the device is compromised. Am I doing something stupid? 😅

If you're doing something stupid I don't know, but to me it looks pretty good. I think your concerns make sense and I'm happy that you gave me another use case for this NIP. I'll mention it in the proposal thread.

frostr pretty much works this way by default, since the group key is the "user key", and all device keys have proofs that they are members of the group

Better than nothing

> Signing and encrypting are different operations Perhaps in the diagram you could include the premise that the user is operating in the two clients with a signer that cannot encrypt (FROST bunker); this would make it easier to understand why such a structure becomes necessary. Even if there are probably other uses cases, like

@miljan on Primal Android cant zoom into this image to help read it, is it possibke to add that as feature request 🙏🙏

oh wait ... nvm! it does it now

This image was just thrown out of context for no reason, I didn't expect it to be shared so much. Anyone interested should read the NIP proposal I linked above (too late).

So Device B needs to sign content with the user level private key? So the only purpose of its own private key is to securely exchange the user level private key? I like to think of public keys as throw away session ids. Private keys should never leave the device where it has been generated but can rotate. Think of it like IP addresses that can change over time. My identity should just reference the current valid session IDs (in the same way that it references the current preferred relays). Any valid session can approve a new session (scan QR code of a new device npub). A session is actually not linked to a device but to a (device,app) pair. So that even a malicious app doesn’t contaminate and jeopardize your identity. Each session id (npub) could also have a tag, so that you can choose to follow me but only the content that I post from a given app. To avoid a malicious app to then automatically approve other npubs, we could have sane default rules. Eg. only your first session (high trust) can approve new sessions. Secondary sessions can only take over the primary role if the relay hasn’t heard from that primary key in more than x months.