Thread - Nostr Hypermedia

Dikaios1517 dikaios1517@nostrplebs.com 2 weeks ago

This sounds like it would be a nice feature to have, but only if virtually every client supports it. For instance, say I set this up for myself and start posting from a derived key. Any client that does not support this would treat me as a completely new user, right? So no one on such a client would be able to see my pfp or any other info that I had created with my root key on my derived key's profile page. And anyone who was following my root key's npub would not see any of my new key's posts in their feed unless they actively added my derived key's pubkey to their follow list, and even then, they would need to somehow remember that npub with no profile info is actually me, unless I republish a new kind 0 with the derived key. Any client or relay that uses web-of-trust but does not implement this would also exclude any derived key's pubkey from the WoT by default, since that new key won't have any follows or anyone following it. So, while it is not required for anyone to implement it, and Nostr will go on working as it had before for anyone who doesn't implement it, in practice it is next to useless unless virtually all clients implement it, since derived keys will be treated as completely new users by any client that doesn't, effectively wiping out their entire post history and social graph. Sure, all the previous notes will still exist, but that doesn't matter if the clients aren't associating them with the derived key. I guess that means a user probably wouldn't want to set this up until there is pretty widespread client adoption. And what is the idea for how users will safely store their root key? My assumption is that ideally we would all want to switch to a new root key, rather than use our existing nsec, since it has been used hot. So that would require us to start fresh regardless. Then what? We would need to get a device like a ColdCard to safely store our root key offline and generate our first derived key using that? I can see the Nostr guides now... "Welcome to Nostr! To get started, first go buy this $150 piece of hardware. You can also build your own for a fraction of that price. You can also get started completely free by simply generating a key pair, but this is not recommended since there is a greater danger of your key being compromised, and if you wanted to upgrade to a more secure means of using Nostr later, you would need to start a whole new identity anyway." Don't get me wrong, I think having a way to rotate keys and keep your root key offline is great, and I would probably do it myself if this method gained widespread client support. I am a bit more technical and familiar with cold storage already, though. I can't imagine this being the main way new users keep their keys safe, though. Maybe I am misunderstanding how this works, though, and all the above concerns are moot.

↑ Parent

Replies (2)

GHOST ghost@nostrplebs.com 2 weeks ago

You’re correct about one thing and misunderstanding another. Correct: If a user rotates before a client supports lineage, that client won’t associate the new epoch key with the root identity. Followers there would see it as a separate npub. That’s expected. The part you’re misunderstanding: Cold root identity is optional and backwards compatible. No one rotates until the clients they care about implement lineage. Nothing forces a migration. Nothing breaks for anyone who doesn’t use the feature yet. This is the same adoption pattern as every optional NIP feature. If a client doesn’t support zaps, zaps are invisible. If a client doesn’t support DMs, DMs don’t work. Same here. Rotation is an additive capability. The value doesn’t depend on universal adoption. Just like multisig, hardware wallets, Tor-only nodes, LNURL-auth, and NIP-46. Even if only power users or security focused clients adopt it, it still solves real problems: - key hygiene - blast-radius reduction - eliminating the hot key identity model Practical rollout is simple: 1. Users keep using their current hot nsec. 2. Clients begin adding support for the lineage tag. 3. Once a client supports it, users can optionally switch to an epoch key. 4. The root npub remains the identity anchor. The client maps the root to whichever epoch key is active. This is exactly how PGP subkeys, Monero subkeys, and minisign key hierarchies work. The identity anchor never changes. Only the operational key rotates. Additionally, You don’t need a new root key or any hardware. Your existing nsec becomes the root. Even if it was used hot, it’s fine because the moment you generate the first epoch key, the root goes offline permanently. No one needs to buy anything or start over unless they want to. Rotation simply gives users a safer operational model when they’re ready for it.

1 replies ↓

Dikaios1517 dikaios1517@nostrplebs.com 2 weeks ago

Except, I don't gave to just care about whether the client I prefer has implemented it. I also have to care about whether the clients those who follow me have implemented it. If they have not, then my posts on the derived key will not show up in their feed, since their client will treat my derived key as a completely separate identity that they are not following, right?

1 replies ↓