Oddbean

Introducing Kind0.io A NIP-41 proof of concept. What is NIP-41? A simple way to migrate from a compromised key into a new key while signaling to your followers what happened. It works by whitelisting your next npub ahead of time and timestamping it to something that can order events chronologically (ie the Bitcoin blockchain) When a key is lost or compromised the new key can sign a migration event, timestamp it as well and then clients can choose to act on it. For more discussion on this, listen to @NVK 's recent Bitcoin.review where they go over the why and the tradeoffs. Here’s is a very rough video of a very rough tool to implement this whole flow. This is not the last word on key management; there is still a lot of work to be done, but this is a small step in the right direction that will allow us to migrate the existing nostr social graph to more cryptographically complex schemes for whoever wants to do that. https://cdn.satellite.earth/3f1bf208810669bd3a9eaa7a0b9c7ff2d75d1abc893a6b2db8463d6f4923d083.mp4

Pablo, Could this be used to whitelist a different npub but not in the context that the old npub is compromised? To clarify, I wish I could have my nsec generate at least one more npub (preferably unlimited npubs like a bitcoin private key can generate unlimited wallet addresses) so I could have a verifiable way to connect my NunyaBidness npub with a Bitcoin And . . . Podcast npub. Your system looks like it could emulate that verifiability but the context here seems to be that the first npub is compromised. Is this tool only to be used in cases of compromise or can it be used in a way for me to verifiably connect 2 npubs?

That use case is much simpler. To "verifiably connect 2 npubs" you should need to sign a note saying that you own the other npub and vice-versa. If you want that relationship to be done automatically and detectable by clients we can come up with something too, but what would be the use case? Another thing that can be done is to generate multiple pubkeys based on a single secret key by, for example, adding numbers to it, for example: pubkey(nsec+1) = npub+pubkey(1) pubkey(nsec+2) = npub+pubkey(2) and so on Such that if someone has npub and npub+pubkey(1) they can verify that they are indeed connected (or it could be any number, doesn't have to be 1, 2, as long as the verifier knows the number). I think we should have a NIP for this because it's a cool way to have multiple identities that are nonetheless tied together, but I'm still searching for a use case.

I like the idea of having a central, controlling nsec as a way to group particular npubs together simply because that is what I am used to having in a legacy system context. I can certainly function without it but it seems useful if I had say 3 different npubs that performed different functions. Maybe notes were written from those npubs by a person other than myself but she couldn't post the note because she doesn't control the nsec. Only I do which would give me the chance to "approve" or "disapprove" of any note because only I can execute the send. Expand this to an organization like a university and that's a shit ton of npubs (at least one from over 100 departments). The horror of this is that if I had multiple well known npubs and the nsec was compromised . . . well, you can fill in the blank. It is very likely that we don't really need this at all but my gut feeling tells me that I want this simply because having nsec/npub key pairs for multiple 'accounts' seems like a lot of management.

Could a slight variation in this theme be used to designate disposable child keys for private messaging? As illustration, I DM someone a child key w/ validation which opens a private message channel where they reply to that validated child key with a message and a new child key & validation of their own and we continue replying — each time designating/validating a new key for reply. As the messages are encrypted to the users disposable keys, no one need know that the child keys exist or that we have continued our conversation.

Nits: Container / form backgrounds should be lighter than the app background. It's just how the human eye perceives depth. Closer object should be lighter. Dark foregrounds are harder on the eyes. It seems like the "Next npub" container has no margin-left. Viewing on mobile. The container licks the left border of my screen. Feels like it should be centered. This tool is fucking awesome 🚀 Thank you Pablo!

It reminds me of a PGP revocation, but with a pointer to the next of kin. It's not quite the same, but has some similarities. It is interesting as long as all this is set up before there's any key compromise.

More importantly to the follower count of the new key is that if your follows are following the new key now. Another alternative would be to verify if the NIP-05 domain remained the same however has a new pubkey for the user. Is there a NIP to revoke a key? I haven't yet caught up completely yet with the latest developments.

Whoever publishes first has the upper hand; if you don’t have the first published event you’ll have to work more to convince your current graph that the newer event is the real one by communicating out of band

nostr:nevent1qqsphpf7jgffzvf5a46lp5l7vhxsqf8snv409w3tttafmnhztpp4usgpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtczyrafsj7hmweg9ur7zmn6apajdg48hxuskujx53rhrux0ttjcqx84yqcyqqqqqqgzy4ts4 And the discussion on Github... https://github.com/nostr-protocol/nips/pull/829