Nostr notes by inkan

Also talked to my LLM, and I think the issue with rootstock ...

2026-10-14T08:56:43Z

In reply to nevent1q…n5pc
_________________________

Also talked to my LLM, and I think the issue with rootstock "confirmations" is that they consist of merge-mined work which is produced by bitcoin miners at zero marginal cost. So there is little that bitcoin miners would lose if they attacked rootstock. And the preventive measures you mention seem to be about detection and halting the chain, but that would give attackers the ability to, well, halt the chain, at no marginal cost to them. And then there would have to be social recovery.

For inkan, the worst thing that could happen is not for RBTC to become unpegged from BTC. It's rather that rootstock gets reorganized, which could rewrite the delegation / revocation history, which would be catastrophic for inkan identities. The integrity of the history is precisely what inkan depends on.

This is forcing me to learn about things like side chains and ...

2026-10-14T07:52:09Z

In reply to nevent1q…6q3j
_________________________

This is forcing me to learn about things like side chains and pegs. So from talking with an LLM, it seems like the custodial problem with rootstock is "pegging out," i.e. releasing escrowed BTC when RBTC is getting redeemed. Bitcoin cannot know mechanically when RBTC gets redeemed, so there has to be a federation of entities that are trusted to correctly operate PowHSMs which co-sign the bitcoin transactions that release escrowed BTC. And these are held out to be "respected companies" but their "identities are not public," which raises the question what basis there is for the respect. And then there is still the other issue, i.e. that it's not clear what exactly would stop bitcoin miners from reorging rootstock. The miners get paid in BTC no matter what happens to rootstock, so beyond the small fee incentive they get for participating there doesn't seem to be anything they'd lose by attacking rootstock. At least at first glance, it doesn't necessarily seem more robust than Ethereum.

I haven't used anything FROST-based, but I think I would if I ...

2026-10-13T23:14:29Z

In reply to nevent1q…5gls
_________________________

I haven't used anything FROST-based, but I think I would if I could do it in a way that seems more secure than regular NIP-46, and convenient to use.

For it to be more secure than regular NIP-46, I would want to require all shards for signing and keep exclusive control over at least one shard myself. If there isn't anything in the cryptography underlying FROST which makes it inherently less secure than using an unsharded key, it seems that this way of using it would be at least as secure as regular NIP-46.

And then on the convenience side, the actual signing would ideally be controlled through an app that sits on my phone and feels generally like Amber, and that app should probably hold one of the shards over which I have exclusive control.

I've only taken a cursory glance at FROST, but if there is something that provides this kind of experience or something equivalent, I think I'd try it.

Huh, so it's starting to sound like inkan would likely run on ...

2026-10-13T17:38:26Z

In reply to nevent1q…d3yj
_________________________

Huh, so it's starting to sound like inkan would likely run on rootstock. One question then is whether that would be advantageous as compared to ethereum. I need to better understand what merge mining is. It seems like rootstock gets a lot of hashrate from it but it's not clear if the miners have anything really at stake there, i.e. it seems like a large pool could reorg rootstock without losing anything? I'm not sure if it protects against reorgs in the way in which Ethereum finality does. Also, rootstock seems like the more exotic product and it seems to have fewer endpoints, so it might be less suitable for broader adoption than something based on ethereum maybe. But I first need to do more reading to really understand how it works.

thanks, let me know any questions any time.

2026-10-13T16:38:31Z

In reply to nevent1q…kr6k
_________________________

thanks, let me know any questions any time.

That's true in a way, but making something that actually ...

2026-10-13T13:18:52Z

In reply to nevent1q…g4h4
_________________________

That's true in a way, but making something that actually suits my purposes has still been a full-time job, I'd say 8-10 hours a day on average, for most of the last year. It's interesting that it should be like that.

"Your whole identity is ONE private key. No rotation. No ...

2026-10-13T12:59:05Z

In reply to nevent1q…z38n
_________________________

"Your whole identity is ONE private key. No rotation. No recovery. Paste your nsec into one sketchy web client and it's gone forever. Your only option is "hey guys new npub pls refollow""

Seems like this got overlooked 👇

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

See?

2026-10-13T12:37:55Z

In reply to nevent1q…85lk
_________________________

See?

I've been asked about this and spent some time thinking about ...

2026-10-13T12:18:23Z

