Thanks, this is helpful. It brings out an important misunder...

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l
hex
3655d0d556aef68f05c5c871bf008de604d9a236d9defe3d9b92145d61fcd1f8nevent
nevent1qqsrv4ws64t2aa50qhzusudlqzx7vpxe5gmdnhh78kdey9zav87dr7qprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsdrfs5nr6trhpxmu97e5dra85g7d2lkc2twu0gkke8058lnx5z5gc543vs4Kind-1 (TextNote)
↳ Reply to Event not found
815bc511efdc099885c051eeb01d76d2cb1c5ff9c96eb2cb210190caaf960873...
Thanks, this is helpful. It brings out an important misunderstanding about Inkan that I should try to clear up.
Inkan is not using OTS to enforce the order of operations. Inkan is using OTS to provide each Nostr event (e.g. notes, likes, reposts, etc.) with an objective timestamp. OTS is not used to enforce the order of anything.
Inkan uses Ethereum (not OTS) to record the order of declarations of delegation and revocation of signing authority. In Inkan, there is no such thing as "two forks of a key rotation." There is no ambiguity as to whether, at any time, key A delegates signing authority to key B, or not. Inkan is not vulnerable to the "late publishing" attack that you describe -- happy to bet on that with anyone.
Also, with Inkan, you do not give a recovery key to anyone, let alone upload a recovery key to some server or record it on a blockchain. You create the master key that represents your identity on your own airgapped system and then always keep the key in cold storage, say on a USB drive. The master key never has to touch an internet-connected machine.
As for signed JSON, I think this is actually a good thing to build on. Digital signatures + OTS timestamps closely track the familiar features of real-life wet ink signatures + notarization. This fact can be used to make the resulting system transparent and intelligible to the user.
Raw JSON
{
"kind": 1,
"id": "3655d0d556aef68f05c5c871bf008de604d9a236d9defe3d9b92145d61fcd1f8",
"pubkey": "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23",
"created_at": 1780303886,
"tags": [
[
"e",
"15fde76baeb9bac55815115d43bc4be5a67cfb611a78f718d0c599dc9b40b7e9",
"wss://relay.primal.net/",
"root",
"930ccef12372dd2f16057cfc54f0dbd94335d8b51b4e2737236b00cab718fcd9"
],
[
"e",
"815bc511efdc099885c051eeb01d76d2cb1c5ff9c96eb2cb210190caaf960873",
"wss://relay.primal.net/",
"reply",
"930ccef12372dd2f16057cfc54f0dbd94335d8b51b4e2737236b00cab718fcd9"
],
[
"p",
"930ccef12372dd2f16057cfc54f0dbd94335d8b51b4e2737236b00cab718fcd9"
]
],
"content": "Thanks, this is helpful. It brings out an important misunderstanding about Inkan that I should try to clear up.\n\nInkan is *not* using OTS to enforce the order of operations. Inkan is using OTS to provide each Nostr event (e.g. notes, likes, reposts, etc.) with an objective timestamp. OTS is *not* used to enforce the order of anything. \n\nInkan uses Ethereum (not OTS) to record the order of declarations of delegation and revocation of signing authority. In Inkan, there is no such thing as \"two forks of a key rotation.\" There is no ambiguity as to whether, at any time, key A delegates signing authority to key B, or not. Inkan is not vulnerable to the \"late publishing\" attack that you describe -- happy to bet on that with anyone.\n\nAlso, with Inkan, you do *not* give a recovery key to anyone, let alone upload a recovery key to some server or record it on a blockchain. You create the master key that represents your identity on your own airgapped system and then always keep the key in cold storage, say on a USB drive. The master key never has to touch an internet-connected machine.\n\nAs for signed JSON, I think this is actually a good thing to build on. Digital signatures + OTS timestamps closely track the familiar features of real-life wet ink signatures + notarization. This fact can be used to make the resulting system transparent and intelligible to the user.",
"sig": "c9e65b2d3c8d770a81ce1e3d40b12e7f80cd6798c2e951b8000ffb8731948eac79e0706638013a9b38a099a068d157f583f1262574c9351293c774cc23edd1d1"
}