Nostr notes by

It seems like I should run this against my codebase.

2026-08-21T04:02:01Z

In reply to nevent1q…gp3d
_________________________

It seems like I should run this against my codebase.

A draft NIP for Inkan 👇 #nevent1q…uztd

2026-08-20T10:51:11Z

A draft NIP for Inkan 👇

quoting
nevent1q…uztd
NIP-XX

Cold-Storage Identities for Nostr

draft optional

This NIP specifies online identities whose private key can be created in cold storage and stay there permanently. The key never has to touch an internet-connected device, and does not have to be kept close at hand. The identity can nonetheless be used easily for everyday online authentication, such as posting, replying, messaging, or signing in to services.

▌ 1. How it works

The identity-securing key never signs Nostr events itself. It delegates signing authority to delegatee keys, which handle the everyday signing on its behalf. If a delegatee key is lost or stolen, it is replaced, and the identity is untouched.

▌ 2. Delegations between keys

Delegations are time-indexed two-place relations. Between any two key pairs, at any moment, the first either delegates signing authority to the second or it does not. When it does, the second key is authorized to sign on the first's behalf. When it does not, the second has no such authority.

Delegations are either direct or indirect. A direct delegation arises when one key has expressly declared that it delegates signing authority to another. An indirect delegation arises because the relation is transitively closed: if X delegates to Y and Y delegates to Z, then X indirectly delegates to Z. This is what lets an identity be built as a chain (master → intermediate → signer), so that events signed by the bottom key are attributed all the way up to the master, while the master, having signed the top link once, retires to cold storage.

▌ 3. How a direct delegation is created

A direct delegation from key pair X to key pair Y is created when both key pairs sign a Declaration of Delegation of Signing Authority, by which X declares that it delegates signing authority to Y and Y declares that it accepts. The signed declaration is then recorded on-chain (the reference implementation uses Ethereum). The delegation begins at the time of the block in which the declaration was recorded, and remains in effect until it is revoked.

One special case: this holds only if neither X nor Y has previously permanently invalidated itself (§5). If either has, no delegation is created, even though the declaration sits on-chain.

As part of the declaration, X and Y also specify whether X can revoke the delegation unilaterally or whether Y's consent is required. The default is unilateral revocation by X, and it is the right default for most users: if Y's key is ever lost, X can still revoke it alone. Were Y's consent required, a lost Y could never be revoked, because Y would no longer be available to sign.

▌ 4. How a direct delegation is terminated

A direct delegation from X to Y is terminated when X signs a Declaration of Revocation of Signing Authority and records it on-chain, with Y's signature too if the original delegation required it. The delegation terminates at the time of the block in which the revocation was recorded. Everything Y signed while the delegation was in effect stays attributed to X; nothing it signs afterward does. A stolen signer therefore damages only the window between key compromise and revocation, and that window is the user's to close.

When a delegation and a revocation between the same X and Y land in the same block, the revocation is by convention treated as occurring first and the delegation thereafter. The convention is a tiebreaker for cases that block timestamps cannot order.

▌ 5. Permanent key invalidation

The third declaration is the Declaration of Permanent Invalidation of a Key Pair, signed by a key pair against itself, declaring that from then on it can no longer participate in any direct delegation, as delegator or delegatee. Once recorded on-chain, it takes effect at the time of its block. From that point, all existing direct delegations involving the key are terminated, and no new one involving it can come into existence, even if a declaration naming it is later recorded.

Its main use is invalidating a compromised master key. Such a key has no delegator above it, so ordinary revocation is unavailable; permanent invalidation lets its owner withdraw it from the system entirely.

▌ 6. Delegation timelines

A client can read the three kinds of declaration from the chain and, for any pubkey and any past moment up to the present, compute the direct delegations that pubkey was involved in at that moment. The indirect ones follow by transitive closure. So for any pubkey a client can compile a complete timeline of every direct and indirect delegation it has ever been involved in, and trace each back to the declaration that established it. Because the rules are fixed and the data is public, every client computes the same timeline, and no server has to be trusted to report it.

▌ 7. Bitcoin timestamping of events

Attribution needs an objective, auditable rule for when the signing of each event is deemed to have occurred. A self-declared created_at proves nothing on its own.

Events are anchored to Bitcoin using OpenTimestamps (OTS). An OTS proof for an event establishes that the event and its signature existed by the time of a specific Bitcoin block. An event's created_at is then treated as its objective signing time when a proof shows the event and its signature existed shortly after that time. The length of the "shortly after" window is configurable; the reference implementation defaults to four hours. Events without such a proof are treated as if they carried no valid signature at all: they are not displayed, and are attributed to no one.

A proof over the event id alone would show only that the event's contents existed by the attested block, not that anyone had yet signed them. Binding the signature into the proof as well shows that the signature itself existed by then, which is what an objective signing time requires. These proofs are published as kind 31045 events (§10).

▌ 8. Attribution of events

We now know, for any past time T and any two keys X and Y, whether X delegated (directly or indirectly) to Y at T; and for any event Y signed with both a valid signature and a valid OTS anchor, we have an objective signing time. Together these give a well-defined attribution rule:

An event E is attributed to a key X if and only if some key Y validly signed E at a time T and, as of T, X delegated signing authority to Y.

So a text note signed by a delegatee Y during a valid delegation period from X appears on X's timeline and is displayed there under X's profile, as if posted by X, even though X's own key never signed it.

▌ 9. Two profiles, one identity

You log in with your signer key and sign events with it, exactly as in any other Nostr client. Those events appear on the signer's own profile, and in addition on the profile of each of its delegators, up to your top-level identity.

You set the signer's profile by publishing a kind-0 event as usual. Separately, a signer can also set a profile for each of its current delegators, so that a top-level identity can present a face to the world without signing any event itself. This delegator-profile mechanism is kind 31065 (§10).

Your identity's profile is what you present to the world. Others should follow and interact with the identity, not with the signer beneath it. The signer is ephemeral and expected to be replaced; the identity is permanent, and is the thing followers should attach to.

▌ 10. Event kinds

This NIP defines two addressable event kinds (kinds 30000 to 39999 in NIP-01, where the latest event for a given (pubkey, kind, d-tag) replaces any earlier one).

Kind | Name | d tag | Signed by
31045 | Bitcoin timestamp | id of the referenced event | any party
31065 | Attributed profile | the delegator's pubkey | a delegatee

▌ 10.1 Kind 31045: Bitcoin timestamp

A 31045 event carries an OpenTimestamps proof for another event (§7). It is addressable by the referenced event's id, so a consumer finds the proof for an event E by querying kind 31045 with d = [E.id], whoever published it. Any valid proof for E is as good as any other, because the proof rests on Bitcoin and not on its publisher.

31045 event tags, marked (yes) if required, (no) if not:

d (yes): Id of the referenced event. The addressable key.
s (yes): Signature of the referenced event. With d, binds the proof to a signed event, not just an id.
p (no): Author pubkey of the referenced event.
b (no): Bitcoin block height of the attestation, or not_yet_available while pending.
t (no): Bitcoin block time (unix seconds), or not_yet_available while pending.
c (no): created_at of the referenced event, when known.
alt (no): NIP-31 summary, e.g. Complete Bitcoin Timestamp.

content is the base64-encoded OpenTimestamps (.ots) proof. Its leaf must commit to sha256(referenced_id || referenced_signature), the concatenation of the referenced event's 32-byte id and 64-byte signature. A consumer should verify the proof against its own view of the Bitcoin chain rather than rely on a relay having accepted it.

Only d and s, together with a verifiable content proof, are required to verify a timestamp. Every single-letter tag (d, p, s, b, t, c) is relay-indexed, so it can also serve as a query key, for example finding proofs by referenced author (p) or by anchoring block (b). b and t additionally duplicate what the proof itself attests; alt is not indexed and serves only as a NIP-31 display label.

{
"kind": 31045,
"tags": [
["d", ""],
["p", ""],
["s", ""],
["b", ""],
["t", ""],
["alt", "Complete Bitcoin Timestamp"],
["c", ""]
],
"content": ""
}

▌ 10.2 Kind 31065: Attributed profile

A 31065 event is a profile for one key, published by another: how an identity that never signs anything nonetheless presents a face to the world (§9). Its d tag is the delegator's pubkey, the identity the profile describes, while the event is signed by a delegatee authorized to sign for it. The defining property is that event.pubkey, the signer, is not the subject d. A consumer must confirm, against the delegation timeline of §6, that the signer was a current delegatee of the subject before honoring the profile; one signed by a non-delegatee is ignored.

31065 event tags, marked (yes) if required:

d (yes): The subject: the delegator's pubkey.
alt (yes): The exact string Attributed profile.

content is a JSON object carrying the subject's presentation. Its kind-0-style fields (name, display_name, about, picture, banner, website, nip05, lud16) mean what they mean in NIP-01 and NIP-05. It may also carry the subject's follow list, mute list, and a map giving relay lists for the members of the identity's delegation network (the keys tied to it by delegation), so a client can present and route for the identity without a further fetch.

{
"kind": 31065,
"pubkey": "",
"tags": [
["d", ""],
["alt", "Attributed profile"]
],
"content": "{\"name\":\"…\",\"display_name\":\"…\",\"about\":\"…\",\"website\":\"…\",\"nip05\":\"…\",\"picture\":\"…\",\"relay_lists_by_pubkey\":{\"\":{\"readWriteRelays\":[[\"r\",\"\",\"\"]],\"favoriteRelays\":[\"\"],\"relaySets\":[{\"id\":\"…\",\"name\":\"…\",\"relayUrls\":[\"\"]}]}},\"publicly_muted_pubkey_hex_ids\":[\"\"],\"current_snapshot_of_dir_indir_followed_pubkey\":[[\"p\",\"\"]]}"
}

Because 31065 is addressable, the current profile for an identity is simply the latest one whose d is that identity, signed by a key that is currently its delegatee. When the signer is rotated, the new signer republishes, and the identity's face carries across the change unbroken.

▌ 11. Reference implementation