In reply to nevent1q…4tn5
_________________________

I've been asked about this and spent some time thinking about it, and I don't have a conclusive answer.

Where it gets difficult is the revocations. Clients need to know if a delegation is still alive at any given moment, and for that they need to be sure that they haven't overlooked a revocation declaration somewhere. So it's not enough that declarations be written somewhere durable, the client needs to be able to assemble the entire set of declarations for a given key and needs to know that it's complete. That completeness property is available on Ethereum, but I think Bitcoin script is attached to single outputs and doesn't accumulate state across transactions. So you could write declarations into the Bitcoin chain in some agreed format, but then anyone wanting the full picture needs to scan the whole chain with a full node and otherwise they can't tell whether a revocation is being withheld from them. I'm not an expert on this, but that's my current understanding.

It seems like rootstock may be different again though if it's a full EVM. But the thing is I'd never heard of rootstock before this came up, and I suspect most people outside bitcoin haven't either. Ethereum is at least something normal people may have vaguely heard of. So it's not obvious to me that swapping in rootstock or bitcoin scripts helps adoption overall, as opposed to just helping with this particular audience, which may be acting on niche preferences that don't have strong technical justifications. Don't get me wrong, though, I'd love to have this conversation with the current nostr community and the bitcoin crowd, and there may be actual technical advantages with using bitcoin that I'm not aware of.

There's been some previous threads relating to this, and also don't forget to actually try it out, otherwise it just ends up being just these abstract discussions 👇

quoting
nevent1q…yzpx

Not an expert, but it seems like this may make delegation and revocation declarations storable and discoverable on BTC, but it may be difficult to be sure that one has retrieved all such declarations unless one runs a full node. I haven't done any in-depth analysis, but it feels like that may be the problem with BTC.

quoting
nevent1q…x3pj

"store the revocations with a guarantee of availability"

That requires a blockchain, though? The agreement on the timestamp is kind of what a blockchain *is*.

quoting
nevent1q…c3qh
Absolutely, for recording key delegation, revocation and invalidation declarations.

I wasn't able to figure out an easy way to record these declarations on Bitcoin, but admittedly I didn't try all that hard.

The Nostr events themselves are timestamped with OTS on Bitcoin.

Actually you can simply keep using your current nostr keypair and ...

2026-10-12T20:39:57Z

In reply to nevent1q…g5r4
_________________________

Actually you can simply keep using your current nostr keypair and make it the signer for a cold storage identity, this just came up in another conversation 👇

quoting
nevent1q…hmyc
Sorry I've been sleeping through this discussion.

So it's like you say, you don't have to abandon your current npub if you don't want to. You can create a new master key and delegate down from it, through a delegation chain, to the npub you already use on nostr.

You then keep posting with your current npub exactly as before. After the delegation this npub doubles as your inkan signing key, so everything you create with it from then on gets attributed to the new master key. If your current npub is ever compromised, the master key can then revoke it and delegate to a new one. The identity attached to the master key survives the compromise.

