Linked Keys for Multi-Device Nostr

[melvincarvalho]

Right now, using Nostr across multiple devices is a challenge. Either you:

• Share your master key (risky, especially on a phone).
• Use separate keys (but then they don’t link).

I want to save something on my desktop, see it on my laptop, edit on my phone—but without giving my phone the master key.

Each device should have its own key, but they should be linked, so apps know they belong to the same user.

This seems like an obvious problem that still isn’t solved. Let’s fix it.

[melvincarvalho]

First attempt at a solution: (copied here for convenience) ... maybe the basis of a new NIP?

https://gist.github.com/melvincarvalho/0eeba92ad49bd7f8907694751ec20cbd

Linked Subkeys for Multi-Device Nostr Usage

Abstract

This NIP introduces a method for using multiple device keys in Nostr while maintaining a unified identity. Instead of sharing a single private key across devices, each device has its own subkey that is cryptographically linked to a master key. This enables seamless multi-device usage without compromising security.

Motivation

Nostr currently has no built-in multi-device support. Users must either:

1. Share their master key across devices (which is insecure).
2. Use separate keys per device (which breaks identity consistency).

This proposal aims to:

• Allow each device to have its own key.
• Ensure subkeys are linked to the master key.
• Make subkeys easily discoverable but revocable.
• Avoid major protocol changes while keeping things simple and efficient.

Specification

1. Master Key (npub-master)

The master key is the root identity. It is never shared with devices and is used only for:

• Signing delegation events.
• Managing linked subkeys.

2. Subkeys (npub-device1, npub-device2, etc.)

Each device generates its own unique subkey and links it to the master.

3. Subkey Declaration in kind:0 (Profile)

Each subkey posts its own profile event (kind:0), referencing the master key.

📄 Example: Subkey’s kind:0 Profile

{
  "kind": 0,
  "pubkey": "npub-subkey1",
  "content": "{\"name\": \"Alice's Phone\", \"parent\": \"npub-master\"}",
  "tags": [],
  "sig": "SIGNATURE_FROM_SUBKEY1"
}

4. Master Key Declares Authorized Subkeys

The master key optionally lists authorized subkeys in its own profile (kind:0).

📄 Example: Master’s kind:0 Profile

{
  "kind": 0,
  "pubkey": "npub-master",
  "content": "{\"name\": \"Alice\", \"about\": \"Nostr user\", \"subkeys\": [\"npub-subkey1\", \"npub-subkey2\"]}",
  "tags": [],
  "sig": "SIGNATURE_FROM_MASTER"
}

5. Optional Delegation for Extra Security

For added security, subkeys can also be explicitly delegated by the master key using NIP-26 (kind:22242).

📄 Example: Delegation Event

{
  "kind": 22242,
  "pubkey": "npub-master",
  "tags": [
    ["p", "npub-subkey1"],
    ["d", "delegation"],
    ["expiration", "1712345678"]
  ],
  "content": "Delegated signing authority",
  "sig": "SIGNATURE_FROM_MASTER"
}

Client Implementation

How Clients Verify a Subkey

1. When a message is signed by npub-subkey1, the client:

   • Fetches its kind:0 profile.
   • Checks "parent": "npub-master".
   • Fetches npub-master’s profile and confirms it lists npub-subkey1.

2. If both conditions are met, treat npub-subkey1 as part of the master identity.

How Clients Handle Revocation

• If a subkey is removed from the master’s profile, it is no longer trusted.
• A master key can also sign a revocation event (kind:22242 with "revoke" tag).

Security Considerations

• Master Key Safety – The master key is never stored on insecure devices.
• Loss Recovery – If a device is lost, it can be revoked without affecting other devices.
• Delegation Expiry – Clients should respect expiration timestamps in delegation events.
• Privacy Considerations – Subkeys could be encrypted in profiles for added security.

Backward Compatibility

This approach does not break existing Nostr clients. Clients that do not support subkeys will simply treat each key as a separate identity.

Open Questions

• Should the "parent" field be encrypted for privacy?
• Should delegation via NIP-26 be mandatory or optional?
• Should we define a specific event kind for subkey linking instead of using kind:0?

Conclusion

This NIP provides a simple, flexible way to support secure multi-device identities in Nostr. It requires minimal changes while improving usability and security.

🔑 Let’s get this implemented! 🚀

[melvincarvalho]

I wrote a blog post explaining one use case, namely GPG, which already uses subkeys. But nostr could be better because relays are better than keyservers:

https://dev.to/melvincarvalho/could-nostr-subkeys-replace-gpg-a-simple-powerful-alternative-for-the-modern-web-aa0

[vitorpamplona]

I implemented subkeys or key-link strategies multiple times. I am unconvinced they are beneficial to Nostr. The implementation complexity for relays and clients easily 10xes:

