M. Dilger on Nostr: NIP-26 is not deprecated. It hasn't been edited in 8 months (and that was just to ...
NIP-26 is not deprecated. It hasn't been edited in 8 months (and that was just to remove authors).
So why did I remove it from gossip?
All I was hearing from EVERY VOICE for months was that it was dead, minds never used it, nobody used it, that nobody wants to use it, and it was entirely a bad idea. Because I am very reticent to break things, I investigated usage first. I looked on all the big relays for ANY event with a deprecation tag. None. Could not find a single use of this NIP. And AFAIK no other client supports it. No relays ever seemed to support it. It was like this for OVER A YEAR before I decided to remove that clearly unused and complicated code that was not simple to maintain.
BUT ALSO I knew I could put it right back as soon as people started to actually use this NIP. And I will.
Just like Murphy's law would predict, after I removed it, everybody piled on me and complained. Just because of the idea, not because anything broke.
To be clear, I really do wish for a secure offline master key and online per-device subkeys. And having thought about it a lot, I think the right path is to do something like NIP-26 but with a single-letter tag, or to have a key schedule event where you publish your subkeys and their revocation status. The problem is that nobody can start using it effectively until everybody has it implemented... until then nobody is going to find and follow your new subkeys. So it's just as impossible to get there as the ipv4-to-ipv6 transition was. That is sad and unfortunate, but it is reality, and reality must be looked at square in the face.
If wishes were horses, beggars would ride.
Published at
2024-07-11 00:40:16Event JSON
{
"id": "f94f439605861cc1a8dfc243224a47ad754bb3f84c69d9955dd0015f1df0a63f",
"pubkey": "ee11a5dff40c19a555f41fe42b48f00e618c91225622ae37b6c2bb67b76c4e49",
"created_at": 1720651216,
"kind": 1,
"tags": [
[
"p",
"de7ecd1e2976a6adb2ffa5f4db81a7d812c8bb6698aa00dcf1e76adb55efd645"
],
[
"p",
"32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245"
],
[
"p",
"44dc1c2db9c3fbd7bee9257eceb52be3cf8c40baf7b63f46e56b58a131c74f0b"
],
[
"e",
"210e4f5b3b80a1fb555acdf9f6389f0adc2191adde1cd007ce89246bf44ce442",
"wss://nostrue.com/",
"root"
],
[
"e",
"1429b3d5cd878fc9d277cba14bd2d2684ae934781f97846277fc5018c592564e",
"wss://nostrue.com/",
"reply"
]
],
"content": "NIP-26 is not deprecated. It hasn't been edited in 8 months (and that was just to remove authors).\n\nSo why did I remove it from gossip?\n\nAll I was hearing from EVERY VOICE for months was that it was dead, minds never used it, nobody used it, that nobody wants to use it, and it was entirely a bad idea. Because I am very reticent to break things, I investigated usage first. I looked on all the big relays for ANY event with a deprecation tag. None. Could not find a single use of this NIP. And AFAIK no other client supports it. No relays ever seemed to support it. It was like this for OVER A YEAR before I decided to remove that clearly unused and complicated code that was not simple to maintain.\n\nBUT ALSO I knew I could put it right back as soon as people started to actually use this NIP. And I will.\n\nJust like Murphy's law would predict, after I removed it, everybody piled on me and complained. Just because of the idea, not because anything broke.\n\nTo be clear, I really do wish for a secure offline master key and online per-device subkeys. And having thought about it a lot, I think the right path is to do something like NIP-26 but with a single-letter tag, or to have a key schedule event where you publish your subkeys and their revocation status. The problem is that nobody can start using it effectively until everybody has it implemented... until then nobody is going to find and follow your new subkeys. So it's just as impossible to get there as the ipv4-to-ipv6 transition was. That is sad and unfortunate, but it is reality, and reality must be looked at square in the face.\n\nIf wishes were horses, beggars would ride.",
"sig": "c52b17298dcd2a1c120bcc7a5bc8e60bc3b1fb73f6b62e06b8c68c3719c900541832c482313cc31988b28ef685ae865b70127953ae4b234a4d6629be53366eee"
}