Full disclosure, this construction needs to be done with the Inkan Management Utility (https://www.inkan.cc/settings/inkan-management-utility), and it takes a bit more care than just creating a completely new identity from scratch. You basically prepare a small text file with your current private key in hex and feed it to the utility, and ideally you do all of this on an airgapped system, since you're handling private key material. If you want to try it, let me know and I'm happy to write up the exact steps, including the format that's required for the input file.

And if you'd first just like to get a better idea of how inkan works before connecting it to your current npub, you can create a throwaway toy identity on inkan's homepage. Recording it on Ethereum costs a small gas fee, and the wizard has a menu where you can ask me to sponsor that tiny amount, which I'm usually happy to do for people who don't hold any Ether (and seem reasonably good-natured, at least as far as posting to the inkan relay goes). Creating one happens right in the browser and takes about five minutes, and the result is the same cryptographic object the Management Utility would produce, just made in an insecure location rather than on an airgapped machine.

When use of an EVM provides a solution to the key management ...

2026-10-12T19:32:15Z

In reply to nevent1q…c8jz
_________________________

When use of an EVM provides a solution to the key management problem, which is a central problem for the nostr protocol, wouldn't it make sense to simply use that solution rather than continue sitting on the problem?

And there is also the idea that nostr was supposed to have broader appeal beyond the Bitcoin community. Leaving problems with the protocol unaddressed because a working solution doesn't fit the tastes of the Bitcoin community doesn't seem like a good strategy to achieve broader adoption.

That seems right, I also just responded with the same reference ...

2026-10-12T19:08:51Z

In reply to nevent1q…mady
_________________________

That seems right, I also just responded with the same reference to the NIP draft.

You need a blockchain with certain completeness properties. ...

2026-10-12T19:07:26Z

In reply to nevent1q…7u3u
_________________________

You need a blockchain with certain completeness properties. It's just a technical requirement, not some partiality towards Ethereum in particular.

The gas fees required for an identity creation are tiny, I think it was maybe $0.20 or so the last time I did it.

I'm happy to take care of the tiny gas payment if you don't hold Ether. There's an option at the end of the toy identity wizard to send me the transaction file that was created and I can record it on-chain.

FYI, the technical specs (which among other things explain why a blockchain is needed) are here 👇

quoting
naddr1qv…vwq8

NIP Proposal

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 (§12).

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 (§12).

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. Disavowal

When making a delegation declaration, the delegator may declare an avowal start time and an avowal end time. When making a revocation declaration, the revoker may declare a disavowal start time and a disavowal end time. A start time of zero is interpreted as the time at which the declaration was recorded on-chain; an end time of zero means unbounded.

For keys X and Y, take the latest delegation or revocation declaration between them recorded before any permanent invalidation of either (§5). If it is a delegation declaration, X avows Y's actions at exactly the times T inside its avowal window; if a revocation declaration, at exactly the times T outside its disavowal window; provided, in both cases, that X directly delegated to Y at T. Y's actions at T are the events Y validly signed with objective signing time T (§7).

Avowal composes along delegation paths: X currently avows S's actions at T if the relevant declaration between X and S avows them directly, or if, for some key Y, X avows Y's actions at T, X avows Y's actions at the present moment, and Y currently avows S's actions at T.

Clients can filter events whose signing the identity currently disavows out of the identity's timeline, or display them with a disavowal badge.

11. Re-ratification

A disavowed window covers everything the disavowed key signed within it, including events whose signing was caused by the identity's legitimate owner. The identity can in that situation make a kind 31066 re-ratification declaration as described in §12.3 below, specifying the events it re-ratifies in the e tags of that declaration. If the declaration is valid and effective, a client treats these events as re-ratified, until a disavowal recorded after the declaration's anchoring block prevails over it (§12.3) or a later declaration governs in its place.

12. Event kinds

This NIP defines three 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

31066 Re-ratification the re-ratifying pubkey an avowed key

12.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.

Tag Required Meaning

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)>"
}
12.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.

Tag Required Meaning

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.

12.3 Kind 31066: Re-ratification declaration

A 31066 event can be used by key A to re-ratify an event signed by key B with objective signing time T (§7), where A currently disavows actions taken by B at T (§10). The d tag contains the re-ratifying pubkey and each e tag is the id of a re-ratified event. The re-ratification is valid only if the 31066 event is signed by a key whose actions the re-ratifying key currently avows (which includes the re-ratifying key itself), and only if no e tag contains the declaration's own event id. The 31066 event must be submitted for Bitcoin timestamping and is effective starting from the time of the block in which its proof is anchored. If there are multiple valid and effective 31066 events with the same re-ratifying pubkey in their d tag, the one with the latest created_at governs. A re-ratification overrides only disavowals recorded on-chain before the time of its anchoring block; a disavowal recorded after that time prevails over the re-ratification.

Tag Required Meaning

d yes The re-ratifying pubkey.

e yes, repeated Id of a re-ratified event, one tag per id.

alt yes Re-ratification declaration
{
  "kind": 31066,
  "pubkey": "<signing-key>",
  "tags": [
    ["d", "<re-ratifying-pubkey>"],
    ["e", "<re-ratified-event-id>"],
    ["e", "<re-ratified-event-id>"],
    ["alt", "Re-ratification declaration"]
  ],
  "content": ""
}
13. 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, permanent invalidation, avowal, and disavowal 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.

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
`31066`	Re-ratification	the re-ratifying pubkey	an avowed key

Tag	Required	Meaning
`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`.

Tag	Required	Meaning
`d`	yes	The subject: the delegator's pubkey.
`alt`	yes	The exact string `Attributed profile`.

