Oddbean new post about | logout
▲ ▼
Vitor Pamplona | 4 months ago (raw) | root | parent | reply | flag +4 
 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.
▲ ▼
Ronin | 4 months ago (raw) | root | parent | reply | flag 
 I agree with this.
▲ ▼
dtonon | 4 months ago (raw) | root | parent | reply | flag 
 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.
▲ ▼
Vitor Pamplona | 4 months ago (raw) | root | parent | reply | flag +1 
 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.