Nostr notes by

I took a look and decided that I don't want to generate the ...

2026-07-30T08:53:44Z

In reply to nevent1q…ula4
_________________________

I took a look and decided that I don't want to generate the quantum-proof key pairs on a networked machine. It looks like there is an offline path available in principle, but it seems like the key generation functionality is currently a bit entangled with the Nostr event signing functionality.

It would be nice if the key generation could be done airgapped, the unsigned Nostr event then transported to a networked device, and the event then be signed as usual (e.g. with nak or a browser extension).

I was facing a somewhat similar situation with Inkan and started using the following de-networked version of Tails for key pair generation. As a word of caution, this is just a working proof of concept and it has not been audited or anything like that, but it may be useful as a model:

https://gitlab.com/inkan_dev/inkan-offline-live

This is interesting. I think I may want to combine this with the ...

2026-07-30T08:02:02Z

In reply to nevent1q…xdwu
_________________________

This is interesting. I think I may want to combine this with the Inkan key rotation / replacement system, which incidentally also records identity-defining declarations on-chain and provides similar OTS timestamping for all of a user's regular Nostr events.

I guess that, for quantum-proof key pairs to get associated with an Inkan identity, it's enough if the current signer key pair signs the quantum pubkeys. Through delegation, the quantum keys will then be automatically attributed to the master key that secures the Inkan identity, and can then be interpreted as a continuation of that master key.

Let me take a closer look at this, it seems to be a nice fit for getting Inkan identities prepared for a potential post-quantum scenario.

I'm assuming it's a bad movie? I was bored out of my mind ...

2026-07-29T10:15:55Z

In reply to nevent1q…uf3a
_________________________

I'm assuming it's a bad movie? I was bored out of my mind by Oppenheimer.

observers are sceptical ...

2026-07-29T04:55:31Z

In reply to nevent1q…746u
_________________________

observers are sceptical ...

"I understand, but you run into the same issue the moment ...

2026-07-29T03:47:12Z

In reply to nevent1q…s0kd
_________________________

"I understand, but you run into the same issue the moment your master key is compromised."