Tag	Required	Meaning
`d`	yes	The re-ratifying pubkey.
`e`	yes, repeated	Id of a re-ratified event, one tag per id.
`alt`	yes	`Re-ratification declaration`

You can keep using your current npub and delegate down to it. For ...

2026-10-12T18:54:18Z

In reply to nevent1q…rexy
_________________________

You can keep using your current npub and delegate down to it.

For example, the npub I'm using right now does double duty as the signer key for a cold storage identity. The profile page of that identity is here:

https://www.inkan.cc/users/npub10ukg94kvrvk4qqr3482zdekfsuaw2x56wa899mnpkxqwfxl6dlkqrux0x9

People who are currently following the signer key can continue to do so for as long as they like, although I'd hope that they'll eventually get around to directly following the identity key (since the identity key will survive if / when the signer key gets compromised).

Sorry I've been sleeping through this discussion. So it's ...

2026-10-12T18:44:37Z

In reply to nevent1q…5q56
_________________________

Sorry I've been sleeping through this discussion.

So it's like you say, you don't have to abandon your current npub if you don't want to. You can create a new master key and delegate down from it, through a delegation chain, to the npub you already use on nostr.

You then keep posting with your current npub exactly as before. After the delegation this npub doubles as your inkan signing key, so everything you create with it from then on gets attributed to the new master key. If your current npub is ever compromised, the master key can then revoke it and delegate to a new one. The identity attached to the master key survives the compromise.

