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

inkan

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

hex

3655d0d556aef68f05c5c871bf008de604d9a236d9defe3d9b92145d61fcd1f8

nevent

nevent1qqsrv4ws64t2aa50qhzusudlqzx7vpxe5gmdnhh78kdey9zav87dr7qprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsdrfs5nr6trhpxmu97e5dra85g7d2lkc2twu0gkke8058lnx5z5gc543vs4

Kind-1 (TextNote)

2026-06-01T08:51:26Z

↳ 回复 事件不存在

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.

原始 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"
}