If you pay attention to the handling of the master key, it's quite unlikely that it will get compromised. You can create it on an airgapped system and then store multiple encrypted copies on, for example, 5 (or more) USB drives. You can store these USB drives in different secure locations, like a bank deposit box, a personal safe, or somewhere in your basement. You don't have to keep the master key close at hand since you will most likely never have to access it again after its creation (replacement of signing keys can be done using intermediary keys in the delegation chain, so you don't need to access the master key to perform signing key rotations).

"... intepertation complexity/demands."

The "interpretation complexity" can mostly be automated away. The Inkan client represents a prototype for how to do this. For the most part, the complexity has to be dealt with by the developer, not the end user. There is some residual complexity that the end user has to handle, mostly relating to the key creation and key replacement ceremonies. Basically, end users must learn to set aside 30 minutes to focus on the steps for key creation and replacement, and to use an airgapped device for that. This will feel like a huge bother and annoyance to people who are not used to it and where there is not yet social proof for the practice. But it is in itself easier to get used to than, say, driving a car, doing long division, or going to the gym.

When people complain about "complexity", one should distinguish "This looks like a headache to implement" from "This will be a headache to use". The first may be true to some extent, but it just reflects developer laziness ("I don't want to have to code this" is not really a convincing argument against a perfectly feasible protocol, and lots of commercially successful software implements far more complex methods). The headache-to-use point isn't actually true and it's being conflated with "I'm currently not accustomed to this and why should I be doing it when noone else is?" Again, I think the main challenge here is to get social proof for the practice and, and once that's been done, people will be less prone to confuse "I'm not currently used to this" with "This is difficult to use."

"... a president or something ..."

Nah, this feels like saying that only the clergy needs to learn how to read, what use could a peasant have for such skills. And this is much easier than reading.

"1: don't believe there will be one scheme that manages universal addoption. ... i deem 1 to be self-explanatory"

This isn't self-explanatory at all, in fact I think it's probably false. The reason it currently *feels* self-explanatory is, I think, again that there is not yet social proof for the practice. It's a bit like saying in the late 1970s that, at some point, there will be a personal computer in every home.

"... all (rigid formal) defenses like this that you implement turn against you and benefit the attacker the moment an attacker succeeds in penetrating them. If the running assumption is 'this master key is truth/my guiding star the moment there is appearent chaos', and that assumption is invalid, you just increased the problem."

I think it's preferable to put up better defenses rather than worse ones, especially if it's easy to do so. I wouldn't say that the master key is a "guiding star." But having a master key that you can expect with some confidence to keep over the long term may incentivize some people to invest more seriously in building online personas with large followings (e.g. 1 million followers) that attach to that key. The key will make these followers portable across the internet. Of course, there is still a risk of loss either due to compromise of the offline master key, or due to flaws in the implementation or in the underlying cryptographic algorithms. But this risk will be smaller than it is with the available alternatives, and that differential may persuade people that investing in an online persona is worth their time.

"If all you can do is extend what is ultimately the same problem ..."

It's not an extension of the same problem. The difference is that you can reasonably have *far* greater confidence in the integrity of a key that has never touched a networked computer. With proper precautions, you can have a very high degree of confidence that the device you used for key creation could not connect to the internet, and that the key you created has therefore not been leaked. You cannot, as a matter of principle, have any comparable amount of confidence that keys which sit "hot" on an internet-connected device have not been leaked. In other words, "ensuring that device X is properly airgapped and cannot connect to the internet" is a very different type of problem than "ensuring that key X, which sits hot on my laptop in a browser extension, doesn't get compromised." You have a great deal of control over the former, and relatively little control over the latter.

"... don't let me discourage you"

Can't be discouraged as long as the underlying math holds up. As long as there's asymmetric public key cryptography + blockchain timestamping, this type of permanent decentralized identity is far too intriguing as something that should be added to the internet's infrastructure. It sort of refocuses thinking about the internet, which is currently still conceptualized as a collection of "websites" on which users rent space and identity from platforms, to a collection of user identities that avail themselves at their own discretion of the communication infrastructure that the internet furnishes to them.

Strongly agree, with one important nuance / correction on this ...

2026-07-28T08:06:40Z

In reply to nevent1q…zqcs
_________________________

Strongly agree, with one important nuance / correction on this part:

"Same thing with the key stuff...do we have "house rotation" for the moment your house burns down?"

I need to point out here that a fully functioning key rotation / replacement scheme for Nostr currently exists. This is not an unsolved problem. It's fully implemented at Inkan and you can use it today. I've been using it for months.

The fact that people aren't looking at it or trying it out doesn't mean it doesn't exist. It exists and it works. See below.

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.

quoting
nevent1q…zyrs
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.

Key rotation has been implemented through Inkan. You can use it ...

2026-07-28T07:42:46Z

In reply to nevent1q…0xks
_________________________

Key rotation has been implemented through Inkan.

You can use it today if you like. See below.

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.

quoting
nevent1q…zyrs
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.

Here is a blockchain-anchored identity that handles key rotation ...

2026-07-28T07:37:13Z

In reply to nevent1q…pngc
_________________________

Here is a blockchain-anchored identity that handles key rotation cleanly:

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.

Apologies for the delay in responding, I'm still digesting ...

2026-07-28T06:49:53Z

In reply to nevent1q…hnnq
_________________________

Apologies for the delay in responding, I'm still digesting this. I may not be technical enough to provide in-depth technical commentary on your device, but I'd definitely be interested in trying it out and getting a closer understanding of it when there's opportunity. As you know, I'm interested in offering an online identity that is secured by 100% airgapped credentials but can nonetheless be used for easy everyday authentication, and a signing device obviously fits into that picture.

As for Inkan, it's actually not EIP-712. There are three "inner" declarations that get signed ("Key X delegates signing authority to key Y", "Key X revokes it from key Y" and "Key X permanently invalidates itself"). Each declaration is signed with a plain secp256k1/ECDSA signature over a hash of the declaration, just a standard signed-message scheme the contract checks with ecrecover. Getting such a declaration recorded on-chain then takes a further normal Ethereum transaction that hands the signed declaration to the contract and pays the gas. So the identity signature and the on-chain-submission signature are distinct layers. There's also a sponsored payment mode, which adds an EIP-7702 transaction on top.

It still seems that the relevant signatures can maybe be handled by your device or something close to it. If you're interested in the details of what Inkan is signing, you could just download the source code of the Inkan Management Utiltiy here: https://www.inkan.cc/settings/inkan-management-utility. If you point your AI at the code, it can explain to you in detail what is getting signed and how.

That does sound pretty comfortable overall. I've never been ...

2026-07-26T07:32:40Z

In reply to nevent1q…3jxm
_________________________

That does sound pretty comfortable overall. I've never been beyond I think the sixth station, maybe I'll try this year.

You picked a hot day. How was the temperature?

2026-07-23T06:38:41Z

In reply to nevent1q…xrvy
_________________________

You picked a hot day. How was the temperature?

I usually walked around shirtless all about Austin, with several ...

2026-07-21T03:54:31Z

In reply to nevent1q…9g68
_________________________

I usually walked around shirtless all about Austin, with several T-shirts in my backpack in case I wanted to go to one of their refrigerator movie theaters.

We're talking about (i) Bitcoin for OTS timestamping of Nostr ...

2026-07-16T08:35:09Z

In reply to nevent1q…emgh
_________________________

We're talking about (i) Bitcoin for OTS timestamping of Nostr events, and (ii) Ethereum for recording declarations of delegation and revocation of signing authority.

Onboarding is indeed the hard part. Not much success so far, including within the Nostr community (which is a bit disappointing).

If you're feeling avant-gardish, there is a "Create a Toy Identity" button on the landing page at https://www.inkan.cc. It's very quick and the instructions at the end of the process include an option to send me the toy identity creation transaction (which does not include any privkeys or secrets) for sponsored payment of the Ethereum gas fees. These one-time gas fees typically run between $0.80 - $1.20 or so, and I'm happy to cover these for people who'd like to try it out.

Also, feel free to ask any questions -- always happy to chat about this.

Nostr event nevent1qqsf4w7g3e6x602mztw8nwuqh4m77my9hhuqpnrhfwzulwq7aawhq2cpz4mhxue69uhhyetvv9unytnfde4kzm3wvd3sygx35c2f3a93msnd7zlv6x37n6y0x40mv99hw85ttvnh6rlen2p2yvuxv9t2

2026-07-12T09:24:38Z

明日と明後日、東京のWebX2026に参加する予定です。
参加される方、ブースを出される方がいれば、ぜひ声をかけてください。

That sounds ambitious if it's meant to be a step in the ...

2026-07-10T06:47:29Z

In reply to nevent1q…xkzc
_________________________

That sounds ambitious if it's meant to be a step in the direction of making deepseek 4 run on your laptop. I've sometimes made ambitious claims myself, so I take care to never be entirely dismissive. Proof is in the pudding I guess.

Yes, pretty much. You get a "master" key that stays ...

2026-07-12T08:02:34Z

In reply to nevent1q…aj0g
_________________________

Yes, pretty much.

You get a "master" key that stays offline in cold storage and never does any day-to-day signing. That's your real identity, and that's what your followers attach to. You also get a separate signing key that you actually post with.

When the master key is first created, it signs a statement delegating signing authority to the signing key. That statement is recorded on a blockchain. After that, any notes signed by the signing key get attributed to the master key by the Inkan client.

If the signing key ever leaks or gets lost, the master key can sign another statement (also recorded on-chain) that revokes the old signing key and re-delegates to a new one. Your identity, i.e. the master key, and the followers attached to it never change. The only thing that changes is the signing key underneath.

It's actually even a bit more powerful than that, since you can create *chains* of delegations from the master key down to the signing key. That means you don't even need the master key for revocations, an intermediary key in the chain can handle them. So after creating it and signing the initial delegation on an airgapped system, you can basically keep the master key in a safe deposit box or buried in your cellar and most likely never touch it again.

For a more detailed explanation, see below.

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.

I suspect it's the same with senior developers. I'd ...

2026-07-10T07:57:48Z

In reply to nevent1q…cyfr
_________________________

I suspect it's the same with senior developers. I'd recommend competing at the senior level.

My main worry about AI is who will own the means of production. ...

2026-07-10T02:31:49Z

My main worry about AI is who will own the means of production.

It's not a bad time to revive that good old Marxian phrase.

Oh, our darling weirdo / mad prophet. I guess my concern is who ...

2026-07-10T04:45:05Z

In reply to nevent1q…m6mt
_________________________

Oh, our darling weirdo / mad prophet. I guess my concern is who will own the physical infrastructure. I gather it's expensive. A high degree of decentralization of control over that would be desirable. As a sort of political / society building project.

Inkan separates your identity from your signing key. If the ...

2026-07-10T02:09:28Z

Inkan separates your identity from your signing key.

If the signing key is leaked or lost, revoke it. Switch to a new one. Same identity. Same followers. New signing key.

The prototype is here:
https://www.inkan.cc

Let me know any questions.

It's a peculiar feature of this system that there is no way ...

2026-07-06T10:31:58Z

In reply to nevent1q…zlvy
_________________________

It's a peculiar feature of this system that there is no way for anyone to ever identify the person who provided the proof that they are over 18.

Presumably you are doing the age verification to provide some service to someone. If you can't ever identify the person who provided the proof that they are over 18, how can you ever confirm that you are providing that service to them and not to someone else?

With regular IDs like a passport, you can always (if you kept a record of the ID) track down the person to whom the ID belongs and investigate whether the service was really provided to them.

Not leaking anything "beyond proof" raises the question ...

2026-07-07T11:15:26Z

In reply to nevent1q…gzx4
_________________________

Not leaking anything "beyond proof" raises the question what's included in the "proof." You're right I should ask a chat bot about this, and that's precisely what I'll do.

I certainly can't trust it right now without knowing a lot ...

2026-07-06T11:01:08Z

In reply to nevent1q…w4ke
_________________________

I certainly can't trust it right now without knowing a lot more about it. In this case, I'm also interested in the conceptual question whether it's in principle possible to build something that allows you to prove that you're over 18 without revealing further info about you, and which is useful in practice. I'm having a hard time getting my mind around it.

Are these tokens issued without giving the EU the ability to know ...

2026-07-06T08:50:33Z

In reply to nevent1q…2e60
_________________________

Are these tokens issued without giving the EU the ability to know where they will be used?

So if I want to buy a cigarette, does the app issue a token proving that I'm over 18 without giving the EU the ability to determine at what tobacco store I'm using it?

I'm scrolling through the Q&As on the website you linked to, and am not yet seeing the answer.

So these attempts by governments to introduce online age ...

2026-07-06T07:47:37Z

So these attempts by governments to introduce online age verification requirements, are these going to use zero knowledge proofs?

Are they trying to sell this by floating the idea that you can prove your age while still remaining "anonymous" in some sense or another?

From what I'm reading, it seems that zk proofs won't really work to achieve this in any truly meaningful way. See for example this for a critique:

https://brave.com/blog/zkp-age-verification-limits/

Does anybody have any insights into what's going on here?

So these attempts by governments to introduce online age ...

2026-07-06T07:43:11Z

In reply to nevent1q…alxp
_________________________

So these attempts by governments to introduce online age verification requirements, are these going to use zk proofs?

Are they trying to sell this by floating the idea that you can prove your age while still remaining "anonymous" in some sense or another?

From what I'm reading, it seems that zk proofs won't really work to achieve this in any truly meaningful way. See for example this for a critique:

https://brave.com/blog/zkp-age-verification-limits/

Does anybody have any insights into what's going on here?

Inkan separates your identity from your signing key. If the ...

2026-07-06T07:18:01Z

I'm here because of the cryptographic properties of the ...

2026-07-06T06:50:00Z

In reply to nevent1q…4qyr
_________________________

I'm here because of the cryptographic properties of the protocol. I'll keep using it until the underlying mathematical relations change.

Inkan separates your identity from your signing key. If the ...

2026-07-05T04:20:47Z

Hello!

2026-07-04T09:32:13Z

In reply to nevent1q…snwz
_________________________

Hello!

Inkan separates your identity from your signing key. If the ...

2026-07-04T05:37:51Z

Inkan separates your identity from your signing key.

If the signing key is leaked or lost, revoke it. Switch to a new one. Same identity. Same followers. New signing key.

(Let me know any questions.)

Also yes, relays are needed. It's a protocol that facilitates ...

2026-07-03T06:34:35Z

In reply to nevent1q…d77n
_________________________

Also yes, relays are needed. It's a protocol that facilitates the dissemination and discovery of digitally signed (and OTS-dated?!) content.

It actually spells naostbr.

2026-07-03T05:20:17Z

In reply to nevent1q…d77n
_________________________

It actually spells naostbr.

Agree that NIP-1 is the thing. It's really just about using ...

2026-07-03T04:44:50Z

In reply to nevent1q…9wwl
_________________________

Agree that NIP-1 is the thing. It's really just about using public key cryptography directly for authentication. I wish they wouldn't call it "Nostr."

It's more important than ever to spread the word that one can ...

2026-07-02T06:45:07Z

In reply to nevent1q…ndvx
_________________________

It's more important than ever to spread the word that one can use public key cryptography to authenticate on the internet.

You can even have online identities whose keys are kept in cold storage. I've implemented a prototype for this at https://www.inkan.cc

For people who are concerned with this kind of legislation, I'd very much recommend taking a close look. It's very timely.

Nostr event nevent1qqs8876c9gud04ywx70rmmd87vgga0eektccan3a86pc0jxt85kxrhcpz4mhxue69uhhyetvv9unytnfde4kzm3wvd3sygx35c2f3a93msnd7zlv6x37n6y0x40mv99hw85ttvnh6rlen2p2yvnt2l59

2026-07-02T05:58:14Z

Inkanでは、アイデンティティと署名用キーを分けて扱えます。

署名用キーが漏れたり失われたりしても、そのキーを取り消して、新しいキーに切り替えられます。
アイデンティティとフォロワーはそのまま。

よろしければ、プロトタイプを少し覗いてみてください。
https://www.inkan.cc/

（質問があれば、ここで声をかけてください。）

That's not good. Thanks for your client by the way. It's ...

2026-06-30T03:37:09Z

In reply to nevent1q…adce
_________________________

That's not good.

Thanks for your client by the way. It's excellent. I'm using it as the base for Inkan.

Huh. Is there a possibility that this is country specific?

2026-06-30T03:22:16Z

In reply to nevent1q…m8qt
_________________________

Huh. Is there a possibility that this is country specific?

Nostr event nevent1qqsyq0vpgcrz3jagftkcsc2vqc852sz5zk54qlzjalgruvr94f72c9gpz4mhxue69uhhyetvv9unytnfde4kzm3wvd3sygx35c2f3a93msnd7zlv6x37n6y0x40mv99hw85ttvnh6rlen2p2yvj6275z

2026-06-30T03:05:25Z

InkanにNIP-46対応を追加しました。
Amberで試したところ、ちゃんと動いているみたいです。

これで、リモート署名を使いつつ、署名用キーが漏れたり失われたりした場合でも、新しいキーに切り替えられるようになります。
アイデンティティとフォロワーはそのまま。

Just realized that I can use NIP-7 with Firefox on my cell phone. ...

2026-06-30T02:38:08Z

Just realized that I can use NIP-7 with Firefox on my cell phone. I had no idea.

The second variant reports a feature, not a bug, as they say.

2026-06-30T02:34:30Z

In reply to nevent1q…0evz
_________________________

The second variant reports a feature, not a bug, as they say.

They must offer something distinctive.

2026-06-29T07:15:09Z

In reply to nevent1q…chkq
_________________________

They must offer something distinctive.

The fun is being able to sell that thing, not just anything.

2026-06-29T07:05:47Z

In reply to nevent1q…9dv5
_________________________

The fun is being able to sell *that* thing, not just anything.

I made a bootable live USB image that has the Inkan Management ...

2026-06-29T03:22:04Z

I made a bootable live USB image that has the Inkan Management Utility pre-installed. This is meant to provide an airgapped environment for signing delegations and revocations of signing authority between key pairs, and for identity creation.

The OS is expected to be amnesic across reboots and networking is disabled. I added QR codes to conveniently transfer keys and signed declarations to an online system. You can also configure persistent storage to keep the keys that secure your identity right on that USB.

https://gitlab.com/inkan_dev/inkan-offline-live

I still look at NIPs for ideas, but I'm not overly concerned ...

2026-06-29T02:45:18Z

In reply to nevent1q…8x56
_________________________

I still look at NIPs for ideas, but I'm not overly concerned about conforming to them when it's not convenient. If I did I wouldn't get much work done. I do try to engage in protocol discussions but the experts are mostly not very responsive, which leaves one without proof that there is actual expertise there. If one community moves too slowly, I guess it may be better to divide one's time and talk to a different one, or just to focus on the product.

What makes vicious characters interesting is maybe the virtuous ...

2026-06-27T09:21:38Z

In reply to nevent1q…kql6
_________________________

What makes vicious characters interesting is maybe the virtuous characteristics they need to have to be effective in the pursuit of their vices. Or maybe it's considering why their vicious goals seem good and worthy of pursuit to them.

Makes sense, still feels meaningful. Thanks for this service by ...

2026-06-27T08:39:03Z

In reply to nevent1q…p08e
_________________________

Makes sense, still feels meaningful. Thanks for this service by the way, which I gather you're providing.

Then that's pretty meaningful and good news.

2026-06-27T08:27:00Z

In reply to nevent1q…xy2f
_________________________

Then that's pretty meaningful and good news.

Nostr event nevent1qqsqedu39gdaplum6c72nwnat6rjd36xd3mynxqp50umsuxav55qllspz4mhxue69uhhyetvv9unytnfde4kzm3wvd3sygx35c2f3a93msnd7zlv6x37n6y0x40mv99hw85ttvnh6rlen2p2yvjyymg7

2026-06-27T06:53:40Z

WebXというカンファレンスも13日から１４日まで開催されるみたい。これはBlockchain Weekの一部なのかな？それとも別イベント？

https://webx-asia.com/ja/

quoting
nevent1q…gu47
Japan Blockchain Weekのサイト、上の方には「７月１日〜７月１５日」と書いてあるけど、下の方には「Kickoff Eventは７月１２日に開催される」と書いてある。スケジュールページを見ても、今のところ７月１２日分しかない。「July 1」は「July 12」のtypo? 行きたいんだけど、いつ行けばいいのかよく分からない。

https://japanblockchainweek.jp/

Nostr event nevent1qqsfndl26p5uzsjsug2483snslpcxzhzzrmx306f272azautwfypp4gpz4mhxue69uhhyetvv9unytnfde4kzm3wvd3sygx35c2f3a93msnd7zlv6x37n6y0x40mv99hw85ttvnh6rlen2p2yvjrql50

2026-06-27T03:21:11Z

日本に着きました。みんなさん、こんにちは。