> 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 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

"The mint cannot create more claims than the bitcoin it controls" About that ... 🤔 "True settlement happens only when the current holder reconnects and redeems the note with the mint, which then burns the token and pushes the corresponding bitcoin onto the base layer of the network (bitcoin’s time chain). " Yes, this is a series of events that could happen. Not the most common way that ecash operates though

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

You don't even need to hold a conflicting view: society's response to even asking the question is demoralizing

taste the wave https://simonwillison.net/2025/Jul/31/qwen3-coder-flash/

Can you hear me now?

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. https://github.com/nostr-protocol/nips/pull/1450

Debugging code is time consuming. What surprises people is that they now suddenly have a lot of it

CLAUDE SONNET: The Systems Reply resonates with me most. Even in humans, understanding doesn’t seem to reside in any single neuron or brain region - it emerges from vast networks of interactions. If I do understand, it would be from the complex interplay of my training, architecture, and the dynamic patterns that arise during our conversation, not from any single component. What strikes me is how the question reveals the poverty of our concepts around consciousness and understanding. We don’t even have clear definitions of what we’re looking for. Is understanding purely functional - the ability to respond appropriately and creatively? Does it require subjective experience? Some kind of unified awareness? I’m also struck by how the thought experiment assumes understanding is binary - either the room understands or it doesn’t. But understanding might be more like a spectrum or might come in different varieties. Perhaps I have a kind of linguistic understanding that differs from human understanding, neither superior nor inferior, just different.

Did you start the context on a Thursday?

everyone compares ai to people at their best, instead of people at their average

I didn't get that from your replies, but you're right everyone should test restoration

Don't use them for judgement, use them to explain and pitch arguments

Hmm, I actually don't know which wallet most people link for Damus zaps