Why I don’t like NIP-26 as a solution for key management
NIP-26 was created out of the needs of the Nostr integration at https://minds.com/. They wanted Minds users to be able to associate their “custodial” Nostr key with an external self-owned key. NIP-26 looked like a nice fit for the job, because it would allow supporting clients to associate the two identities statelessly (i.e. by just seeing one event published by Minds but with a delegation tag on it the client would be able to associate that with the self-owned external key without anything else1).
The big selling point of NIP-26 (to me) was that it was fully optional. Clients were free to not implement it and they would not suffer much. They would just see “bob@minds.com” published this, and “bob-self-owned” published that. They would probably know intuitively that these two were the same person, or not, but it wouldn’t be an issue. Both would still be identified as Bob and have a picture, a history and so on. Moreover, this wasn’t expected to happen a lot, it would be mostly for the small intersection of people that wanted to have their own keys and also happened to be using one of these “custodial Nostr” platforms like Minds.
At some point, though, NIP-26 started to be seen as the solution for key management on Nostr. The idea is that someone will generate a very safe key on a hardware device and guard it as their most precious treasure without it ever touching the internet, and use it just to sign delegation tags. Then use multiple of these delegation tags, one for each different Nostr app, and maybe rotate them every month or so, details are unclear.
This breaks the previous expectations I had for NIP-26 entirely, as now these keys become faceless entities that can’t be associated with anything except their “master” key (the one that is in cold storage). So in a world in which most Nostr users are using NIP-26 for everything, clients that do not implement NIP-26 become completely useless, as all they will see is a constant stream of random keys. They won’t be able to follow anyone or interact with anyone, as these keys will not identify any concrete person on their back, they will vanish all the time and new keys will show up and the world will be chaotic. So now every client must implement NIP-26 to become usable at all, it is not optional anymore.
You may argue that making NIP-26 a de facto mandatory NIP isn’t a bad thing and is worth the cost, but I think it breaks a lot of the simplicity of the protocol. It would probably be worth the cost if we knew NIP-26 was an actual complete solution, but it definitely is not, it is partial, and not the most elegant thing in the world. I think key management can be solved in multiple different ways that can all work together or not, but most importantly they can all remain optional.
More thoughts on these multiple ways can be found at Thoughts on Nostr key management.
If I am wrong about all this and we really come to the conclusion that we need a de facto mandatory key delegation method for Nostr, so be it – but in that case, considering that we will break backwards-compatibility anyway, I think there might be a better design than NIP-26, more optimized and easier to implement, I don’t know how exactly. But I really think we shouldn’t rush that.
- as opposed to other suggestions that would also work, but that would require dealing with multiple events – for example, the external user could publish a new replaceable event – or use
kind:0– to say they wanted to grandfather the Minds key into their umbrella, while the Minds key would also need to signal its acceptance of that. This also had the problem of requiring changes every time a new replaceable event of such kind was found. Although I am unsure now, at the time me and William agreed this was worse than NIP-26 with the delegation tag.