I'm not sure what exactly you mean by "fork" or "join," but inkan's declarations do "join" in the sense that the delegation state at any given time is a function of the total set of past declarations.
But the question whether declarations "fork" or "join" seems in any event orthogonal to the question whether inkan needs consensus. Inkan needs consensus on the relative order of nostr events and revocations. If Bitcoin uses consensus for validating the DAG, that's fine. Inkan just uses the types of consensus it actually needs.
I'm not sure about the "humans" point. Inkan can absolutely issue identities to agents. Neither Bitcoin nor inkan can check that its users are humans.
Regarding the "notary," inkan uses a notary, namely OTS, for the timestamping of nostr events. But a notary is not sufficient for inkan, since a notary can't prove *absence* (e.g "no revocation existed before time T ...").
As for the leak's and revocation's being inherently race that inkan can't eliminate, that's of course true. But a stolen signer can damage only the window between key compromise and revocation. You can also take preventative steps by periodically rotating your signing key preemptively.
npub16x…56z6l
2026-09-18 07:00:10 UTC
in reply to nevent1q…6cvv
Author Public Key
npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6lPublished at
2026-09-18 07:00:10 UTCEvent JSON
{
"id": "abd2dc2a0bc5badb250fb962a7da000b727be9ad517b7df573b6862f17b392b3",
"pubkey": "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23",
"created_at": 1789714810,
"kind": 1,
"tags": [
[
"e",
"193f82b9436456aa42b17056bb81d19066c4ba92915e15d97ed639caea854c60",
"wss://pipe.imwald.eu/",
"root",
"dd664d5e4016433a8cd69f005ae1480804351789b59de5af06276de65633d319"
],
[
"e",
"17e09315034940366c9900b223e81c52fb6cf12d0b03250ec4393e618251113c",
"wss://pipe.imwald.eu/",
"reply",
"5538e28a66eb88360f15f8fa95646bdd2daa2999aacfe4faacf43d0c0540b281"
],
[
"p",
"dd664d5e4016433a8cd69f005ae1480804351789b59de5af06276de65633d319"
],
[
"p",
"5538e28a66eb88360f15f8fa95646bdd2daa2999aacfe4faacf43d0c0540b281"
]
],
"content": "I'm not sure what exactly you mean by \"fork\" or \"join,\" but inkan's declarations do \"join\" in the sense that the delegation state at any given time is a function of the total set of past declarations.\n\nBut the question whether declarations \"fork\" or \"join\" seems in any event orthogonal to the question whether inkan needs consensus. Inkan needs consensus on the relative order of nostr events and revocations. If Bitcoin uses consensus for validating the DAG, that's fine. Inkan just uses the types of consensus it actually needs.\n\nI'm not sure about the \"humans\" point. Inkan can absolutely issue identities to agents. Neither Bitcoin nor inkan can check that its users are humans.\n\nRegarding the \"notary,\" inkan uses a notary, namely OTS, for the timestamping of nostr events. But a notary is not sufficient for inkan, since a notary can't prove *absence* (e.g \"no revocation existed before time T ...\").\n\nAs for the leak's and revocation's being inherently race that inkan can't eliminate, that's of course true. But a stolen signer can damage only the window between key compromise and revocation. You can also take preventative steps by periodically rotating your signing key preemptively.",
"sig": "7fba9a3b3fd65327cf8cbfecea3a4c408e1301e5ab44395eecbaef6abf8ca8a63d6bb8e17370a6a9491b63727f7175808ba104bc12ceead1da7166c645980870"
}