Oddbean new post about login | logout Recently, NIP-26 has been back in the limelight in some discussions, because indeed a system of key rotation, and temporary delegation of event signing, is crucial in a mass adoption path. Reflecting a little on NIP-26's critical points, I came up with a simple modification that seems interesting at first sight, although it would still require a mandatory flag: https://github.com/nostr-protocol/nips/pull/1363/files What do you think? I ask this first of all to the NIP-26 haters @fiatjaf and @PABLOF7z, to @Magister Michael Dilger M.Sc. who recently added back NIP-26 to Gossip, to @jb55, @bu5hm4nn, @Enki and anyone else who seems interested in the issue. Feel free to tag others for visibility.
I'm definitely not an expert in this stuff, but I'm gonna give it a read. nostr:nevent1qqstmq4u9758jf0qphm8qy99kkgv0xgyef9z6y8lrdf68wfc4nmd80qpz9mhxue69uhkummnw3ezuamfdejj7q3q0000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsxpqqqqqqz8zwyys
I disagree this stuff is "crucial". This approach does look better at a first glance, though.
I agree that delegation to other generic entities is not crucial, but a way to rotate/invalidate keys seems essential, isn't? What I worry is that when onboarding will increase, malware and scammers will follow: and a compromised key entails the loss of considerable value, and can also bring damage if the attacker uses it for malicious purposes. Such a situation would immediately drive the user away and create bad publicity for Nostr. The only mitigating alternative I see, without touching the protocol, is for NIP-46 to impose itself and become the recognised standard, and *all* clients to use it by eliminating login via nsec.
I don't know why everybody thinks rotating keys is essential. That seems to be a meme that came from nowhere and suddenly everybody thinks this is to be expected. The truth is that it is not possible to do the perfect delegation scheme without a centralized entity controlling the keys, like Bluesky has on their centralized server, or using a blockchain. And if we're going to have something that is a good-enough solution, Pablo's NIP-41 proposal is pretty good for the disastrous cases of lost keys. Also having this delegation scheme by itself doesn't imply key rotation is solved, I think these are different problems. I think we'll end up having good NIP-46 support and that will fix most things.
Rotation is essential to avoid loosing one's digital identity, that's a fundamental part of what Nostr offers. Yes, delegation in the NIP-26 form doesn't fully solve key rotation because there isn't an immediate way to revoke a key. For who is speculating what NIP-41 is, read here: https://github.com/pablof7z/nips/blob/nip41/41.md
Again, it's impossible to do rotation without centralization. If that is really essential then let's move to Bluesky.
please expand
I want my master key offline, and per-device signing keys online. That isn't centralization. And I cannot do that with NIP-46 where the bunker has to be online. The only solutions to provide this that I can conceive of are major breaking changes. My keypair has leaked all over the place and it is only by the grace of god that people haven't noticed and posted as me. But as of today there is almost zilch I can do about it.
You're talking about delegation, I'm talking about rotation. But your stuff also can't be done reliably because there is no way to revoke your per-device signing keys without a centralized server telling everybody that a key was revoked.
Why can't I publish a key schedule event to my outbox relays, created and signed offline by my master key, that says that some device key is now revoked?
Are your outbox relays defined by your per-device key or by your master key?
I see that it would have to be the master key. *grumble grumble hrumph*
Noob here. What about NIP41 requires centralization? The announcement of the revocation? If so, could we remove the requirement for announcement? Could NIP41 suggest generating something like 12000 keys (1 per month for 100 years) instead of the proposed 256 in the NIP? Then everyone rotates on the first of the month if they want to? Too much processing on onboarding or recovery? Or too much of a pain for each client to download the list of 1200 keys for each of their contacts? If that’s too much then rotate yearly Puts the burden on clients, not relays (except load) or Nostr code. Remain backwards compatible for all existing keys. Clients could choose to care or not about rotated out keys. Clients could say “outdated contact, use caution” etc.
I suspect single key rotation and per-device keys require really different approaches. The latter is more similar to delegation. With a single key that rotates, the last used one is the authority and could sign the outbox relays, as hypothised here: nostr:nevent1qqsz9huty7l7yvzw8n85vsd3phrj9fkpnun8qqdrjc5lyzhltjrr7sgpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsygrmmmmmugka3evlgcqwq3922wsul966nhrayl04svauwldhsjjcq5psgqqqqqqsrgs8g8
The message defining those could be signed on a hardware device though, keeping the master key offline
Yes. I haven't changed email providers or DNS providers in years. Once nostr settles down, changing relays will be a rare enough thing that requiring the master key to do it doesn't seem overly onerous to me.
Why? NIP-41 doesn't do that? Let's hypothesize another solution. Take a hierarchical deterministic keys structure, and publish the public master key. When a new key is used to sign something (it should be a special event for better visibility), clients are instructed to ignore all events from the previous keys. Wait, but this doesn't block a malicious actor from signing and broadcasting events with a date in the *past*. These are the pain points. It's it that you are talking about? To fix this, we should validate all past events with the new key, or let the new key invalidate/delete malicious events, and both hypotheses seem crazy, even if maybe the latter is feasible as an extreme solution. Of course, we cannot block the broadcasting of old events, otherwise we would kill the uncensorable mechanism. So we end up considering time-stamping events using the blockchain, which is also a huge pain and a heavy dependency. I can see where centralization could arise.
not centralisation, CONSISTENCY > In a distributed system, achieving consistency falls upon the consistency model and consistency (enforcing) mechanisms. Consistency models determine which data and operations are visible to a user or process, and which kind of read and write operations are supported on them. consistency means that everywhere you ask, you get the same answer nostr's design has weak consistency not ZERO CONSISTENCY please, i beg you, go actually refresh your memory about the nature of distributed systems problems, especially the CAP theorem
eventual consistency
Yes, you're right.
people in nostr think consistency is centralisation and shitcoiners think that 100 authorities is decentralised seriously, go back and read some DST pls pls plss
Consistent is not centralization, but it requires centralization. Are you happier now?
no, because you are wrong consistency is a product of a protocol that gives some degree of priority to checking that all replicas are the same or in the case of eventual consistency, where the propagation strategy inevitably reaches all participants bitcoin has probabalistic consistency, which is a variant of eventual consistency, in that you can say with some amount of confidence that the chances of convergence failure after 6 blocks is basically nearest thing to impossible but not precisely impossible is bitcoin centralised? i believe it's the most decentralised distributed system ever designed nostr simply does not have a consensus, so it's not really a distributed system, the definition of a distributed system is that it acts like a von neumann machine, with limitations of time to consistency or resistance to partitioning or whatever it was intentional that nostr not have a consensus, because that frees up the space to experiment with strategies, and we have like blastr, we have nip-65 outbox model, and there's dozens of other ways that consistency can be created and actually once you can start to say that the public part of the nostr relay network is starting to have some kind of consistency, it will be so heteregenous that no single attack will ever be able to break it i mean, not that i particularly care to exercise this angle on it but using a pBFT based blockchain database effectively adds a form of consistency, that is the central point in our pitches to get the grants to do the work i don't think it's the best solution but it does in fact increase the consistency of a group of relays sharing a common distributed database, i would say that it is centralising, to a strong degree, and what primal does with cache relays is even more centralising
Rotating and invalidating keys is essential. Mistakes will be made.
The first mistake is thinking this is essential.
Yesterday i tried primal on android, i copied my nsec from amber, 10 minutes later i pasted the clipboard contents in the search box of you tube.... 😭...... Mistakes happens. It's essential
nostr:nevent1qqstmq4u9758jf0qphm8qy99kkgv0xgyef9z6y8lrdf68wfc4nmd80qpzpmhxue69uhkummnw3ezumt0d5hsygrmmmmmugka3evlgcqwq3922wsul966nhrayl04svauwldhsjjcq5psgqqqqqqstlmslw
A node (client or relay) that doesn't upgrade will see these as broken invalid events. The signature will not match the pubkey field. In the current NIP-26, at least the events are valid and people can see them, they just don't have a clear association between the signer and the delegator. So I think this is a worse experience for nodes that don't upgrade. If every node upgraded it would be fine, but I'm not sure it would be better. Both ways of doing it require code to update either it's signature verification or it's method of associating an author, neither being a harder ask IMHO. BTW the delegation proof doesn't have to be replicated in every event if we wanted to save space, it could be a separate event.
I also was worried to the idea to spread invalid events; for this reason the NIP is flagged as mandatory. You are certainly more qualified than I am to express the complexity of an upgrade, but the extended signature check seems to me easier, and it also keeps the events with the same human-readable structure related to the `pubkey`. > BTW the delegation proof doesn't have to be replicated in every event if we wanted to save space, it could be a separate event. A delegation proof is ~280B, is it worth the risk of invalidating an event because the proof was not founded? Or adding an async pattern and wait more time to fetch it?
I think having the delegation proof immediately accessible may be very important. But the mandatoryness or the invalidness of all events by non-supporting clients may be too much of a barrier, such that I think it might be better to try all the other alternatives first.
Account Delegation is a layer 2 problem: NIP-46, remote signers, signing bots, etc. Nostr doesn't need to change anything to have great delegation schemes. But I saw that you are using delegation to also solve key rotation. That's a mistake. If you want to solve key rotation solve rotation, not delegation.
I'm just reasoning on an already existent NIP that has low support, trying to improve it, and yes I'm interested more in key rotation, because I think it's more urgent. I agree that to solve this specific problem would be better a dedicated solution, and probably there are many. For example I thought about hierarchical deterministic wallets, exposing the master public key and use an event to signal the height of the valid key. Btw, delegation with expiry is actually key rotation. They are two problems with clear common points. But a clear limit of NIP-26 in this respect is that it not allow for immediate revocation.
Yes, it feels like delegation and key rotation intersect and a solution for one could solve the other. But the intersection breaks down when reality is applied. It's the same in DIDs. The rotation that is baked into DIDs fails to provide the type of delegation use cases want. In my mind, these two things just look similar, but they are vastly different. Mixing them into the same solution is a disservice to both.