1. Instead of just one follow list, now users have to follow all master keys and all subkeys of each key. This easily creates follow lists or subscription filters with 3000 keys, which in turn are far too big to be sent to almost any relay these days.
2. The Outbox model, relay hint procedures freak out because each sub-key can have its own inbox and outbox relays.
3. You have to p-tag all subkeys to make sure notifications work on clients that don't support this.
4. All encryptions must be run for each key in the set. So, to send a DM, you will have to send multiple DMs, one for each key. The subkeys replying must also include a copy of each of the other subkeys (basically every chat is a group chat).
5. Mute lists, (and all lists, bookmarks, draft events, settings, app data, etc) will be per key since there is no way for a subkey to update the encryption of the master key's list without that nsec.
6. Relay auth will be per sub key. So, relays must also change to include sub-keys in their authorization stack.

Each NIP will have its own little changes to account for subkeys. For instance, on Zap Polls, now the tallying must remove subkeys to make sure only one person is voting.

But maybe somebody can invent a way to do this without breaking the extreme simplicity of Nostr.

[alltheseas]

Recently there was a FROSTR prototype announcement and release.

https://njump.me/nevent1qqs9vnnt0fmr3sqxdsewuz6wfz48vsajdvnaqrg9u8llsn36mmf2x7spp4mhxue69uhkummn9ekx7mqpz4mhxue69uhhxet5dqhxummnw3erztnrdakszyrhwden5te0dehhxarj9emkjmn9qyvhwumn8ghj7urewfsk66ty9enxjct5dfskvtnrdaksasge8n

How might FROSTR fit, if at all, with the above problem statement?

[mikedilger]

First, you are ignoring nostr connect. Multiple devices can use the same key without having the nsec by communicating with a nostr connect bunker.

Second, I like this scheme except:

• its optional usage of NIP-26
• both keys MUST prove each other or I could become anybody I wanted to become

[melvincarvalho]

First, you are ignoring nostr connect. Multiple devices can use the same key without having the nsec by communicating with a nostr connect bunker.

If you mean the NIP-46, I made a comparison comparison chart, I’ll admit—it’s framed in favor of subkeys, but I tried to fairly lay out the trade-offs. Open to adjusting it if there’s something I missed!

Second, I like this scheme except:

Thanks!

its optional usage of NIP-26

That makes sense—I also felt it was the weakest part, but included it for completeness. If removing it simplifies things, I’m happy to do that.

both keys MUST prove each other or I could become anybody I wanted to become

Agreed! Two-way links are actually part of the spec already:

• keyA declares itself as a subkey of keyB
• keyB acknowledges keyA in return

If not, I’ll fix. Next step for me is to do an implementation and show it works.

I believe Safebox is interested in implementing it too.

I get that this could be a heavy lift for bigger clients right now, so my plan is to build it, test it, and show that it works. Then other clients can figure out if they think it would be useful.

[melvincarvalho]

Recently there was a FROSTR prototype announcement and release.

https://njump.me/nevent1qqs9vnnt0fmr3sqxdsewuz6wfz48vsajdvnaqrg9u8llsn36mmf2x7spp4mhxue69uhkummn9ekx7mqpz4mhxue69uhhxet5dqhxummnw3erztnrdakszyrhwden5te0dehhxarj9emkjmn9qyvhwumn8ghj7urewfsk66ty9enxjct5dfskvtnrdaksasge8n

How might FROSTR fit, if at all, with the above problem statement?

Been v impressed with frostr so far, but I'm still wrapping my head around it. I'm a taproot person so really love to see this work happening. My initial thought is that we are looking at complementary solutions, but I need to think this through a bit more. Very much open to collaboration!

[vitorpamplona]

I think FROST requires a remote signer in the same way NIP-46 does... No?

So, if that is a key restriction of the use case here, then it's no good.

[mikedilger]

In the masterkey/subkey scheme I envisioned for nostr-next, certain documents could only be created by (and should only be recognized by) the master key. Things like relay lists and metadata. Yes, it makes changing your relays more of a PITA, but a rogue subkey changing your relays is too much of a security risk IMHO.

But here we are saying the subkeys each have their own metadata, and maybe each their own relay lists. That might get complicated. Something to brainstorm on.

Also, the masterkey should publish revocation information on subkeys, and I think a revocation date is important. If a key was stolen in July, or is just no longer used, maybe you still trust events signed in June.

[mikedilger]

For clients that don't support this, they will see the profile and relays of the subkey. So we have to keep such things and they might get out of sync from master, but whatever. I think also that one of your devices could be using a subkey even if it doesn't support this NIP. Basically, support is optional. Without it, there are multiple melvincarvalho accounts, with it they are bound together. Is this right?

[1l0]

related? #1709

[mikedilger]

I've done a simple version here. I think it should be simple. #1837

Note that for encrypting data to a person we need a different additional scheme like what @fiatjaf proposed recently, which I take as a first-step that has to roll out before the masterkey-subkey thing does.