I think that by

inkan

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

hex

3c6577e583003ad43477222d67c12f5bcc43ede131740e5c69fb38af17991e31

nevent

nevent1qqsrcethukpsqwk5x3mjytt8cyh4hnzrahsnzaqwt35lkw90z7v3uvgprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsdrfs5nr6trhpxmu97e5dra85g7d2lkc2twu0gkke8058lnx5z5gcw2myus

Kind-1 (TextNote)

2026-06-09T16:19:31Z

↳ 回复 事件不存在

9e6171280bb937e561f7a5ce0483328c7870ddba344b6fbde29f3df3a398debe...

I think that by

"an identity attests them"

you mean that the identity signs something saying that events signed by the attested keys should be attributed to the identity, right? If so, this is similar to what Inkan calls a "delegation of signing authority."

And when you say that, when a key is lost, the identity key publishes a disavow, this is similar to what Inkan calls a "revocation of signing authority."

All of the above is, I think, fully implemented in Inkan.

Now the part I don't agree with conceptually is (6): "In the presence of a disavow, all events with that attestation are considered deleted."

That's not what should happen. Only events that are signed after the disavow should be no longer attributable to the identity. Events that were signed prior to the disavow (while the attestation / delegation was still in effect) should remain attributable to the identity.

So I think Inkan is in many ways similar to what you describe above, except for the modification to (6). I think Inkan's handling of this is conceptually more correct.

原始 JSON

{
  "kind": 1,
  "id": "3c6577e583003ad43477222d67c12f5bcc43ede131740e5c69fb38af17991e31",
  "pubkey": "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23",
  "created_at": 1781021971,
  "tags": [
    [
      "e",
      "f9901260bc194e772513aa63bc4c5e4696eaaad9168d08f4d547c18e46eae264",
      "wss://cyberspace.nostr1.com/",
      "root",
      "577de06dce160a0379163a4bb7b680be3e0a0e1c68de6e6ba8c01134b44064dd"
    ],
    [
      "e",
      "9e6171280bb937e561f7a5ce0483328c7870ddba344b6fbde29f3df3a398debe",
      "wss://relay.primal.net/",
      "reply",
      "576d23dc3db2056d208849462fee358cf9f0f3310a2c63cb6c267a4b9f5848f9"
    ],
    [
      "p",
      "577de06dce160a0379163a4bb7b680be3e0a0e1c68de6e6ba8c01134b44064dd"
    ],
    [
      "p",
      "32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245"
    ],
    [
      "p",
      "a9434ee165ed01b286becfc2771ef1705d3537d051b387288898cc00d5c885be"
    ],
    [
      "p",
      "036533caa872376946d4e4fdea4c1a0441eda38ca2d9d9417bb36006cbaabf58"
    ],
    [
      "p",
      "930ccef12372dd2f16057cfc54f0dbd94335d8b51b4e2737236b00cab718fcd9"
    ],
    [
      "p",
      "576d23dc3db2056d208849462fee358cf9f0f3310a2c63cb6c267a4b9f5848f9"
    ]
  ],
  "content": "I think that by\n\n\"an identity attests them\"\n\nyou mean that the identity signs something saying that events signed by the attested keys should be attributed to the identity, right? If so, this is similar to what Inkan calls a \"delegation of signing authority.\"\n\nAnd when you say that, when a key is lost, the identity key publishes a disavow, this is similar to what Inkan calls a \"revocation of signing authority.\"\n\nAll of the above is, I think, fully implemented in Inkan.\n\nNow the part I don't agree with conceptually is (6): \"In the presence of a disavow, all events with that attestation are considered deleted.\"\n\nThat's not what should happen. Only events that are signed *after* the disavow should be no longer attributable to the identity. Events that were signed *prior to* the disavow (while the attestation / delegation was still in effect) should remain attributable to the identity.\n\nSo I think Inkan is in many ways similar to what you describe above, except for the modification  to (6). I think Inkan's handling of this is conceptually more correct.",
  "sig": "4b77dcada3739407d55e0433d2c33c4bd42d013fd5a64082ab268d929f46138d93de3c5e5024b1817e9bf160dd6da57890e657c5b56906fcb4defb571a8b0aca"
}