The main mistake is using OTS to enforce the order of operations, not realising (or in the case of DID:ION realising and accepting) that this opens the door for a late publishing attack, where key A generates a rotation to. key B' and timestap it, but not publish it, then later it creates a rotation to key B and publish that, then later publishes key B' disrupting everything.
That is possibly problematic in two scenarios;
1. An organisation trying to move control from one CEO to another, they can never be sure that the first CEO didn't create a hidden rotation that allows him to clawback control.
2. Honest mistakes where the rotation propagate or reach every one at the same time, so now two parts of the network are on two forks of key rotation.
But the worst is that it doesn't allow you to have key recovery, so basically you want to give some server a Recovery key that allows you to recover if you lost your PrimaryKey, but to do that you have to make sure that the RecoveryKey can't steal your identity, you want it to be forcefully published on a Blockchain so if it is trying to steal your identity, you have a window of time where you can challenge that rotation event with your PrimaryKey
In fact this safe recovery is the main reason PKIs need a Blockchain or an authority in the first place, see for example Farcaster IDs or Bluesky DID PLC directory.
That was the main disagreement, other disagreements are marginal, for example I believe that we shouldn't use Nostr events or signed JSON for these stuff instead we should have a good old Name Server and signed DNS packets because this is very much a DNS problem so it should embrace DNS schemas.
Finally, despite using a Blockchain, because it is only OTS and not force publishing, you don't get to enjoy an Ordinals feature, where all identities are ordered, which would allow you to give them very short numbers which would allow you to encode them as very short names and thus short URLs, for example rovodero-hopabesy.mns.alt, which is what I do in Mlkut Name System using Rootstock sidechain, you can see the resulting names here https://gist.githack.com/Nuhvi/8daa04620118a00d5d6bf40c3fbd9c6f/raw/mns-visualize.html
Nuh
npub1jv…s7yqz
2026-06-01 01:20:55 UTC
in reply to nevent1q…ng3d
Author Public Key
npub1jvxvaufrwtwj79s90n79fuxmm9pntk94rd8zwderdvqv4dcclnvs9s7yqzSeen on
wss://relay.primal.netPublished at
2026-06-01 01:20:55 UTCEvent JSON
{
"id": "815bc511efdc099885c051eeb01d76d2cb1c5ff9c96eb2cb210190caaf960873",
"pubkey": "930ccef12372dd2f16057cfc54f0dbd94335d8b51b4e2737236b00cab718fcd9",
"created_at": 1780276855,
"kind": 1,
"tags": [
[
"e",
"15fde76baeb9bac55815115d43bc4be5a67cfb611a78f718d0c599dc9b40b7e9",
"wss://relay.primal.net/",
"root",
"930ccef12372dd2f16057cfc54f0dbd94335d8b51b4e2737236b00cab718fcd9"
],
[
"e",
"e49d08f5165a1168336001227221cbcb104012b02fcecdcb760e8f3fe9c339ad",
"wss://relay.primal.net/",
"reply",
"d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23"
],
[
"p",
"d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23"
]
],
"content": "The main mistake is using OTS to enforce the order of operations, not realising (or in the case of DID:ION realising and accepting) that this opens the door for a late publishing attack, where key A generates a rotation to. key B' and timestap it, but not publish it, then later it creates a rotation to key B and publish that, then later publishes key B' disrupting everything.\n\nThat is possibly problematic in two scenarios;\n1. An organisation trying to move control from one CEO to another, they can never be sure that the first CEO didn't create a hidden rotation that allows him to clawback control.\n2. Honest mistakes where the rotation propagate or reach every one at the same time, so now two parts of the network are on two forks of key rotation.\n\nBut the worst is that it doesn't allow you to have key recovery, so basically you want to give some server a Recovery key that allows you to recover if you lost your PrimaryKey, but to do that you have to make sure that the RecoveryKey can't steal your identity, you want it to be forcefully published on a Blockchain so if it is trying to steal your identity, you have a window of time where you can challenge that rotation event with your PrimaryKey \n\nIn fact this safe recovery is the main reason PKIs need a Blockchain or an authority in the first place, see for example Farcaster IDs or Bluesky DID PLC directory.\n\nThat was the main disagreement, other disagreements are marginal, for example I believe that we shouldn't use Nostr events or signed JSON for these stuff instead we should have a good old Name Server and signed DNS packets because this is very much a DNS problem so it should embrace DNS schemas.\n\nFinally, despite using a Blockchain, because it is only OTS and not force publishing, you don't get to enjoy an Ordinals feature, where all identities are ordered, which would allow you to give them very short numbers which would allow you to encode them as very short names and thus short URLs, for example rovodero-hopabesy.mns.alt, which is what I do in Mlkut Name System using Rootstock sidechain, you can see the resulting names here https://gist.githack.com/Nuhvi/8daa04620118a00d5d6bf40c3fbd9c6f/raw/mns-visualize.html",
"sig": "15ad5e48de39529fdcbbb282d6d5066065c3e35b3527f9e8c752607ba26623d92a3620743e502d2f27868c7b2d0aff94c45c360da4121b0fac095962a087c18a"
}