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 nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 and nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft, to nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c who recently added back NIP-26 to Gossip, to nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s, nostr:npub1hlq93jdtkfg29a8s7fqzzzh82q3pkc20rxucwt4geh6e56wk3y2qxdz5wg, nostr:npub1gnwpctdec0aa00hfy4lvadftu08ccs9677mr73h9ddv2zvw8fu9smmerrq 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.


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


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.


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 agree with this.


Rotating and invalidating keys is essential. Mistakes will be made.


The first mistake is thinking this is essential.


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.


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


I'd argue that the first mistake was when you created the protocol without this already solved .


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


This can be solved, or at least mitigated, using the ncryptsec. More client should support it.


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.


Again, it's impossible to do rotation without centralization. If that is really essential then let's move to Bluesky.


please expand


In real world , people lose health , wealth , name and fame  -  if they didn't care for it  ! why didgital systems be any different ?  In fact , this should be selling point of nostr :

Lose your keys - lose your ID !


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.


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.


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


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


Nah, eventual is more optimistic, there is no common mechanism. Eventual means it has a propagation strategy. Nope. That's left up to the relay operators and clients.


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?


consistency*


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


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.


I haven't changed email providers in years too, in fact I never changed, because it's impossible!