nip	title	status	author	created	discussions-to
TBD	Linked Subkeys for Multi-Device Nostr Usage	Draft	Melvin Carvalho	26-02-2025	nostr-protocol/nips#1810

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:

Share their master key across devices (which is insecure).
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

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.
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/subkeys.md