Inkan (https://www.inkan.cc) implements this specification as a working Nostr client and a cooperating relay at wss://relay.inkan.cc. Delegation, revocation, and permanent invalidation are recorded by an Ethereum contract deployed at 0x385C0A272b1f44687cb360557b25827bD7CdB7eb, which is the normative reference for the exact on-chain declaration encoding. A separate, network-disconnected "Management Utility" generates keys and signs declarations on an air-gapped machine, so a master key can be created and used to bootstrap an identity without ever touching a networked host.

Huh, it looks like NostrHub isn't actually surfacing the ...

2026-08-21T01:56:04Z

In reply to nevent1q…cshn
_________________________

Huh, it looks like NostrHub isn't actually surfacing the draft NIP or the link to Inkan that I published there. That would make that site unsuitable for discussing NIPs.

Maybe I should republish the NIP here as a long-form note, with markdown for better formatting ...

Thanks, that might work. I'll give it a try.

2026-08-19T16:30:28Z

In reply to nevent1q…fqx6
_________________________

Thanks, that might work. I'll give it a try.

NIP-XX Cold-Storage Identities for Nostr draft optional This NIP ...

2026-08-20T10:46:19Z

In reply to nevent1q…fqx6
_________________________

NIP-XX

Cold-Storage Identities for Nostr

draft optional

This NIP specifies online identities whose private key can be created in cold storage and stay there permanently. The key never has to touch an internet-connected device, and does not have to be kept close at hand. The identity can nonetheless be used easily for everyday online authentication, such as posting, replying, messaging, or signing in to services.

▌ 1. How it works

The identity-securing key never signs Nostr events itself. It delegates signing authority to delegatee keys, which handle the everyday signing on its behalf. If a delegatee key is lost or stolen, it is replaced, and the identity is untouched.

▌ 2. Delegations between keys

Delegations are time-indexed two-place relations. Between any two key pairs, at any moment, the first either delegates signing authority to the second or it does not. When it does, the second key is authorized to sign on the first's behalf. When it does not, the second has no such authority.

Delegations are either direct or indirect. A direct delegation arises when one key has expressly declared that it delegates signing authority to another. An indirect delegation arises because the relation is transitively closed: if X delegates to Y and Y delegates to Z, then X indirectly delegates to Z. This is what lets an identity be built as a chain (master → intermediate → signer), so that events signed by the bottom key are attributed all the way up to the master, while the master, having signed the top link once, retires to cold storage.

▌ 3. How a direct delegation is created

A direct delegation from key pair X to key pair Y is created when both key pairs sign a Declaration of Delegation of Signing Authority, by which X declares that it delegates signing authority to Y and Y declares that it accepts. The signed declaration is then recorded on-chain (the reference implementation uses Ethereum). The delegation begins at the time of the block in which the declaration was recorded, and remains in effect until it is revoked.

One special case: this holds only if neither X nor Y has previously permanently invalidated itself (§5). If either has, no delegation is created, even though the declaration sits on-chain.

As part of the declaration, X and Y also specify whether X can revoke the delegation unilaterally or whether Y's consent is required. The default is unilateral revocation by X, and it is the right default for most users: if Y's key is ever lost, X can still revoke it alone. Were Y's consent required, a lost Y could never be revoked, because Y would no longer be available to sign.

▌ 4. How a direct delegation is terminated

A direct delegation from X to Y is terminated when X signs a Declaration of Revocation of Signing Authority and records it on-chain, with Y's signature too if the original delegation required it. The delegation terminates at the time of the block in which the revocation was recorded. Everything Y signed while the delegation was in effect stays attributed to X; nothing it signs afterward does. A stolen signer therefore damages only the window between key compromise and revocation, and that window is the user's to close.

When a delegation and a revocation between the same X and Y land in the same block, the revocation is by convention treated as occurring first and the delegation thereafter. The convention is a tiebreaker for cases that block timestamps cannot order.

▌ 5. Permanent key invalidation

The third declaration is the Declaration of Permanent Invalidation of a Key Pair, signed by a key pair against itself, declaring that from then on it can no longer participate in any direct delegation, as delegator or delegatee. Once recorded on-chain, it takes effect at the time of its block. From that point, all existing direct delegations involving the key are terminated, and no new one involving it can come into existence, even if a declaration naming it is later recorded.

Its main use is invalidating a compromised master key. Such a key has no delegator above it, so ordinary revocation is unavailable; permanent invalidation lets its owner withdraw it from the system entirely.

▌ 6. Delegation timelines

A client can read the three kinds of declaration from the chain and, for any pubkey and any past moment up to the present, compute the direct delegations that pubkey was involved in at that moment. The indirect ones follow by transitive closure. So for any pubkey a client can compile a complete timeline of every direct and indirect delegation it has ever been involved in, and trace each back to the declaration that established it. Because the rules are fixed and the data is public, every client computes the same timeline, and no server has to be trusted to report it.

▌ 7. Bitcoin timestamping of events

Attribution needs an objective, auditable rule for when the signing of each event is deemed to have occurred. A self-declared created_at proves nothing on its own.

Events are anchored to Bitcoin using OpenTimestamps (OTS). An OTS proof for an event establishes that the event and its signature existed by the time of a specific Bitcoin block. An event's created_at is then treated as its objective signing time when a proof shows the event and its signature existed shortly after that time. The length of the "shortly after" window is configurable; the reference implementation defaults to four hours. Events without such a proof are treated as if they carried no valid signature at all: they are not displayed, and are attributed to no one.

A proof over the event id alone would show only that the event's contents existed by the attested block, not that anyone had yet signed them. Binding the signature into the proof as well shows that the signature itself existed by then, which is what an objective signing time requires. These proofs are published as kind 31045 events (§10).

▌ 8. Attribution of events

We now know, for any past time T and any two keys X and Y, whether X delegated (directly or indirectly) to Y at T; and for any event Y signed with both a valid signature and a valid OTS anchor, we have an objective signing time. Together these give a well-defined attribution rule:

An event E is attributed to a key X if and only if some key Y validly signed E at a time T and, as of T, X delegated signing authority to Y.

So a text note signed by a delegatee Y during a valid delegation period from X appears on X's timeline and is displayed there under X's profile, as if posted by X, even though X's own key never signed it.

▌ 9. Two profiles, one identity

You log in with your signer key and sign events with it, exactly as in any other Nostr client. Those events appear on the signer's own profile, and in addition on the profile of each of its delegators, up to your top-level identity.

You set the signer's profile by publishing a kind-0 event as usual. Separately, a signer can also set a profile for each of its current delegators, so that a top-level identity can present a face to the world without signing any event itself. This delegator-profile mechanism is kind 31065 (§10).

Your identity's profile is what you present to the world. Others should follow and interact with the identity, not with the signer beneath it. The signer is ephemeral and expected to be replaced; the identity is permanent, and is the thing followers should attach to.

▌ 10. Event kinds

This NIP defines two addressable event kinds (kinds 30000 to 39999 in NIP-01, where the latest event for a given (pubkey, kind, d-tag) replaces any earlier one).

Kind | Name | d tag | Signed by
31045 | Bitcoin timestamp | id of the referenced event | any party
31065 | Attributed profile | the delegator's pubkey | a delegatee

▌ 10.1 Kind 31045: Bitcoin timestamp

A 31045 event carries an OpenTimestamps proof for another event (§7). It is addressable by the referenced event's id, so a consumer finds the proof for an event E by querying kind 31045 with d = [E.id], whoever published it. Any valid proof for E is as good as any other, because the proof rests on Bitcoin and not on its publisher.

31045 event tags, marked (yes) if required, (no) if not:

d (yes): Id of the referenced event. The addressable key.
s (yes): Signature of the referenced event. With d, binds the proof to a signed event, not just an id.
p (no): Author pubkey of the referenced event.
b (no): Bitcoin block height of the attestation, or not_yet_available while pending.
t (no): Bitcoin block time (unix seconds), or not_yet_available while pending.
c (no): created_at of the referenced event, when known.
alt (no): NIP-31 summary, e.g. Complete Bitcoin Timestamp.

content is the base64-encoded OpenTimestamps (.ots) proof. Its leaf must commit to sha256(referenced_id || referenced_signature), the concatenation of the referenced event's 32-byte id and 64-byte signature. A consumer should verify the proof against its own view of the Bitcoin chain rather than rely on a relay having accepted it.

Only d and s, together with a verifiable content proof, are required to verify a timestamp. Every single-letter tag (d, p, s, b, t, c) is relay-indexed, so it can also serve as a query key, for example finding proofs by referenced author (p) or by anchoring block (b). b and t additionally duplicate what the proof itself attests; alt is not indexed and serves only as a NIP-31 display label.

{
"kind": 31045,
"tags": [
["d", "<referenced-event-id>"],
["p", "<referenced-event-author>"],
["s", "<referenced-event-signature>"],
["b", "<bitcoin-block-height>"],
["t", "<bitcoin-block-time>"],
["alt", "Complete Bitcoin Timestamp"],
["c", "<referenced-event-created-at>"]
],
"content": "<base64 .ots proof committing to sha256(id||sig)>"
}

▌ 10.2 Kind 31065: Attributed profile

A 31065 event is a profile for one key, published by another: how an identity that never signs anything nonetheless presents a face to the world (§9). Its d tag is the delegator's pubkey, the identity the profile describes, while the event is signed by a delegatee authorized to sign for it. The defining property is that event.pubkey, the signer, is not the subject d. A consumer must confirm, against the delegation timeline of §6, that the signer was a current delegatee of the subject before honoring the profile; one signed by a non-delegatee is ignored.

31065 event tags, marked (yes) if required:

d (yes): The subject: the delegator's pubkey.
alt (yes): The exact string Attributed profile.

content is a JSON object carrying the subject's presentation. Its kind-0-style fields (name, display_name, about, picture, banner, website, nip05, lud16) mean what they mean in NIP-01 and NIP-05. It may also carry the subject's follow list, mute list, and a map giving relay lists for the members of the identity's delegation network (the keys tied to it by delegation), so a client can present and route for the identity without a further fetch.

{
"kind": 31065,
"pubkey": "<delegatee-that-signs>",
"tags": [
["d", "<delegator-pubkey-the-profile-is-for>"],
["alt", "Attributed profile"]
],
"content": "{\"name\":\"…\",\"display_name\":\"…\",\"about\":\"…\",\"website\":\"…\",\"nip05\":\"…\",\"picture\":\"…\",\"relay_lists_by_pubkey\":{\"<pubkey>\":{\"readWriteRelays\":[[\"r\",\"<relay-url>\",\"<scope>\"]],\"favoriteRelays\":[\"<relay-url>\"],\"relaySets\":[{\"id\":\"…\",\"name\":\"…\",\"relayUrls\":[\"<relay-url>\"]}]}},\"publicly_muted_pubkey_hex_ids\":[\"<muted-pubkey>\"],\"current_snapshot_of_dir_indir_followed_pubkey\":[[\"p\",\"<followed-pubkey>\"]]}"
}

Because 31065 is addressable, the current profile for an identity is simply the latest one whose d is that identity, signed by a key that is currently its delegatee. When the signer is rotated, the new signer republishes, and the identity's face carries across the change unbroken.

▌ 11. Reference implementation

Inkan (https://www.inkan.cc) implements this specification as a working Nostr client and a cooperating relay at wss://relay.inkan.cc. Delegation, revocation, and permanent invalidation are recorded by an Ethereum contract deployed at 0x385C0A272b1f44687cb360557b25827bD7CdB7eb, which is the normative reference for the exact on-chain declaration encoding. A separate, network-disconnected "Management Utility" generates keys and signs declarations on an air-gapped machine, so a master key can be created and used to bootstrap an identity without ever touching a networked host.

Nostr event nevent1qqs0weh6ezae8zf86yt5czttapz05m3wh275cmr0nf6dhs6e2352pmsp8emhxue69uhhyetvv9uju6twddskutnrvvhhjcttd95xsmmwv5a8yetvv9uju6twddskutnrvvhkxmmww3skxazqd9hxkctw9e3kxq3q6xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3sawsly6

2026-08-20T10:38:26Z

In reply to nevent1q…fqx6
_________________________

Done.

https://nostrhub.io/naddr1qvzqqqrcvypzp5dxzjv0fvwuym0shmx350573re4t7mpfdm3az6mya7sl7v6s23rqqskxmmvvskhxar0wfskwefdd9jx2mn5d96xjetn94nx7u3ddehhxarjnjhzrn

Good, I'm seeing your 31045 timestamp events on the relay. ...

2026-08-19T19:42:53Z

In reply to nevent1q…aa59
_________________________

Good, I'm seeing your 31045 timestamp events on the relay.

Now that the timestamps are available, the events on npub1u280zakdwcv23nqpgatsmz8lw6aj22aa6gjjlx0d50lqr8m8xucq7kf93q (npub1u28…f93q)'s profile page should become visible again. If you still cannot see them, let me know - I can see them on my end.

I think the reason why the toggles were disabled is that you may have logged in with your signer key before I had recorded your identity on-chain. If the client doesn't detect an on-chain identity when a key first logs in, I think it disables these toggles by default. This setting then sticks even if an on-chain identity is later detected. I should try to make this less confusing somehow.

Nostr event nevent1qqsp9f724n7rnnek2cngp8rgewnhdts4tgy9ssj9wmspmgyug74el7gp8emhxue69uhhyetvv9uju6twddskutnrvvhhjcttd95xsmmwv5a8yetvv9uju6twddskutnrvvhkxmmww3skxazqd9hxkctw9e3kxq3qpy30nwp2zjlm3we9gn6fsp4g22mpsr4smz6cscm92kh6d2qy7y7sy2xtmc

2026-08-19T19:09:21Z

TS test 8-19-2026-4

Nostr event nevent1qqsqmz29x3wsylnsedksdexrs4p2whqkjr8fd308hh4xc8jvxwlkywcp8emhxue69uhhyetvv9uju6twddskutnrvvhhjcttd95xsmmwv5a8yetvv9uju6twddskutnrvvhkxmmww3skxazqd9hxkctw9e3kxq3qpy30nwp2zjlm3we9gn6fsp4g22mpsr4smz6cscm92kh6d2qy7y7svykh2e

2026-08-19T19:09:13Z

TS test 8-19-2026-3

Nostr event nevent1qqsgshwjn3assz8uf0h6sjpqw0lyq8mdjqdpktegslnekvnjvj4yqpgp8emhxue69uhhyetvv9uju6twddskutnrvvhhjcttd95xsmmwv5a8yetvv9uju6twddskutnrvvhkxmmww3skxazqd9hxkctw9e3kxq3qpy30nwp2zjlm3we9gn6fsp4g22mpsr4smz6cscm92kh6d2qy7y7s9fx8sq

2026-08-19T19:09:06Z

TS test 8-19-2026-2

Nostr event nevent1qqsrj8ek30l59q8thnsgms54rsrx8gf5etth7wedvgzpf96t2ysdf7cp8emhxue69uhhyetvv9uju6twddskutnrvvhhjcttd95xsmmwv5a8yetvv9uju6twddskutnrvvhkxmmww3skxazqd9hxkctw9e3kxq3qpy30nwp2zjlm3we9gn6fsp4g22mpsr4smz6cscm92kh6d2qy7y7szq6zax

2026-08-19T19:08:58Z

TS test 8-19-2026-1

those were disabled by default for some reason. enabled now

2026-08-19T19:02:46Z

In reply to nevent1q…sl0p
_________________________

those were disabled by default for some reason. enabled now

I think that's most likely the issue I pointed out in the ...

2026-08-19T15:36:39Z

In reply to nevent1q…m5ft
_________________________

I think that's most likely the issue I pointed out in the note below.

You have probably been posting from a client other than https://www.inkan.cc, which means that you didn't automatically publish 31045 OTS timestamps for your events to the Inkan relay (only the Inkan client takes care of this automatic publication). This means that Inkan now cannot find these timestamps for your events on the relay and thus treats your events as invalid.

You should be able to correct this by logging into the Inkan client and making sure that your signer extension approves the signing of 31045 events. You should then probably stay logged in for some time since the client's catching up on the publication of the missing events might take a while. The timestamps for your events exist on the timestamping server, your Inkan client just needs to catch up with publishing them to the relay as 31045 events.

quoting
nevent1q…w0fn
[Quick technical note, just FYI: I'm not currently seeing 31045 OTS timestamp events for events published by your signer pubkey on the Inkan relay. This might be because you did not allow your signer extension to sign the "31045" events that the client tried to publish. Without these OTS timestamp events being available on the relay, the events you have posted so far will get filtered out and become invisible on the Inkan client once they fall outside the recency window (i.e. soon). However, these events *have* been OTS timestamped and the timestamps are stored on the timestamping server. If you permit your client through the browser extension to publish the 31045 timestamp events in the future, the events you posted should become visible again, once the 31045 OTS timestamp events have been published.]

By the way, you might be able to speed up the process of catching ...

2026-08-19T15:47:44Z

In reply to nevent1q…kl90
_________________________

By the way, you might be able to speed up the process of catching up on the publication of the timestamps by going to

Settings >> Inkan Settings >> Delegation & Timestamping

and on that page switch off and then immediately back on the two toggles that say

"Periodially collect timestamps info from TS Server"

and

"Periodically publish timestamps info to relays".

Switching these toggles off and back on should restart these jobs immediately (otherwise they just run periodically while you are logged in).

Another thing you can try is to switch the "Apply timestamp filter" toggle off, and then go back to the profile page of your master delegator key. I'd predict that the currently missing events will be shown because the functionality that filters out events for which no valid timestamp could be found will have been turned off. Playing with the "Apply timestamp filter" toggle and observing its effect can be useful for getting a more thorough understanding of how Inkan works.

That would explain it. The Inkan client sends the 31045 timestamp ...

2026-08-18T15:17:34Z

In reply to nevent1q…aqgq
_________________________

That would explain it. The Inkan client sends the 31045 timestamp events to the Inkan relay automatically while you are logged into the client.

So when you log in the next time, you may not immediately see the regular events you posted since the client won't find their timestamps on the relay at first. However, it should catch up over time as the 31045 events are getting posted to the relay and the client can then later retrieve them. So they should become visible again after a while.

If you use another client, the important thing is to include wss://relay.inkan.cc among the relays you post to (it looks like you are doing this!). If your events don't end up on that Inkan relay soon after their created_at, they don't get timely OTS timestamps at all, which makes them forever "invalid" from Inkan's perspective.

@npub16xn…6z6l my delegation account is empty and signer ...

2026-08-19T09:54:33Z

inkan (npub16xn…6z6l) my delegation account is empty and signer profile is empty except the most recent post. is this normal? :)

thanks, will add it!

2026-08-18T17:56:41Z

In reply to nevent1q…w0sf
_________________________

thanks, will add it!

It looks like most of my Nostr events get timestamped within 30 ...

2026-08-18T17:29:54Z

In reply to nevent1q…rncl
_________________________

It looks like most of my Nostr events get timestamped within 30 minutes, often faster than 15 minutes. A few take up to 45 minutes. And then there is the occasional outlier taking 2 1/2 hours. The client uses a default setting under which it considers an event "validly signed and dated" if its OTS timestamp comes within 4 hours after its created_at.

OTS was a huge pain in getting Inkan to work reasonably fast. At ...

2026-08-18T15:48:18Z

In reply to nevent1q…tyds
_________________________

OTS was a huge pain in getting Inkan to work reasonably fast.

At first I wanted to make it work without relay modifications, which meant that the client had, after receiving a regular event, go out a second time to check whether an OTS proof for that event was available on the relay. That led to huge bottlenecks and involved complicated caching mechanisms etc.

The solution to this was to make the relay itself return the OTS proof synchronously along with the reference event (whenever the relay stores such an OTS proof).

FYI, there is currently a small bug in the OTS implementation that can lead to interference when a pubkey decides to publish 31045 OTS proofs on behalf of *another* pubkey. I haven't gotten around to fixing this, but it shouldn't affect things with the default settings where pubkeys only publish proofs for their own events.

Your AI can explain the details of the OTS-enabled relay. I'd also be curious to see your OTS lib if you release it.

If you feel like it, you can even delegate from your Inkan seed ...

2026-08-18T18:12:13Z

In reply to nevent1q…53ql
_________________________

If you feel like it, you can even delegate from your Inkan seed key

"npub1u280zakdwcv23nqpgatsmz8lw6aj22aa6gjjlx0d50lqr8m8xucq7kf93q"

down to your usual pubkey for ngmi, i.e. down to

"npub14p7fhlz9wrlptt7a5mqqjkk79460k98r999l7dafv4fznqaa565qhjdzry"

If you did that, any future posts by your usual ngmi key will get automatically attributed to the Inkan seed key (until you revoke the delegation). If you include the Inkan relay when making your usual ngmi posts, you'll also get automatic OTS timestamps for notes you post with your ngmi key, which you can download and keep for your records.

Other people will of course be able to see your ngmi posts from any Nostr client as usual. And if they log into Inkan, they'll also be able to see your events being attributed to your Inkan seed key identity.

To create a delegation like that, you'd need to use the "Build Custom Transaction" menu in the Inkan Management Utility. You can download a Linux AppImage of the Management Utility here:

https://www.inkan.cc/settings/inkan-management-utility

The actual delegation you'd be creating would be from your current Inkan signer key to the ngmi key, extending the delegation chain down to your ngmi key.

Happy to walk you through creating this kind of transaction and sponsor it if you're interested. But no pressure, I don't mean to overwhelming, just wanted to point this out as an option.🙇

Degraded performance for Claude Opus 5 and Claude Haiku 4.5 and ...

2026-08-19T09:48:28Z

Degraded performance for Claude Opus 5 and Claude Haiku 4.5

and again, and again, and again...

#anthropic

got myself a fancy @npub1qu7…7p98 #mailstr address 🥰

2026-08-18T18:43:03Z

got myself a fancy Form* (npub1qu7…7p98) #mailstr address 🥰

That would also be my opinion.

2026-08-18T12:54:03Z

In reply to nevent1q…gw04
_________________________

That would also be my opinion.

Posting from amethyst atm 🤔

2026-08-18T14:00:45Z

In reply to nevent1q…fn23
_________________________

Posting from amethyst atm 🤔

[Quick technical note, just FYI: I'm not currently seeing ...

2026-08-18T13:56:54Z

In reply to nevent1q…5uex
_________________________

[Quick technical note, just FYI: I'm not currently seeing 31045 OTS timestamp events for events published by your signer pubkey on the Inkan relay. This might be because you did not allow your signer extension to sign the "31045" events that the client tried to publish. Without these OTS timestamp events being available on the relay, the events you have posted so far will get filtered out and become invisible on the Inkan client once they fall outside the recency window (i.e. soon). However, these events *have* been OTS timestamped and the timestamps are stored on the timestamping server. If you permit your client through the browser extension to publish the 31045 timestamp events in the future, the events you posted should become visible again, once the 31045 OTS timestamp events have been published.]

Inkan actually also requires a small update to relays, which need ...

2026-08-18T13:21:05Z

In reply to nevent1q…qk8e
_________________________

Inkan actually also requires a small update to relays, which need to send OTS proofs along with the events they return. The Inkan relay uses the following reference implementation of this feature:

https://gitlab.com/inkan_dev/ots-enabled-strfry

Also, the source code for the Management Utility (i.e. the utility for airgapped creation of "non-toy" identities) is available here:

https://www.inkan.cc/settings/inkan-management-utility

Pointing an AI to these should give people a pretty good idea of what the on-chain declarations and OTS functionality look like.

Not sure if it's just a matter of SKILL or AGENTS.md ... I started working on this one and a half years ago, and even with agentic coding it's been many months of work ...

at least perhaps a SKILL or AGENTS.md for other clients to ask ...

2026-08-18T11:53:31Z

In reply to nevent1q…k0m3
_________________________

at least perhaps a SKILL or AGENTS.md for other clients to ask their AI to implement this feature? would be super cool if #amethsyst and #noornote had this

What's the problem? Genuine usecase of a smartcontract, a ...

2026-08-18T12:36:31Z

In reply to nevent1q…qsh5
_________________________

What's the problem? Genuine usecase of a smartcontract, a very good one imo

I think when you say "database," you are referring to the ...

2026-08-18T12:26:05Z

In reply to nevent1q…hufv
_________________________

I think when you say "database," you are referring to the server that I was using with earlier versions.

I was able to get rid of that server entirely. The fetching of the delegation info is now all done directly by the client.

Also, onboarding is much easier now. There's now a button on the home page that allows users to create a throw-away toy identity directly in the browser, which makes it easy to try out (feel free to do so!).

Also, after the identity has been recorded on chain, there is now a first-login wizard that gets all the details for the identity set up automatically. The wizard includes setup of the two profiles for the signer key and the identity-securing key.

Also, you no longer need to hold ETH to create an identity. There's an option in the setup process that allows you to send me the identity creation file and I can sponsor the tiny amount of gas fees (which I'm happy to do).

In any event, thanks for taking a look! If you play with it more ...

2026-08-18T11:12:06Z

In reply to nevent1q…5uex
_________________________

In any event, thanks for taking a look!

If you play with it more and have any questions or comments, let me know any time.

Also, you are right that there should be a NIP, but I'm ...

2026-08-18T11:46:24Z

In reply to nevent1q…5uex
_________________________

Also, you are right that there should be a NIP, but I'm finding it difficult to compress the concepts into a form that fits that schema. The following explanation is the closest I currently have:

quoting
nevent1q…4pj3
A short explainer of the Inkan identity system.

▌ What is Inkan?

Inkan enables online identities whose private key can be created in cold storage and stay there permanently. The key never has to touch an internet-connected device and does not have to be kept close at hand. The identity itself can nonetheless be used easily for everyday online authentication, like posting, replying, messaging, or signing in to services.

▌ How does it work?

Inkan builds on the Nostr protocol which facilitates the distribution of digitally signed content. The idea behind Inkan is that the identity-securing key never has to sign that content itself. It can delegate signing authority to delegatee keys, which handle the everyday signing on its behalf. If a delegatee key is ever lost or stolen, it can be replaced.

▌ Delegations between keys

Delegations are time-indexed two-place relations. Between any two key pairs, at any moment in time, the first key pair either delegates signing authority to the second or it doesn't. When it does, the second key is authorized to sign on the first's behalf. When it doesn't, the second key has no such authority.

Delegations are either direct or indirect. A direct delegation arises when one key has expressly declared that it delegates signing authority to another. An indirect delegation arises because, on Inkan's concept of delegation, the relation is transitively closed: if X delegates to Y and Y delegates to Z, then X also indirectly delegates to Z.

▌ How is a direct delegation created?

A direct delegation from key pair X to key pair Y is created when both key pairs digitally sign a "Declaration of Delegation of Signing Authority" by which X declares that it delegates signing authority to Y, and Y declares that it accepts.

The signed declaration must then be recorded on-chain (Inkan uses Ethereum). The delegation begins at the time of the block in which the declaration was recorded, and remains in effect until it is revoked.

One special case: the above holds only if neither X nor Y has previously permanently invalidated itself. If either has, no delegation relationship is created, even though the declaration sits on-chain. (See "What is permanent key invalidation?" below.)

As part of the delegation declaration, X and Y also specify whether X can revoke the delegation unilaterally, or whether Y's consent is required. The default is unilateral revocation by X. This matters most if Y's private key is ever lost: with unilateral revocation, the user can still revoke using X alone; if Y's consent is required, they cannot (since they no longer have access to Y, and thus can no longer use Y to sign the revocation declaration). For most users, unilateral revocation is recommended for this reason.

▌ How is a direct delegation terminated?

A direct delegation from key pair X to key pair Y is terminated when X digitally signs a "Declaration of Revocation of Signing Authority," by which it revokes the signing authority it had delegated to Y. If the original delegation declaration specified that Y's consent is required for revocation, Y must also sign; otherwise, X's signature alone is enough.

The signed revocation declaration must then be recorded on-chain. If it carries all required signatures, the delegation relationship terminates at the time of the block in which the declaration was recorded.

One final wrinkle: when a delegation declaration and a revocation declaration between the same X and Y land in the same Ethereum block, the revocation is by convention treated as occurring first, and the delegation as occurring thereafter. So from that block on, the delegation is in effect (assuming neither X nor Y has been permanently invalidated). The convention is just a tiebreaker for cases that block timestamps can't order.

▌ What is permanent key invalidation?

The third type of declaration in Inkan is the "Declaration of Permanent Invalidation of a Key Pair." It is signed by the key pair invalidating itself, declaring that, from then on, this key pair can no longer participate in any direct delegation relationship, either as delegator or as delegatee.

Once signed, the invalidation declaration must be recorded on-chain. It takes effect at the time of the block in which it was recorded.

From that point on, all existing direct delegations in which the invalidated key pair was delegator or delegatee are terminated, and no new direct delegations involving it can come into existence, even if a delegation declaration naming it is later recorded on-chain.

The main use is invalidating a compromised master key. Such a key has no delegator, so ordinary revocation isn't available. Permanent invalidation lets the user withdraw it from the Inkan ecosystem entirely.

▌ Delegation timelines

An Inkan-enabled client can read the three types of declarations on the blockchain and, for any given pubkey and any past moment up to the present, compute the direct delegation relationships that the pubkey was involved in at that moment. The indirect ones follow by transitive closure.

So for any pubkey, the client can compile a complete timeline showing every direct and indirect delegation relationship that pubkey has been involved in at any time, up to the present moment.

At www.inkan.cc, registered users can view such timelines for any pubkey that has been involved in delegations and trace them back to the underlying declarations recorded on-chain.

▌ Bitcoin timestamping of Nostr events

Inkan needs an objective, auditable rule for when the act of signing each Nostr event is deemed to have occurred.

To achieve this, Inkan uses OpenTimestamps (OTS) to anchor Nostr events to Bitcoin blocks. An OTS proof for an event establishes that the event and the cryptographic artifact that constitutes its "signature" existed by the time of a specific Bitcoin block.

Inkan then treats an event's 'created_at' field (the signer's self-declared timestamp) as its objective signing time if an OTS proof shows the event and its signature existed shortly after that time. The "shortly after" window is user-configurable (default: four hours). Events without such a proof are treated as if they had no valid digital signature at all, are not displayed by the client, and are not attributed to any delegator.

▌ Attribution of Nostr events

Under this framework, we know, for any past time T and any two keys X and Y, whether X delegated (directly or indirectly) signing authority to Y at T. And for any event that Y has signed, with both a valid cryptographic signature and a valid OTS anchor, we have an objective signing time, i.e. the event's 'created_at'.

Putting this together gives us the necessary ingredients for a well-defined attribution rule: an event E is attributed to key X if and only if some key Y validly signed E at time T and, as of T, X delegated signing authority to Y.

So, for example, a text note signed by a delegatee Y during a valid delegation period from X appears on X's timeline and is displayed there under X's profile as if posted by X, even though X's own key never signed it.

▌ Setting up and managing an Inkan identity

Inkan provides a tool, the "Inkan Management Utility," that automates the creation of the key pairs and the delegations running through them that constitute an identity. The utility can also create key replacements and permanent invalidations. The utility runs without network access and is intended to be used on an amnesic, air-gapped system such as Tails (with networking disabled), so that nothing persists after shutdown and the master key is never exposed to a networked host. The utility is available as a Linux AppImage:
https://www.inkan.cc/settings/inkan-management-utility

Users should set up their identity by building a chain of delegations (master → intermediate(s) → signer) rather than a single master-to-signer delegation. By transitive closure, events signed by the bottom-of-chain signer are attributed to the master. Revocations only require the immediate delegator above the affected signer, so it is not necessary to keep private keys above that immediate delegator close at hand. In particular, the master, once it has signed the chain's initial top-level delegation during the identity's creation ceremony, can stay in cold storage indefinitely.

Generated key pairs can be backed up in encrypted form on USB sticks; multiple copies in separate locations are easy and recommended. Only the current signer key and the delegator immediately above that signer need to be reachable. The rest can be stored in relatively inaccessible locations.

The Ethereum gas fees required for on-chain recording of delegation, revocation and invalidation declarations can be paid by the user directly or by a sponsor. Sponsored payment lets a user create and manage an Inkan identity without holding ETH, and without revealing any private key information to the sponsor.

Setting up an Inkan identity takes some up-front ceremony, but ongoing use does not. The initial work is to create key pairs, sign the declarations that wire the keys into delegation relationships, and record these declarations on-chain. This is a one-time effort and is in large part automated through the management utility. After that, most of the keys can be put away and not be touched again, with only the signing key sitting "hot" on internet-connected devices for everyday signing, and the immediate delegator of the signing key kept close at hand so that it can perform key rotations if the signer is lost or compromised, or preemptively on a periodic basis.

▌ Using the client — two profiles, one identity

When using the Inkan client, you log in with your signer key and sign events with it, just as you would with any other Nostr client. These events appear on the signer's profile page (as in any other client), but in addition they also appear on the profile pages of each of its delegators, including, especially, your top-level identity.

You can set the signer's profile (avatar, banner, display name, etc.) by publishing a kind-0 event as usual. In addition, Inkan includes a mechanism by which the signer can set profiles for its current delegators. This allows your top-level identity to maintain a profile without having to sign any Nostr event itself.

Your identity's profile is what you present yourself with to the world. Others should follow and interact with the identity, not with the signer beneath it. The signer is ephemeral and expected to be replaced sooner or later. The identity is expected to be permanent and is the appropriate object to which followers should attach.

Also, when you are on a delegator profile page, you can click on ...

2026-08-18T11:09:08Z

In reply to nevent1q…5uex
_________________________

Also, when you are on a delegator profile page, you can click on the green "D"s that appear on the avatars.

You will see backup data explaining the delegation relationships that that cause the event to be displayed there, and you can click through to full tables showing historical delegations.

I don't have a NIP, but I have the following explanation. ...

2026-08-18T11:03:42Z

In reply to nevent1q…ygl6
_________________________

I don't have a NIP, but I have the following explanation. This covers pretty much all of the conceptual details:

quoting
nevent1q…4pj3
A short explainer of the Inkan identity system.

▌ What is Inkan?

Inkan enables online identities whose private key can be created in cold storage and stay there permanently. The key never has to touch an internet-connected device and does not have to be kept close at hand. The identity itself can nonetheless be used easily for everyday online authentication, like posting, replying, messaging, or signing in to services.

▌ How does it work?

Inkan builds on the Nostr protocol which facilitates the distribution of digitally signed content. The idea behind Inkan is that the identity-securing key never has to sign that content itself. It can delegate signing authority to delegatee keys, which handle the everyday signing on its behalf. If a delegatee key is ever lost or stolen, it can be replaced.

▌ Delegations between keys

Delegations are time-indexed two-place relations. Between any two key pairs, at any moment in time, the first key pair either delegates signing authority to the second or it doesn't. When it does, the second key is authorized to sign on the first's behalf. When it doesn't, the second key has no such authority.

Delegations are either direct or indirect. A direct delegation arises when one key has expressly declared that it delegates signing authority to another. An indirect delegation arises because, on Inkan's concept of delegation, the relation is transitively closed: if X delegates to Y and Y delegates to Z, then X also indirectly delegates to Z.

▌ How is a direct delegation created?

A direct delegation from key pair X to key pair Y is created when both key pairs digitally sign a "Declaration of Delegation of Signing Authority" by which X declares that it delegates signing authority to Y, and Y declares that it accepts.

The signed declaration must then be recorded on-chain (Inkan uses Ethereum). The delegation begins at the time of the block in which the declaration was recorded, and remains in effect until it is revoked.

One special case: the above holds only if neither X nor Y has previously permanently invalidated itself. If either has, no delegation relationship is created, even though the declaration sits on-chain. (See "What is permanent key invalidation?" below.)

As part of the delegation declaration, X and Y also specify whether X can revoke the delegation unilaterally, or whether Y's consent is required. The default is unilateral revocation by X. This matters most if Y's private key is ever lost: with unilateral revocation, the user can still revoke using X alone; if Y's consent is required, they cannot (since they no longer have access to Y, and thus can no longer use Y to sign the revocation declaration). For most users, unilateral revocation is recommended for this reason.

▌ How is a direct delegation terminated?

A direct delegation from key pair X to key pair Y is terminated when X digitally signs a "Declaration of Revocation of Signing Authority," by which it revokes the signing authority it had delegated to Y. If the original delegation declaration specified that Y's consent is required for revocation, Y must also sign; otherwise, X's signature alone is enough.

The signed revocation declaration must then be recorded on-chain. If it carries all required signatures, the delegation relationship terminates at the time of the block in which the declaration was recorded.

One final wrinkle: when a delegation declaration and a revocation declaration between the same X and Y land in the same Ethereum block, the revocation is by convention treated as occurring first, and the delegation as occurring thereafter. So from that block on, the delegation is in effect (assuming neither X nor Y has been permanently invalidated). The convention is just a tiebreaker for cases that block timestamps can't order.

▌ What is permanent key invalidation?

The third type of declaration in Inkan is the "Declaration of Permanent Invalidation of a Key Pair." It is signed by the key pair invalidating itself, declaring that, from then on, this key pair can no longer participate in any direct delegation relationship, either as delegator or as delegatee.

Once signed, the invalidation declaration must be recorded on-chain. It takes effect at the time of the block in which it was recorded.

From that point on, all existing direct delegations in which the invalidated key pair was delegator or delegatee are terminated, and no new direct delegations involving it can come into existence, even if a delegation declaration naming it is later recorded on-chain.

The main use is invalidating a compromised master key. Such a key has no delegator, so ordinary revocation isn't available. Permanent invalidation lets the user withdraw it from the Inkan ecosystem entirely.

▌ Delegation timelines

An Inkan-enabled client can read the three types of declarations on the blockchain and, for any given pubkey and any past moment up to the present, compute the direct delegation relationships that the pubkey was involved in at that moment. The indirect ones follow by transitive closure.

So for any pubkey, the client can compile a complete timeline showing every direct and indirect delegation relationship that pubkey has been involved in at any time, up to the present moment.

At www.inkan.cc, registered users can view such timelines for any pubkey that has been involved in delegations and trace them back to the underlying declarations recorded on-chain.

▌ Bitcoin timestamping of Nostr events

Inkan needs an objective, auditable rule for when the act of signing each Nostr event is deemed to have occurred.

To achieve this, Inkan uses OpenTimestamps (OTS) to anchor Nostr events to Bitcoin blocks. An OTS proof for an event establishes that the event and the cryptographic artifact that constitutes its "signature" existed by the time of a specific Bitcoin block.

Inkan then treats an event's 'created_at' field (the signer's self-declared timestamp) as its objective signing time if an OTS proof shows the event and its signature existed shortly after that time. The "shortly after" window is user-configurable (default: four hours). Events without such a proof are treated as if they had no valid digital signature at all, are not displayed by the client, and are not attributed to any delegator.

▌ Attribution of Nostr events

Under this framework, we know, for any past time T and any two keys X and Y, whether X delegated (directly or indirectly) signing authority to Y at T. And for any event that Y has signed, with both a valid cryptographic signature and a valid OTS anchor, we have an objective signing time, i.e. the event's 'created_at'.

Putting this together gives us the necessary ingredients for a well-defined attribution rule: an event E is attributed to key X if and only if some key Y validly signed E at time T and, as of T, X delegated signing authority to Y.

So, for example, a text note signed by a delegatee Y during a valid delegation period from X appears on X's timeline and is displayed there under X's profile as if posted by X, even though X's own key never signed it.

▌ Setting up and managing an Inkan identity

Inkan provides a tool, the "Inkan Management Utility," that automates the creation of the key pairs and the delegations running through them that constitute an identity. The utility can also create key replacements and permanent invalidations. The utility runs without network access and is intended to be used on an amnesic, air-gapped system such as Tails (with networking disabled), so that nothing persists after shutdown and the master key is never exposed to a networked host. The utility is available as a Linux AppImage:
https://www.inkan.cc/settings/inkan-management-utility

Users should set up their identity by building a chain of delegations (master → intermediate(s) → signer) rather than a single master-to-signer delegation. By transitive closure, events signed by the bottom-of-chain signer are attributed to the master. Revocations only require the immediate delegator above the affected signer, so it is not necessary to keep private keys above that immediate delegator close at hand. In particular, the master, once it has signed the chain's initial top-level delegation during the identity's creation ceremony, can stay in cold storage indefinitely.

Generated key pairs can be backed up in encrypted form on USB sticks; multiple copies in separate locations are easy and recommended. Only the current signer key and the delegator immediately above that signer need to be reachable. The rest can be stored in relatively inaccessible locations.

The Ethereum gas fees required for on-chain recording of delegation, revocation and invalidation declarations can be paid by the user directly or by a sponsor. Sponsored payment lets a user create and manage an Inkan identity without holding ETH, and without revealing any private key information to the sponsor.

Setting up an Inkan identity takes some up-front ceremony, but ongoing use does not. The initial work is to create key pairs, sign the declarations that wire the keys into delegation relationships, and record these declarations on-chain. This is a one-time effort and is in large part automated through the management utility. After that, most of the keys can be put away and not be touched again, with only the signing key sitting "hot" on internet-connected devices for everyday signing, and the immediate delegator of the signing key kept close at hand so that it can perform key rotations if the signer is lost or compromised, or preemptively on a periodic basis.

▌ Using the client — two profiles, one identity

When using the Inkan client, you log in with your signer key and sign events with it, just as you would with any other Nostr client. These events appear on the signer's profile page (as in any other client), but in addition they also appear on the profile pages of each of its delegators, including, especially, your top-level identity.

You can set the signer's profile (avatar, banner, display name, etc.) by publishing a kind-0 event as usual. In addition, Inkan includes a mechanism by which the signer can set profiles for its current delegators. This allows your top-level identity to maintain a profile without having to sign any Nostr event itself.

Your identity's profile is what you present yourself with to the world. Others should follow and interact with the identity, not with the signer beneath it. The signer is ephemeral and expected to be replaced sooner or later. The identity is expected to be permanent and is the appropriate object to which followers should attach.

Yes, but I think we need some people to try out the current ...

2026-08-18T10:57:27Z

In reply to nevent1q…5uex
_________________________

Yes, but I think we need some people to try out the current client to get familiar with the idea.

In the left lower corner, are you seeing the avatar of your signer key, with an overlayed avatar for the identity key?

Clicking on the overlay gets you to your permanent identity profile page.

Clicking on "profile" gets you to your signer profile page.

Hi there. If you rotate the signer npub, you do not lose the ...

2026-08-18T10:54:57Z

In reply to nevent1q…gguj
_________________________

Hi there.

If you rotate the signer npub, you do *not* lose the followers that attach to your identity, which is secured by:

e28ef176cd7618a8cc0147570d88ff76bb252bbdd2252f99eda3fe019f673730

Be sure to treat the profile page for this identity-securing key as the one that followers should attach to. And be sure to keep the privkey that is associated with this identity-securing key in airgapped cold storage.

This key represents the permanent "you", and it survives replacements of the signer key.

Take a pretty close look at each step in the wizard. Default ...

2026-08-18T10:39:58Z

In reply to nevent1q…0k2g
_________________________

Take a pretty close look at each step in the wizard.

Default settings should work, but be sure to create the two distinct profiles, one of the signer and one for the identity.

Let me know if everything works through the end of the wizard.

Ok, your identity should be on-chain now. The following is your ...

2026-08-18T10:37:20Z

In reply to nevent1q…vefu
_________________________

Ok, your identity should be on-chain now.

The following is your signer pubkey (i.e. put the privkey that is associated with this pubkey into the NIP-07 browser extension before logging in):

199f12c94fe6a2903908c46efcb91190d9993b7380886c98321b59c513dca973

And this should be your identity-securing pubkey (keep the privkey that is associated with this pubkey completely airgapped):

e28ef176cd7618a8cc0147570d88ff76bb252bbdd2252f99eda3fe019f673730

After logging in with the signer pubkey through NIP-7, there should be a welcome wizard.

Be sure to create distinct profiles with different profile pictures for (i) the signer pubkey and (ii) the identity securing pubkey.

You'll want to be able to tell these two profiles apart.

If you get stuck anywhere, let me know.

I think @npub16xn…6z6l is a very cool experiment, and it works. ...

2026-08-18T10:36:17Z

I think inkan (npub16xn…6z6l) is a very cool experiment, and it works. however, there needs to be a NIP so other clients can follow the schema. can't ask others to follow my seed npub and then they can't see what I post

Nostr event nevent1qqsf06trp8lxgk45q6kazlpf5ccascrmgqzm6qy27kfnwkdcw59qz9gp8emhxue69uhhyetvv9uju6twddskutnrvvhhjcttd95xsmmwv5a8yetvv9uju6twddskutnrvvhkxmmww3skxazqd9hxkctw9e3kxq3qrx039j20u63fqwggc3h0ewg3jrvejwmnszyxexpjrdvu2y7u49es9zs4f5

2026-08-18T10:32:39Z

test

It works best on a laptop / desktop with NIP-7 browser extension. ...

2026-08-18T10:14:13Z

In reply to nevent1q…7raa
_________________________

It works best on a laptop / desktop with NIP-7 browser extension. NIP-46 seems to work as well, but I haven't tested extensively. It's not optimized for mobile. Feel free to ask any questions anytime.

You may be interested in this discussion with @npub1t6j…ksrw. ...

2026-08-18T09:59:05Z

In reply to nevent1q…h8wt
_________________________

You may be interested in this discussion with Constant (npub1t6j…ksrw). He pointed out that verification of OTS proofs can be very fast, which turned out to be true.👇

quoting
nevent1q…5n9v
FYI, Inkan makes extensive use of OTS proofs. They are a central element of a key rotation system. Inkan timestamps a concatenation of event_id + signature.

I do find it useful to publish the OTS info through Nostr events. If the OTS info is signed by a known pubkey (possibly by the same pubkey that signed the reference event or one's own pubkey), this can send trust signals which make it less necessary to independently audit the OTS info, absent anything suspicious.

I also find it useful to include info about the reference event in the OTS event, in particular the reference event's pubkey, signature and created_at. Moreover, the lowest BTC block in which the proof is anchored and its timestamp should be included.

I also think that OTS events should be addressable events -- each signing pubkey should get only one opinion regarding the lowest BTC timestamp that is available for a given reference event.

I've included a sample OTS event from Inkan to illustrate the shape that I've found most useful in practice:

{
"kind": 31045,
"id": "9b5e4b154cb30ece6edc94d87c14dad8dec47cacc958227d5b21d36abfa9f6af",
"pubkey": "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23",
"created_at": 1777422076,
"tags": [
[
"d",
"6cf8a174c3e1bc6cb4eda11f5b93a04413776d044c5aed006fef080f336fdfb6"
],
[
"p",
"d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23"
],
[
"s",
"429eb4f965e5c2d14bbdb54370e0be63c2388e29d4077d3286349ae7fc7302b61a5e506a05834acb50053908e20ed6a36ae8c09f4fd3b0cef4d9f0a6cec308cf"
],
[
"b",
"947055"
],
[
"t",
"1777400959"
],
[
"alt",
"Complete Bitcoin Timestamp"
],
[
"c",
"1777391199"
]
],
"content": "AE9wZW5UaW1lc3RhbXBzAABQcm9vZgC/ieLohOiSlAEIjqT9pJouNM2LV5xdUIHPi9Zu6ah3DlaMq9GqPd2+/FPwEBzbLgerPtDTFWt/rrsP8fsI8AjH08Luv0xfnQjwIOmb09izZmrXfwDHXH6vLsaVvma8oeREeiQOLbJImkdpCPEgACuUPZl913m7H4qWT/2YhxOVlbka0KiazVt7kzXV2akI8BCF7U/JXsqU0O9VE9DPXB7HCPEg07lLgYAMs6+D2+ORmzf9/d/71YMLY+uBFGVMy+eThgcI8QRp8NZv8AiuncE7Mwzcx/8Ag9/jDS75DI4uLWh0dHBzOi8vYWxpY2UuYnRjLmNhbGVuZGFyLm9wZW50aW1lc3RhbXBzLm9yZwjwIIBZ5c9lUtDMmO7pXcINbK0MqK4Js2QHfT4K4rGbuExCCPEgChH41skC/7/FT43MICR+zkrh+fZqyDOtjBGUm5+J3u8I8CBlagb7N54NttzgBMPxChcSw24B53EEvBvOxt9bcCZAvAjxIBOI7rPbgMnzwbX5UJT9S4IOirX19BPU04e0ezzwciOfCPEgXTMEQ0icWDuAylKEW4Ivavdci/YAWIEv0SQ0HFf8s/8I8SAYqkXh8NU36+YUesLH4g+TZvEKML2qGJuGX12mysWbxAjwICUOb2N4RDtZPvVUQc8OzhJK3nfWKDkqpSMqLyNWKNYuCPAg1Ul7hArE1q+Tm+9DMh4ob4eddklRRzS9vbRe3S/m+LoI8CBB7WZXGAgPrgdPZajtwHqp4shCiRNdLuuqltdwlytvWQjxIA6SEUIReSAFC2lA/fG22ZHsshjG9wDl0e/Vep/w1ZOnCPAgIyzpQHNa8zyJuTq+7/rOc4/s5oSpnFAD0IVnN3t/q70I8CA5WvfpGvzFYuUuP2LeJXNQRyfpOo4KEImq6E1dYmTmsAjwIBZmjRHxHAIzBRHOK0rQdxB05gCyphpM5brZAX1jjUKCCPAgeKPdBwpp9OLqYuovrcr0AS0bpnvvbFMGLD65yW0HMQEI8VkBAAAAAeVW0FXcs6j9W7UDf0nGA5i9VbQgUNcNxz9s4oOT1oBzAAAAAAD+////Ato7AAAAAAAAFgAUOcSOFLmE5Y5EAImKTk3+0fLTg74AAAAAAAAAACJqIPAEbnMOAAgI8CC6wj6NCPQhynQQaP7HQ6HVFBJTjOgO668bU/C/DJdSmAgI8SCBtYeuXSbsPZ4/aKAg7H8HP6Oh6jaqWYUNUF7FDeV1nwgI8CCZkFEui2Dkh95uFfC53qJnx70m1m4oWubWoWKQQ3aGoAgI8SCCoAOlqcfh5VCJYa+qgkh+EhMT8vjbwWhgjrkH3B4GYwgI8SBoOHnDQvSjamiihpyFRDSnrQ2bjIQqR3JIPjk/+3RWLwgI8SAMoPz2gaKaiCf5CMaYcnz2YRZUXnW/ZtNs0LUKEUcjoAgI8CCIn0U6v7sfmjXH42/9RTgcx7YCOrjS9KcBA6KzK51eBggI8CCDFzGJB3m8HFbI0gbGHAMP5awZJhaSujZ9ipyHD1ExDAgI8CCgoGzBbt5C6fWHxYgE3VbvywUE/slwVJjaoI0uYBJhQggI8CCtSTgUbBKvsVRpwvs0f7RpLiROko8EnX1eNZiVKVIrJggI8CBNZ2rcpTevhVy4Y5WrBXrmWfDB1QgllPr9J+Mmh/VvUwgI8SAqFoRrrr2B+iAuhkx2PrFC+6la03Z/wFOfYlu1aRCGoggIAAWIlg1z1xkBA+/mOQ==",
"sig": "7a7a57afba9ec2417e07604e41f63e657472e82ffad66e4f632c6ca954b67dba184c5100faf207e7b36f5f61852409d79f8980006f557f208a89fee59a8b117e"
}

I'm not really an expert on crypto, I just used blockchains ...

2026-08-18T09:35:22Z

In reply to nevent1q…2kn4
_________________________

I'm not really an expert on crypto, I just used blockchains for this project. That said, the self-custody / sovereignty portions of the document make sense to me. For some of the claims, I'm not familiar enough with the particular properties of Bitcoin in particular to fully evaluate these claims, although they seem plausible to me at first glance. The document does read overwritten in the way AI slop often is, which doesn't necessarily make it incorrect.

Agreed. If you're interested, please feel free to try it out ...

2026-08-18T08:28:53Z

In reply to nevent1q…yp5f
_________________________

Agreed. If you're interested, please feel free to try it out and play around with it, for example by making a throw-away "toy identity" on the homepage. I'm happy to sponsor the tiny bit of gas fees for the identity creation for people who'd like to give it a try. Also always happy to answer questions.

This is it. I'm seeing it only on nos.lol - can you see it? ...

2026-08-17T11:09:53Z

In reply to nevent1q…wt75
_________________________

This is it. I'm seeing it only on nos.lol - can you see it?

quoting
nevent1q…63ey
# Sovereign Signal
### A framework for Nostr identity sovereignty

*MIT license. Share freely. No author credit required.*

---

## The Problem in One Sentence

Your nsec is doing two jobs it should never do simultaneously: it is your permanent identity and your active signing key at the same time, stored in one place, with no separation between them.

This is not a flaw in the Nostr protocol. The protocol is correctly designed. This is a flaw in how the protocol is used in practice — and it accumulated by default, because the simplest implementation became the standard one.

The simplest implementation is not the sovereign one.

---

## What Your nsec Actually Is

When you generated your Nostr keypair, two things were created:

**npub** — your public identity. This is who you are on Nostr. Every note you've ever signed, every follow, every reaction — all of it is cryptographically bound to this identifier. It is permanent. You cannot change it without abandoning your history.

**nsec** — the private key that proves you are the owner of that npub. Anyone who holds your nsec can post as you, follow and unfollow as you, and destroy your reputation as you. It is the master credential for your entire Nostr existence.

These two things are different in kind. The npub is your identity. The nsec is your authority over that identity.

Current practice collapses them into one object, stored in one place, used constantly.

That collapse is the problem.

---

## What Can Go Wrong and Why It's Permanent

A compromised Bitcoin private key means lost funds. That is devastating, but it is bounded — only what was in that wallet is lost.

A compromised Nostr nsec means something different: someone else becomes you. They post as you. They destroy your relationships as you. They impersonate you indefinitely. And because Nostr has no central authority to appeal to, no company to call, no account recovery form — the damage continues until your followers learn to distrust the key.

Most people store their nsec in a browser extension. One compromised device. One malicious extension update. One browser exploit. The key is gone and the damage begins immediately.

The question is not whether this can happen. The question is whether you have prepared for it.

---

## The Four-Layer Framework

The framework separates what should always have been separate. Each layer is built from existing Nostr infrastructure — no new protocol is required. The tools exist. This document organizes them.

---

### Layer 1 — The Cold Root

Generate a new keypair on a device that will never connect to the internet after the generation moment. This can be an old laptop in airplane mode, a dedicated offline device, or an air-gapped Raspberry Pi. The method is less important than the principle: this keypair never touches a network.

This keypair is your true nsec. Store it:
- Written on paper, stored in a physical location you control
- On an encrypted USB drive, stored separately from the paper backup
- Nowhere else

You will use this key approximately twice a year. Once to issue new delegations. Once if you need to signal a key migration.

If you are migrating to this framework from an existing nsec that has ever been on a networked device — generate a new one. Your old key has been exposed. The new cold root should be clean from its first moment.

---

### Layer 2 — The Delegation Ring

This layer uses **NIP-26: Delegated Event Signing**.

NIP-26 allows your cold root to sign a delegation certificate authorizing a different keypair to post on your behalf, within defined limits. The delegation can be:

- **Time-limited**: valid only until a specific Unix timestamp
- **Kind-limited**: valid only for specific event types (notes, reactions, follows, etc.)
- **Independently revocable**: each delegated key can be revoked without touching the master

In practice: generate a separate keypair for each context where you post. One for your phone. One for your desktop. One for any third-party client you use. Each gets a delegation from your cold root.

These are your hot keys. They sign your daily activity. They are not your identity. Your identity is the cold npub they are authorized to represent.

**How to implement NIP-26 today:**

1. Generate a new keypair for signing. This is your delegation key — it can be generated on any device.
2. Using your cold root (offline), create a delegation string in this format:
```
nostr:delegation::kind=1&created_at<1800000000
```
Sign this string with your cold nsec. The resulting signature is the delegation certificate.
3. Include the delegation tag in events signed by the delegation key:
```json
["delegation", "", "", ""]
```
4. Clients that support NIP-26 will display your cold root npub as the author.

Set expiry dates. Renew delegations from your cold root every six months or when a device is compromised. A compromised delegation key is a contained incident — revoke it, generate a new one, continue.

**Current client support note:** NIP-26 support varies across clients. Damus, Amethyst, and most web clients support reading delegated events. If your primary client does not yet support NIP-26 posting, track its development — this is where the framework needs to be built, not redesigned.

---

### Layer 3 — The Recovery Web

This is the layer that has no equivalent in Bitcoin. It is native to Nostr's architecture and almost entirely unused.

Your web of trust — the people who follow you and whose follows you reciprocate — holds a cryptographic history of your activity. They have seen your notes. They have verified your npub. They know what you sound like, what you write about, who you interact with.

This is a recovery mechanism if you prepare it.

**What key migration looks like without preparation:**
Your nsec is compromised. You generate a new keypair. You broadcast from the new key saying "I moved here." Most followers ignore it or distrust it because anyone could broadcast that message. Your social graph does not transfer. You start over.

**What key migration looks like with preparation:**

Before a crisis, identify five to ten people you genuinely trust on Nostr. Contact them through a channel outside Nostr — Signal, email, in person. Tell them: "I am going to share my cold root npub with you privately. If I ever post a signed migration notice from that key pointing to a new signing key, please re-follow the new key and post about the migration. This is my recovery plan."

They do not need to do anything until the day it's needed. They need only to know what to watch for.

When migration is needed:
1. From your cold root (offline), sign a final event from the old signing key pointing to your new key.
2. Broadcast the migration notice.
3. Your trusted contacts attest to the migration from their own keys, independently.
4. Followers who trust those contacts follow the attestations.

The social graph does not transfer instantly or completely. But it transfers — because trust is distributed across your network, not held by any single authority. This is the unique property. A small number of genuine attesting voices is more powerful than any centralized verification system.

**Prepare this layer before you need it.** It costs almost nothing when you are not in crisis. It is worth almost everything when you are.

---

### Layer 4 — The Key Shards

The cold root solves the theft problem. It does not solve the loss problem. A single paper backup in a single location can burn, flood, or be lost.

The solution is **Shamir's Secret Sharing** — a cryptographic method for splitting a secret into N shards, where any K of them (your chosen threshold) can reconstruct the original, but K-1 shards reveal nothing.

In practice: split your cold nsec into five shards with a threshold of three. Distribute the five shards to five people who do not know each other and do not know what they hold. Tell each person only: "I am giving you a fragment of an important backup. Please keep it safe and return it to me if I ask for it. It is meaningless without other fragments."

They hold nothing useful alone. Three of them together can reconstruct your identity. Losing two shards entirely leaves you with recovery intact.

**Tools:**
- `iancoleman/slip39` — SLIP39 implementation, audited
- `dsprenkels/shamir` — simple command-line tool
- `hashwyre/horcrux` — Bitcoin-community Shamir tool, works on any secret string

The procedure:
1. Convert your cold nsec to its raw hex or bech32 string.
2. Run the secret sharing tool with your chosen N and K.
3. Distribute shards physically — print them, hand them to your chosen people.
4. Verify: reconstruct from a test set before distributing. Confirm the output matches your original nsec before trusting this layer.
5. Delete all digital copies of the shards after distribution.

This layer is for catastrophic recovery only — device destruction, death, incapacity. It is the layer that makes the framework durable across time, not just across incidents.

---

## The Full Structure After Implementation

```
Cold Root (Layer 1)
↓ signs delegation certificates
Delegation Ring (Layer 2) — one key per device/context
↓ signs all daily activity
Your Nostr presence — npub is constant, signing keys vary

Separately:
Recovery Web (Layer 3) — five to ten trusted contacts, prepared in advance
Key Shards (Layer 4) — cold nsec split and distributed
```

What changes after implementation:

Your **npub never changes**. Your history is permanent. Your identity is constant.

Your **signing keys can be rotated** without affecting your identity. A compromised phone is a contained incident.

A **compromised cold root** — the worst case — is survivable through Layer 3 if you prepared it, and reconstructible through Layer 4 if the original is lost.

A single failure at any layer does not cascade.

---

## What This Costs

**Time to implement all four layers:** Three to four hours on the first day. Thirty minutes every six months to renew delegations.

**Financial cost:** Zero. All tools are free and open source.

**Social cost of Layer 3:** One conversation with five to ten people you already trust. You are asking them to hold a piece of paper and respond to a message if something goes wrong.

**Technical difficulty:** Layer 2 requires familiarity with how Nostr events are structured. Layer 4 requires running a command-line tool once. Layers 1 and 3 require no technical knowledge beyond key hygiene.

The barrier is not technical. The barrier is that nobody wrote down that this is what sovereignty looks like on Nostr. That is what this document is.

---

## What This Is Not

This is not a product. There is nothing to buy, install, or subscribe to.

This is not a critique of any Nostr client or relay. The existing infrastructure is sufficient.

This is not a complete security audit of every possible threat model. It addresses the primary structural vulnerability — the conflation of identity and signing mechanism — and the primary loss scenarios.

---

## The Minimum

If you implement nothing else: separate your cold root from your signing keys using NIP-26, and tell three trusted contacts your cold npub and what to do if they see a signed migration notice from it.

That alone moves you from the default state — one key, one point of failure, unrecoverable — to a fundamentally different position.

The full framework is better. The minimum is enough to start.

---

## Existing Resources

**NIP-26 specification:** github.com/nostr-protocol/nostr/blob/master/26.md

**NIP-46 (Nostr Connect / nsecBunker):** github.com/nostr-protocol/nostr/blob/master/46.md
*Remote signing — an alternative implementation of the delegation layer for those who prefer server-based signing over per-device delegation keys.*

**Shamir's Secret Sharing tools:**
- SLIP39: github.com/iancoleman/slip39
- Simple CLI: github.com/dsprenkels/sss-cli

**Key generation offline:**
- nak (Nostr Army Knife): github.com/fiatjaf/nak — can be run air-gapped

---

*Sovereign Signal — v1*
*No rights reserved. Share without modification or with it. Build on it.*
*The tools belong to the protocol. The framework belongs to whoever uses it.*

AT Proto ...

2026-08-17T07:21:58Z

In reply to nevent1q…457j
_________________________

AT Proto の方は詳しくないので踏み込みませんが、「こうなると Nostr でアカウントの秘密鍵が漏洩した場合と変わらない」と書かれていた点、まさにそこを Inkan で解決しようとしています。

アイデンティティと署名用キーを分けて、マスターキーはコールドストレージに置いたまま、普段は署名用キーを使います。署名用キーが漏れたり失われたりしても、取り消して新しいキーに委任できます。アイデンティティとフォロワーはそのまま。

quoting
nevent1q…r4gy
The way it usually goes, your online identity is your private key. If the key is compromised, there goes your identity. Inkan fixes that.

You keep a master key in cold storage and a signing key for everyday use. If the signing key ever leaks or gets lost, the master revokes it and delegates to a new one. Same identity, same followers, fresh signing key.

If you'd like to take a look at the prototype: https://www.inkan.cc. Log in with your NIP-07 extension and say hi to the test identities already walking around. Or make one of your own.

It's delegation, but it's quite different from NIP-26. ...

2026-08-17T06:21:47Z

In reply to nevent1q…vw4k
_________________________

It's delegation, but it's quite different from NIP-26.

Here is an explanation of how it works:

quoting
nevent1q…2h4t
A short explainer of the Inkan identity system.

▌ What is Inkan?

Inkan enables online identities whose private key can be created in cold storage and stay there permanently. The key never has to touch an internet-connected device and does not have to be kept close at hand. The identity itself can nonetheless be used easily for everyday online authentication, like posting, replying, messaging, or signing in to services.

▌ How does it work?

Inkan builds on the Nostr protocol which facilitates the distribution of digitally signed content. The idea behind Inkan is that the identity-securing key never has to sign that content itself. It can delegate signing authority to delegatee keys, which handle the everyday signing on its behalf. If a delegatee key is ever lost or stolen, it can be replaced.

▌ Delegations between keys

Delegations are time-indexed two-place relations. Between any two key pairs, at any moment in time, the first key pair either delegates signing authority to the second or it doesn't. When it does, the second key is authorized to sign on the first's behalf. When it doesn't, the second key has no such authority.

Delegations are either direct or indirect. A direct delegation arises when one key has expressly declared that it delegates signing authority to another. An indirect delegation arises because, on Inkan's concept of delegation, the relation is transitively closed: if X delegates to Y and Y delegates to Z, then X also indirectly delegates to Z.

▌ How is a direct delegation created?

A direct delegation from key pair X to key pair Y is created when both key pairs digitally sign a "Declaration of Delegation of Signing Authority" by which X declares that it delegates signing authority to Y, and Y declares that it accepts.

The signed declaration must then be recorded on-chain (Inkan uses Ethereum). The delegation begins at the time of the block in which the declaration was recorded, and remains in effect until it is revoked.

One special case: the above holds only if neither X nor Y has previously permanently invalidated itself. If either has, no delegation relationship is created, even though the declaration sits on-chain. (See "What is permanent key invalidation?" below.)

As part of the delegation declaration, X and Y also specify whether X can revoke the delegation unilaterally, or whether Y's consent is required. The default is unilateral revocation by X. This matters most if Y's private key is ever lost: with unilateral revocation, the user can still revoke using X alone; if Y's consent is required, they cannot (since they no longer have access to Y, and thus can no longer use Y to sign the revocation declaration). For most users, unilateral revocation is recommended for this reason.

▌ How is a direct delegation terminated?

A direct delegation from key pair X to key pair Y is terminated when X digitally signs a "Declaration of Revocation of Signing Authority," by which it revokes the signing authority it had delegated to Y. If the original delegation declaration specified that Y's consent is required for revocation, Y must also sign; otherwise, X's signature alone is enough.

The signed revocation declaration must then be recorded on-chain. If it carries all required signatures, the delegation relationship terminates at the time of the block in which the declaration was recorded.

One final wrinkle: when a delegation declaration and a revocation declaration between the same X and Y land in the same Ethereum block, the revocation is by convention treated as occurring first, and the delegation as occurring thereafter. So from that block on, the delegation is in effect (assuming neither X nor Y has been permanently invalidated). The convention is just a tiebreaker for cases that block timestamps can't order.

▌ What is permanent key invalidation?

The third type of declaration in Inkan is the "Declaration of Permanent Invalidation of a Key Pair." It is signed by the key pair invalidating itself, declaring that, from then on, this key pair can no longer participate in any direct delegation relationship, either as delegator or as delegatee.

Once signed, the invalidation declaration must be recorded on-chain. It takes effect at the time of the block in which it was recorded.

From that point on, all existing direct delegations in which the invalidated key pair was delegator or delegatee are terminated, and no new direct delegations involving it can come into existence, even if a delegation declaration naming it is later recorded on-chain.

The main use is invalidating a compromised master key. Such a key has no delegator, so ordinary revocation isn't available. Permanent invalidation lets the user withdraw it from the Inkan ecosystem entirely.

▌ Delegation timelines

An Inkan-enabled client can read the three types of declarations on the blockchain and, for any given pubkey and any past moment up to the present, compute the direct delegation relationships that the pubkey was involved in at that moment. The indirect ones follow by transitive closure.

So for any pubkey, the client can compile a complete timeline showing every direct and indirect delegation relationship that pubkey has been involved in at any time, up to the present moment.

At www.inkan.cc, registered users can view such timelines for any pubkey that has been involved in delegations and trace them back to the underlying declarations recorded on-chain.

▌ Bitcoin timestamping of Nostr events

Inkan needs an objective, auditable rule for when the act of signing each Nostr event is deemed to have occurred.

To achieve this, Inkan uses OpenTimestamps (OTS) to anchor Nostr events to Bitcoin blocks. An OTS proof for an event establishes that the event and the cryptographic artifact that constitutes its "signature" existed by the time of a specific Bitcoin block.

Inkan then treats an event's 'created_at' field (the signer's self-declared timestamp) as its objective signing time if an OTS proof shows the event and its signature existed shortly after that time. The "shortly after" window is user-configurable (default: four hours). Events without such a proof are treated as if they had no valid digital signature at all, are not displayed by the client, and are not attributed to any delegator.

▌ Attribution of Nostr events

Under this framework, we know, for any past time T and any two keys X and Y, whether X delegated (directly or indirectly) signing authority to Y at T. And for any event that Y has signed, with both a valid cryptographic signature and a valid OTS anchor, we have an objective signing time, i.e. the event's 'created_at'.

Putting this together gives us the necessary ingredients for a well-defined attribution rule: an event E is attributed to key X if and only if some key Y validly signed E at time T and, as of T, X delegated signing authority to Y.

So, for example, a text note signed by a delegatee Y during a valid delegation period from X appears on X's timeline and is displayed there under X's profile as if posted by X, even though X's own key never signed it.

▌ Setting up and managing an Inkan identity

Inkan provides a tool, the "Inkan Management Utility," that automates the creation of the key pairs and the delegations running through them that constitute an identity. The utility can also create key replacements and permanent invalidations. The utility runs without network access and is intended to be used on an amnesic, air-gapped system such as Tails (with networking disabled), so that nothing persists after shutdown and the master key is never exposed to a networked host. The utility is available as a Linux AppImage:
https://www.inkan.cc/settings/inkan-management-utility

Users should set up their identity by building a chain of delegations (master → intermediate(s) → signer) rather than a single master-to-signer delegation. By transitive closure, events signed by the bottom-of-chain signer are attributed to the master. Revocations only require the immediate delegator above the affected signer, so it is not necessary to keep private keys above that immediate delegator close at hand. In particular, the master, once it has signed the chain's initial top-level delegation during the identity's creation ceremony, can stay in cold storage indefinitely.

Generated key pairs can be backed up in encrypted form on USB sticks; multiple copies in separate locations are easy and recommended. Only the current signer key and the delegator immediately above that signer need to be reachable. The rest can be stored in relatively inaccessible locations.

The Ethereum gas fees required for on-chain recording of delegation, revocation and invalidation declarations can be paid by the user directly or by a sponsor. Sponsored payment lets a user create and manage an Inkan identity without holding ETH, and without revealing any private key information to the sponsor.

Setting up an Inkan identity takes some up-front ceremony, but ongoing use does not. The initial work is to create key pairs, sign the declarations that wire the keys into delegation relationships, and record these declarations on-chain. This is a one-time effort and is in large part automated through the management utility. After that, most of the keys can be put away and not be touched again, with only the signing key sitting "hot" on internet-connected devices for everyday signing, and the immediate delegator of the signing key kept close at hand so that it can perform key rotations if the signer is lost or compromised, or preemptively on a periodic basis.

▌ Using the client — two profiles, one identity

When using the Inkan client, you log in with your signer key and sign events with it, just as you would with any other Nostr client. These events appear on the signer's profile page (as in any other client), but in addition they also appear on the profile pages of each of its delegators, including, especially, your top-level identity.

You can set the signer's profile (avatar, banner, display name, etc.) by publishing a kind-0 event as usual. In addition, Inkan includes a mechanism by which the signer can set profiles for its current delegators. This allows your top-level identity to maintain a profile without having to sign any Nostr event itself.

Your identity's profile is what you present yourself with to the world. Others should follow and interact with the identity, not with the signer beneath it. The signer is ephemeral and expected to be replaced sooner or later. The identity is expected to be permanent and is the appropriate object to which followers should attach.

Nostr identity is already being fixed👇 #nevent1q…x5u8

2026-08-17T06:08:13Z

In reply to nevent1q…qht3
_________________________

Nostr identity is already being fixed👇

quoting
nevent1q…x5u8
The way it usually goes, your online identity is your private key. If the key is compromised, there goes your identity. Inkan fixes that.

You keep a master key in cold storage and a signing key for everyday use. If the signing key ever leaks or gets lost, the master revokes it and delegates to a new one. Same identity, same followers, fresh signing key.

If you'd like to take a look at the prototype: https://www.inkan.cc. Log in with your NIP-07 extension and say hi to the test identities already walking around. Or make one of your own.

FYI, what you are asking for exists. Unfortunately mainstream ...

2026-08-17T06:00:52Z

In reply to nevent1q…pzwh
_________________________

FYI, what you are asking for exists. Unfortunately mainstream Nostr developers are actively ignoring it, so there is no adoption and almost no discussion:

quoting
nevent1q…x5u8
The way it usually goes, your online identity is your private key. If the key is compromised, there goes your identity. Inkan fixes that.

You keep a master key in cold storage and a signing key for everyday use. If the signing key ever leaks or gets lost, the master revokes it and delegates to a new one. Same identity, same followers, fresh signing key.

If you'd like to take a look at the prototype: https://www.inkan.cc. Log in with your NIP-07 extension and say hi to the test identities already walking around. Or make one of your own.

Now👇 #nevent1q…x5u8

2026-08-17T05:00:58Z

In reply to nevent1q…c2w0
_________________________

Now👇

quoting
nevent1q…x5u8
The way it usually goes, your online identity is your private key. If the key is compromised, there goes your identity. Inkan fixes that.

You keep a master key in cold storage and a signing key for everyday use. If the signing key ever leaks or gets lost, the master revokes it and delegates to a new one. Same identity, same followers, fresh signing key.

If you'd like to take a look at the prototype: https://www.inkan.cc. Log in with your NIP-07 extension and say hi to the test identities already walking around. Or make one of your own.

Wait, I've been doing delegated signing with Inkan for months ...

2026-08-17T04:50:18Z

In reply to nevent1q…ukmh
_________________________

Wait, I've been doing delegated signing with Inkan for months now. It's entirely practical, and I wouldn't want to use Nostr without it.

Setting up the initial delegations in an airgapped environment takes some ceremony, but once that's done it's really easy to use.

I've also added a"Toy identity" option for people who want to create a quick throw-away identity in their browser, just to try it out.

See below 👇

quoting
nevent1q…x5u8
The way it usually goes, your online identity is your private key. If the key is compromised, there goes your identity. Inkan fixes that.

You keep a master key in cold storage and a signing key for everyday use. If the signing key ever leaks or gets lost, the master revokes it and delegates to a new one. Same identity, same followers, fresh signing key.

If you'd like to take a look at the prototype: https://www.inkan.cc. Log in with your NIP-07 extension and say hi to the test identities already walking around. Or make one of your own.