Agree. What is kind 1040?

Would be nice if we used seed phrases and HD wallets/keys so users could rotate effortlessly. Unfortunately, every single client would have to implement this though…

Also, never mind if you’re dealing with key loss… disregard… I was thinking about key rotation the other day in the event of a quantum computer coming around and we don’t update our key scheme for some reason…

The opentimestamps proof

GitHub

nips/03.md at master · nostr-protocol/nips

Nostr Implementation Possibilities. Contribute to nostr-protocol/nips development by creating an account on GitHub.

No, that does not work at all unfortunately.

Having implemented SSO before, I think that my proposal is more practical. How can anyone trust anything that a compromised key posts? What happens if the migration event is lost or not currently available? Why make everyone update their follow lists? It's better to separate identity from authorization, so that that hot new client never knew your identity nsec in the first place, and everyone still recognizes you as you, even if one of your app keys gets away.

GitHub

NIP-102: Subkey Attestation by ynniv · Pull Request #1450 · nostr-protocol/nips

This NIP defines a way to separate identity from authentication using hierarchical deterministic (HD) keys. This allows people to use one key pair ...

I get it, but any subkey proposal creates enormous burden on clients and relays and ensures nothing cool can ever be built again on Nostr. Also bunkers -- hosted frost multisig, self-hosted, running on your phone, running on trusted hosted hardware, running on a physical device in your home -- are the solution to not having to post your nsec everywhere.

I don't understand the complexity criticism. Clients make a random key when they're installed, then request a signed attestation from the identity key. When they sign things they also include this attestation. When a relay sees such an event, it validates the attestation (this can be done with no additional information) and then substitutes the identiy npub for the publishing npub in all indexes. When clients see a new event, they do the same validation and substitution. The identity npub is all that matters. Finally, if the identity ever publishes an event disavowing a specific attestation, relays and clients should treat this as a deletion request for all events created using that attestation. And that's basically it ... treat (locally verifiable) attestations as if they were the author, and delete events that were made by a disavowed client key. Separating identity from authorization is an important part of improving the security of systems, and doesn't need to be onerous

First of all this isn't backwards compatible (because indexes, relay message validation and other things have to be changed), so if you're going to break Nostr entirely then it's better to make a new protocol that also tries to address other suboptimal parts of Nostr, like @npub1acg6...p35c is doing with Mosaic. But then at the same time you lose all the (small, but significant) network effect we have here, which to me isn't worth doing. Second, you create the need for these "disavowing" events to be reliably published (which cannot ever be guaranteed in Nostr) and they become the central part of Nostr, and you can't have that work reliably without a centralized sequencer (i.e. either a blockchain or a trusted operator), see for just a brief example of one of the many half-broken issues that can happen (I'm not sure this specifically applies to your idea, but I'm sure we can think of many variants). Now even if by miracle these disavowing events become reliably distributed then there is still the problem that now all clients and all relays have to store them and then check all incoming events that come with a locally valid attestation to see if their pubkey has been previously disavowed, forever. (I just came up with these issues now, later I can revise my opinion to either add more or retract these.) The other solution is to go the NIP-26 way and treat each key as independent, soft-linking them with attestations. That is more elegant in my opinion, but in practice it breaks too, because of issues like those described in this comment by @Vitor Pamplona:

GitHub

Linked Keys for Multi-Device Nostr · Issue #1810 · nostr-protocol/nips

Right now, using Nostr across multiple devices is a challenge. Either you: Share your master key (risky, especially on a phone). Use separate keys ...

Maybe you'll want to see also View article → although I don't remember what I wrote there.

> First of all this isn't backwards compatible Sure it is. In some future where there is a crazy mix of support, people using this functionality have multiple npubs that are seen as the same to supporting clients, and just similar to non-supporting ones. People probably wouldn't want to constantly post from different keys during this period, but c'est la vie. They can put "subkey of @Identity" in one profile and "has subkeys" in their main one. Relays can do the same, but there are fewer relay implementations and adding support would be easier than with clients. > Second, you create the need for these "disavowing" events to be reliably published I mean, sure... same as "deletion" (better described as retraction) events. Put them in profiles if we're that concerned... before you fetch the profile they don't even have an identity anyway. > those signature checks also rely on server signing keys which can be expired and replaced I don't know what this means. Perhaps it isn't applicable to my proposal? My attestations are validated in the same manner as event signatures. > Now even if by miracle these disavowing events become reliably distributed then there is still the problem that now all clients and all relays have to store them and then check all incoming events that come with a locally valid attestation to see if their pubkey has been previously disavowed, forever. Which again is the same as NIP-09. If anyone in the world has a copy of an event "deleted" using NIP-09, then they can republish it as soon as the retraction event falls out of circulation. This is worse than my proposal because you're probably not going going to lose your nsec as frequently as you would delete a post. It's said that you should fix nostr by building things, and that works great when your fix looks like a new app, but I don't have the time right now to build my own improved nostr ecosystem just to fix this important but uncommon edge case. But are we really going to keep slamming our nsec into random new apps, or limiting ourselves to browser extension or remote signing? Assuming you haven't already lost it, your current key can continue to be your identity, and random new apps (that might only barely need continuity) can get subkeys. The best time to plant a tree was 20 years ago, but the second best is to plant it today

É muito bom ver que o #Nostr está em constante movimento 🤠 View quoted note → View quoted note → Será possível cobrar por um conteúdo em específico e até vender usando ZAP e Blossom. E também outras novidades interessantes.