Full disclosure, this construction needs to be done with the Inkan Management Utility (https://www.inkan.cc/settings/inkan-management-utility), and it takes a bit more care than just creating a completely new identity from scratch. You basically prepare a small text file with your current private key in hex and feed it to the utility, and ideally you do all of this on an airgapped system, since you're handling private key material. If you want to try it, let me know and I'm happy to write up the exact steps, including the format that's required for the input file.

And if you'd first just like to get a better idea of how inkan works before connecting it to your current npub, you can create a throwaway toy identity on inkan's homepage. Recording it on Ethereum costs a small gas fee, and the wizard has a menu where you can ask me to sponsor that tiny amount, which I'm usually happy to do for people who don't hold any Ether (and seem reasonably good-natured, at least as far as posting to the inkan relay goes). Creating one happens right in the browser and takes about five minutes, and the result is the same cryptographic object the Management Utility would produce, just made in an insecure location rather than on an airgapped machine.

The other thingy is fun as well.

2026-10-12T14:56:55Z

In reply to nevent1q…ltnc
_________________________

The other thingy is fun as well.

Following up on this one, with inkan "verify" isn't ...

2026-10-12T06:08:39Z

In reply to nevent1q…2j69
_________________________

Following up on this one, with inkan "verify" isn't just a slogan.

Every OTS-stamped event on inkan.cc comes with a download button for the raw .ots proof, together with a report that tells you exactly how to reproduce the hash the proof commits to:

leaf = SHA-256( id_bytes || sig_bytes )

It takes one line of shell to recompute it from the event's id and sig, then feed the .ots to any OpenTimestamps verifier, the CLI, the web one, whichever you like. Nothing from inkan is in the loop. It either resolves to a Bitcoin block header or it doesn't.

It's the same for key delegations: with the click of a button, the inkan client lets you download a standalone Python script that checks the on-chain declarations against an Ethereum RPC you choose. It recovers every ECDSA signature locally, checks the contract binding, flags nonce replays. You can read it top to bottom, no inkan server involved.

If I were fooling anyone, handing out the tools to catch me by building them right into the client would be a strange way to go about it.

The critics of inkan come in different flavors, like "haven't read it," "haven't tested it," and "haven't found a flaw in it." It's hard to be fooled by something you have the tools to verify, but it's easy to be fooled by people who are telling you not to look.

You should already be whitelisted on the timestamp server, as ...

2026-10-11T19:58:11Z

In reply to nevent1q…3p3x
_________________________

You should already be whitelisted on the timestamp server, as well as on the relay.

You can check your status at "Settings > Inkan Settings > Service Access". It should show that you have access everywhere, if not let me know.

pubkeys that have recently applied for AI search should have ...

2026-10-11T19:41:49Z

pubkeys that have recently applied for AI search should have access now 🧞‍♀

The concept is not going away for as long as there is asymmetric ...

2026-10-11T19:05:21Z

In reply to nevent1q…utcd
_________________________

The concept is not going away for as long as there is asymmetric cryptography.🤷‍♂

Don't trust, verify.

2026-10-11T18:34:21Z

In reply to nevent1q…sssh
_________________________

Don't trust, verify.

I bet you can get all sorts of descriptions out of it if you just ...

2026-10-11T18:21:39Z

In reply to nevent1q…4wru
_________________________

I bet you can get all sorts of descriptions out of it if you just tweak the prompt. It's available under "Assay" in the nav bar at https://www.inkan.cc. If you'd like to try it out it first asks you to sign the Terms, once I have these I'm happy to switch it on for your pubkey.

this is kind of relevant broadly speaking, for the nostr case ...

2026-10-11T17:53:52Z

In reply to nevent1q…8cz9
_________________________

this is kind of relevant broadly speaking, for the nostr case 👇

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

Huh, I guess it's an opportunity to post yet another a link ...

2026-10-11T17:49:05Z

In reply to nevent1q…qaz9
_________________________

Huh, I guess it's an opportunity to post yet another a link to inkan, which I'll do in a minute. 🤔

As a reminder, there's a standing invitation to make a toy identity directly in the browser on the homepage at https://www.inkan.cc. Useful if you'd like to try it out without going through the steps of making a true airgapped identity.

And even if you don't make your own identity, you can still use https://www.inkan.cc to interact with existing cold storage identities. You can find some of them by clicking on the Explore tab.

https://www.inkan.cc is a jumble fork that's pretty nice to ...

2026-10-11T16:17:32Z

In reply to nevent1q…rcnn
_________________________

https://www.inkan.cc is a jumble fork that's pretty nice to use.

It supports cold storage identities, if you ever want one of those.

And you can search the nostr network with the new AI Search feature. That's actually how I found your note that I'm replying to right now. I asked it what Laeserin had been up to, and here is what it came back with. 👇

Once you get used to managing your regular key pair, you may at ...

2026-10-11T15:03:51Z

In reply to nevent1q…wp89
_________________________

Once you get used to managing your regular key pair, you may at some point become interested in replaceable keys, i.e. keys that you you can revoke if they are ever lost or stolen and replace with new ones.

I implemented a system for doing this at https://www.inkan.cc. Other nostr users tell me that the system is too complicated, especially for people who are just getting started with nostr. I don't really think so, but I guess it depends on one's preferences. In any event, I wanted to let you know that there's a way of doing this if you are, or ever become, interested. See below for a bit more info and some screenshots. 👇

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

Wow.

2026-10-05T00:53:22Z

In reply to nevent1q…vhh9
_________________________

Wow.

Thanks, I'll take a look at their repo to see how they are ...

2026-10-04T22:40:31Z

In reply to nevent1q…tkud
_________________________

Thanks, I'll take a look at their repo to see how they are doing it. What I was thinking was to let the AI search page talk to any server that speaks the standard chat API. You'd run a local gateway with your provider key in its config, and paste its localhost address into a field on the search page, or something like that.

I hadn't heard of buzz. It's really interesting to me as it seems to be about AI agent identity. This is something I've thinking a lot about in connection with inkan, because inkan provides the ability not just to give AI agents identity, but also to make it durable, and to make AI identities accountable to identities of human principals.

I asked my AI search whether buzz has a nostr handle, but other than a bot nothing came up ...

For the AI search, I could try to add a "connect your own ...

2026-10-04T16:39:13Z

For the AI search, I could try to add a "connect your own model" feature.

The idea would be that you run a local gateway (e.g. LiteLLM) on your laptop with your own model provider account behind it , like DeepSeek or Anthropic or whatever. The AI search page then talks to that instead of the AI that inkan is using.

Should I add such a feature? Would anyone want to use it?

quoting
nevent1q…ehda
AI Search for Nostr has been live for a day now. 🧞‍♀

Here's the kind of thing it comes back with, more details below the screenshots 👇

nevent1q…rlrz

I saw Disclosure Day. It was a throwback to the days when people ...

2026-10-04T15:57:43Z

I saw Disclosure Day. It was a throwback to the days when people still knew how to make movies, although among those competent ones this would not have been an especially good one. The ending sequences brought me to brink of tears, which was however not a genuine emotion but more of a physical reaction to the particular combination and sequencing of images and voices and music, sort of like a vasovagal reflex, or the mental state you get into when you sit in front of a slot machine with all the blinking lights, or I guess a horror movie jump scare. There was a very clean separation between that physical reaction I was experiencing and the consciousness of being manipulated. Not unpleasant but also somewhat annoying. In any event, it's nice to encounter something of good workmanship even though it may ultimately not be very remarkable.

"meeting analogically" is a great phrase, I'll ...

2026-10-04T07:35:08Z

In reply to nevent1q…wedn
_________________________

"meeting analogically" is a great phrase, I'll remember that.🙂

It's been almost a month since this discussion, so here's ...

2026-10-04T02:48:56Z

In reply to nevent1q…hf8j
_________________________

It's been almost a month since this discussion, so here's a quick reminder that Nostr already has a working key rotation / replacement system.

You can go to https://www.inkan.cc and click on "Explore" to interact with some cold storage identities that have never signed a single Nostr event.

You can also create a throwaway "toy identity" on the homepage if you want to try it out yourself. If you don't mind going through the steps, you can even make a full-fledged airgapped identity with the Management Utility.

By the way, I'm still trying to get the word out on this key ...

2026-10-03T04:03:58Z

In reply to nevent1q…vw4k
_________________________

By the way, I'm still trying to get the word out on this key rotation system.

If you go to the "Explore" menu at https://www.inkan.cc, you can interact with cold storage identities that have never themselves signed a single Nostr event but that are nonetheless doing posts every day. If you like, you can also make your own toy identity on the homepage.

I realize there's a strong presumption among the Nostr community that this kind of thing doesn't work. But as a matter of fact it works quite well. I've been using it for many months now.

This also plugs into the recent discussion that we should adopt good practices while the Nostr community is still small. And in any event, it doesn't break anything in the current protocol, it just sits on top of it.

AI Search for Nostr is a pretty good UX experience I think. I ...

2026-10-03T03:31:50Z

In reply to nevent1q…q5rn
_________________________

AI Search for Nostr is a pretty good UX experience I think. I just made it this week and am already pretty hooked on it. 👇

quoting
nevent1q…jsrr
AI Search for Nostr has been live for a day now. 🧞‍♀

Here's the kind of thing it comes back with, more details below the screenshots 👇

nevent1q…rlrz

"Your nsec is still your identity" FYI, here is a system ...

2026-10-03T03:14:37Z

In reply to nevent1q…da4l
_________________________

"Your nsec is still your identity"

FYI, here is a system where your nsec is no longer your identity. If you go to the Explore page at https://www.inkan.cc, you can interact with Nostr identities that have never signed a Nostr event themselves. You can also create your own toy identity on the homepage.👇

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

So there's this nostr paradox, why would a community obsessed ...

2026-09-21T05:49:20Z

So there's this nostr paradox, why would a community obsessed with crypto and key security refuse to even test working key rotation?

Because you can't tell working from broken without spending your own time on it.

After enough broken NIPs and abandoned apps, you learn to price every new thing as a lemon and assume broken. The good leaves the market with the bad. 👇

https://en.wikipedia.org/wiki/The_Market_for_Lemons

Nostr notes by inkan

Also talked to my LLM, and I think the issue with rootstock ...

This is forcing me to learn about things like side chains and ...

I haven't used anything FROST-based, but I think I would if I ...

Huh, so it's starting to sound like inkan would likely run on ...

thanks, let me know any questions any time.

That's true in a way, but making something that actually ...

"Your whole identity is ONE private key. No rotation. No ...

See?

I've been asked about this and spent some time thinking about ...

Actually you can simply keep using your current nostr keypair and ...

When use of an EVM provides a solution to the key management ...

That seems right, I also just responded with the same reference ...

You need a blockchain with certain completeness properties. ...

NIP Proposal

1. How it works

2. Delegations between keys

3. How a direct delegation is created

4. How a direct delegation is terminated

5. Permanent key invalidation

6. Delegation timelines

7. Bitcoin timestamping of events

8. Attribution of events

9. Two profiles, one identity

10. Disavowal

11. Re-ratification

12. Event kinds

12.1 Kind 31045: Bitcoin timestamp

12.2 Kind 31065: Attributed profile

12.3 Kind 31066: Re-ratification declaration

13. Reference implementation