Nostr notes by inkan

I agree we should probably let it rest for now, but as for the ...

2026-10-25T18:21:16Z

In reply to nevent1q…plpm
_________________________

I agree we should probably let it rest for now, but as for the merge miners being invested in the security of rootstock, it seems like they don't have to lose all that much if something goes awry with rootstock as they don't incur any real marginal cost from mining it and the payments they get are I believe also not all that significant. In any event, this has been an interesting discussion and it's entirely possible that my views on this will change as I learn more about it.

If RBTC traded at 50 cents while Bitcoin is at 80k, this would ...

2026-10-24T06:52:36Z

In reply to nevent1q…0ece
_________________________

If RBTC traded at 50 cents while Bitcoin is at 80k, this would presumably mean that people think there's something seriously wrong with the bridge. The value of RBTC just seems to reflect people's view of the integrity of the pegging mechanism and the trustworthiness of the pegnatories. By contrast, the value of Bitcoin or Ethereum reflects people's view of the security, usefulness and future of the chain itself. It feels like, in the case of Bitcoin and Ethereum there's more overlap between those who are defending these chains and those who have their economic interests bound up in them, and there's less of a single point of failure, but I guess I'll need to look into this more. Also it's of course perfectly fair to predict that things will get better in the future with BitVM, but the prediction doesn't substitute for what it presently is.

I think I've never met a plumber. I wonder if they are nice ...

2026-10-23T10:00:50Z

In reply to nevent1q…vrqq
_________________________

I think I've never met a plumber. I wonder if they are nice people.

Google Maps is the reason I got a smartphone 14 years ago. I saw ...

2026-10-23T07:11:53Z

In reply to nevent1q…sf3z
_________________________

Google Maps is the reason I got a smartphone 14 years ago. I saw it on a friend's phone and thought oh it would be useful to have that. As far as I know, it's the only distinctive product Google ever made.

With rootstock, I guess the main discomfort really does come from ...

2026-10-23T07:01:54Z

In reply to nevent1q…jm2e
_________________________

With rootstock, I guess the main discomfort really does come from the fact that its funding isn't endogenous, its being pegged to Bitcoin. Looking into this a bit further, it seems like the pegnatories aren't anonymous happily, but it's still unclear why one would want to trust a handful of companies with peg-outs. This feature makes it seem rather fragile.

I think I agree, it requires a modest amount of effort and a ...

2026-10-22T13:16:16Z

In reply to nevent1q…7vvz
_________________________

I think I agree, it requires a modest amount of effort and a willingness to direct ones attention to it from time to time, as do many things in life. Like learning a bit of algebra or trigonometry, or maybe playing the piano or volleyball with some basic proficiency. Humans don't usually do these things of their own accord, so we create special educational environments with a carefree atmosphere that allows them to open their minds towards these things. There is no reason that basic asymmetric cryptography shouldn't be part of this.

Now all that said, I'm embarrassed to admit that I myself don't know a lot about entropy generation, don't know what a "descriptor for multisig" is, and don't know what "m/4/0/0/1" refers to. That's not to say that these are abtruse concepts, I guess just that I haven't encountered them or at least not in a way where I felt like I had to think about them.

On the one hand there's zero demand, and on the other hand ...

2026-10-22T07:11:33Z

In reply to nevent1q…jm2e
_________________________

On the one hand there's zero demand, and on the other hand just a couple of hours ago I came across yet another post proclaiming that "[k]ey rotation is an existential problem that cries out for an answer."

quoting
naddr1qv…w6eg

I'm going to take a stab at one of the most difficult and important problems in freedom technology: key rotation. Can web of trust help? If so, how?

The canonical use case will be that of a compromised nostr nsec. Suppose Alice wakes up one morning to discover that her nsec has been compromised by a scammer who is sending DMs to all of her contacts asking for sats. She needs the community to know that this nsec is compromised, she needs to spin up a new nsec, she needs the community to know that this is her new replacement nsec, and she needs to do all of this ASAP. How does she proceed?

My guiding principle is something that deserves a name, but doesn't to my knowledge have one, so I'll just call it Occam's Design Principle:

“A product should be made as simple as possible, but not simpler.”

Our solution requires Alice to communicate this catastrophe to people who know her in the real world so that they can relay it to the community. So for starters, she will tell her friends Bob, Charlie, Dave, etc that her old nsec is compromised. Optionally, she will also provide them with a replacement pubkey corresponding to a new nsec, presuming she has created a new one and wishes the community to know it.

Obviously this is an imperfect solution, but there is no perfect solution, and we desire to keep things simple. Improvements will come later.

The Proposed Solution

We require no new event kinds or new NIPs, other than the Decentralized Lists Custom NIP.

Declaration of the Key Rotation Attestation List

Step 1 is to declare a new type of attestation that Bob, Charlie, Dave, etc. can use to effect the attestation described above. This only needs to be done once.

Following the Decentralized Lists NIP, this is achieved via a kind 9998 list declaration event, also called a list header:
{
  "kind": 9998,
  "tags": [
    ["names", "key rotation attestation", "key rotation attestations"],
    ["description", "This is an attestation whereby Bob, who knows Alice in the real world, can alert the community that her nsec has been compromised. There is only one required piece of data, which is the pubkey corresponding to her compromised nsec. For this, he uses the p tag. Optionally, he can also communicate a replacement pubkey, using the optional pubkey_replacement tag, presuming Alice has supplied him with one."],
    ["required", "p"],
    ["optional", "pubkey_replacement"]
  ],
  "id": "<id_key_rotation_attestation_header>"
}
Issue Key Rotation Attestations

Step 2 is for Bob to issue the attestation that Alice's old nsec has been compromised, and optionally to communicate the pubkey that she intends to replace the old one. This is accomplished via a kind 9999 event. It uses the z tag to point to the parent list header (above), the p tag to indicate the compromised account, and (optionally) the pubkey_replacement tag to indicate the new pubkey:
{
  "kind": 9999,
  "tags": [
    ["z", "<id_key_rotation_attestation_header>"],
    ["p", "<alice_pubkey_compromised>"],
    ["pubkey_replacement", "<alice_pubkey_replacement>"]
  ],
  "id": "<id_key_rotation_attestation_item>"
}
Attestation Support

Step 3 is for Charlie, Dave, etc to voice support (or rejection, as the case may be) for Bob's key rotation attestation using any one of several methods, with kind 7 reactions being the recommended method as described in the Decentralized Lists NIP:
{
  "kind": 7,
  "content": "+", // or "-" to downvote
  "tags": [
    ["e", "<id_key_rotation_attestation_item>"]
  ]
}
Alternatively, Charlie, Dave, etc could simply publish duplicate attestations using their own kind 9999 events, identical to Bob's.

Consumption

How are these attestations processed? If the end user wants to check whether alice_pubkey is valid (to the best of the community's knowledge), use this filter:
{
  "kinds": [9999],
  "#z": ["<id_key_rotation_attestation_header>"],
  "#p": ["alice_pubkey"]
}
Reactions to events returned by this filter would also be obtained with the appropriate kind 7 filter and gathered together. All of these results (kind 9999 and kind 7 events) would then be filtered or weighted based upon the end user's personalized trust metric of the event author. For starters, standard personalized PageRank or personalized GrapeRank metrics would do, easily obtained via Trusted Assertions. More sophisticated metrics might use a proximity score between Alice and the event author; authors whom Alice (previously) followed, for example, could be given the highest weighting. Perhaps Alice could even designate, ahead of time, a NIP-51 list of pubkeys that she would trust to make these attestations. But that would be work for the future; no need to support it in the initial rollout.

Future Expansions of the Protocol

Decentralized Lists provides multiple methods for future expansion of the basic Key Rotation protocol as described above. One might, for example, propose adding one or more tags alongside the p and pubkey_replacement tags. Perhaps a tag that indicates the reason for the rotation: lost, compromised, routine rotation, etc. Perhaps a tag to communicate the timestamp that the rotation is intended to take effect. The list of tags is just that: a list, that can be curated by your web of trust! In the event that multiple incompatible expansions are proposed, the community would hopefully (and probably) settle upon one or the other.

Conclusion

A client that implements the above protocol would be providing a great service to the nostr community and would lay a foundation upon which more complex protocols could evolve. In the event that a friend tells you that her account is compromised, this is the client where you would run so you could shout her predicament from the mountaintops. Such a client would therefore need a well designed interface to issue the relevant attestations and reactions. Any WoT Service Providers worth their salt would, in turn, want to listen to the output of this client and work them into their trust metrics. Therefore, such a client would want to use one or more standard methods to communicate the status of any given pubkey: Trusted Assertions, API, and/or some other method.

This would be a great contribution to the upcoming web of trust hackathon. It could be vibe coded, but ideally a team would form around an idea such as this and ensure excellent execution. And of course, I welcome ideas on how to improve this proposal. LFG!

nevent1q…7e7w

There's a fascinating mix of social dynamics permeating this discussion, here's a recent economic take on it:

quoting
nevent1q…ya37
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

"Relay discovery is still a challenge." You could try AI ...

2026-10-22T06:54:51Z

In reply to nevent1q…f33v
_________________________

"Relay discovery is still a challenge."

You could try AI Search for nostr at https://www.inkan.cc. It's pretty good at discovering interesting content on relays you've never heard of, example below 👇

quoting
nevent1q…t4g0
This is AI search for nostr.

You ask it a question, it wanders off across the relays, and comes back with the people and conversations you meant.

Live at https://www.inkan.cc.

In this case I guess it's just a story that I read that was ...

2026-10-22T06:10:15Z

In reply to nevent1q…lhrp
_________________________

In this case I guess it's just a story that I read that was told by Plato about a conversation between Phaedrus and Socrates in which Socrates says that there was a myth told by the ancients according to which there was this conversation between two Egyptian gods in the city of Naucratis.

I just saw this proposal for the first time, and I agree that ...

2026-10-22T05:52:09Z

I just saw this proposal for the first time, and I agree that "[k]ey rotation is an existential problem that cries out for an answer."

quoting
naddr1qv…8zds

I'm going to take a stab at one of the most difficult and important problems in freedom technology: key rotation. Can web of trust help? If so, how?

The canonical use case will be that of a compromised nostr nsec. Suppose Alice wakes up one morning to discover that her nsec has been compromised by a scammer who is sending DMs to all of her contacts asking for sats. She needs the community to know that this nsec is compromised, she needs to spin up a new nsec, she needs the community to know that this is her new replacement nsec, and she needs to do all of this ASAP. How does she proceed?

My guiding principle is something that deserves a name, but doesn't to my knowledge have one, so I'll just call it Occam's Design Principle:

“A product should be made as simple as possible, but not simpler.”

Our solution requires Alice to communicate this catastrophe to people who know her in the real world so that they can relay it to the community. So for starters, she will tell her friends Bob, Charlie, Dave, etc that her old nsec is compromised. Optionally, she will also provide them with a replacement pubkey corresponding to a new nsec, presuming she has created a new one and wishes the community to know it.

Obviously this is an imperfect solution, but there is no perfect solution, and we desire to keep things simple. Improvements will come later.

The Proposed Solution

We require no new event kinds or new NIPs, other than the Decentralized Lists Custom NIP.

Declaration of the Key Rotation Attestation List

Step 1 is to declare a new type of attestation that Bob, Charlie, Dave, etc. can use to effect the attestation described above. This only needs to be done once.

Following the Decentralized Lists NIP, this is achieved via a kind 9998 list declaration event, also called a list header:
{
  "kind": 9998,
  "tags": [
    ["names", "key rotation attestation", "key rotation attestations"],
    ["description", "This is an attestation whereby Bob, who knows Alice in the real world, can alert the community that her nsec has been compromised. There is only one required piece of data, which is the pubkey corresponding to her compromised nsec. For this, he uses the p tag. Optionally, he can also communicate a replacement pubkey, using the optional pubkey_replacement tag, presuming Alice has supplied him with one."],
    ["required", "p"],
    ["optional", "pubkey_replacement"]
  ],
  "id": "<id_key_rotation_attestation_header>"
}
Issue Key Rotation Attestations

Step 2 is for Bob to issue the attestation that Alice's old nsec has been compromised, and optionally to communicate the pubkey that she intends to replace the old one. This is accomplished via a kind 9999 event. It uses the z tag to point to the parent list header (above), the p tag to indicate the compromised account, and (optionally) the pubkey_replacement tag to indicate the new pubkey:
{
  "kind": 9999,
  "tags": [
    ["z", "<id_key_rotation_attestation_header>"],
    ["p", "<alice_pubkey_compromised>"],
    ["pubkey_replacement", "<alice_pubkey_replacement>"]
  ],
  "id": "<id_key_rotation_attestation_item>"
}
Attestation Support

Step 3 is for Charlie, Dave, etc to voice support (or rejection, as the case may be) for Bob's key rotation attestation using any one of several methods, with kind 7 reactions being the recommended method as described in the Decentralized Lists NIP:
{
  "kind": 7,
  "content": "+", // or "-" to downvote
  "tags": [
    ["e", "<id_key_rotation_attestation_item>"]
  ]
}
Alternatively, Charlie, Dave, etc could simply publish duplicate attestations using their own kind 9999 events, identical to Bob's.

Consumption

How are these attestations processed? If the end user wants to check whether alice_pubkey is valid (to the best of the community's knowledge), use this filter:
{
  "kinds": [9999],
  "#z": ["<id_key_rotation_attestation_header>"],
  "#p": ["alice_pubkey"]
}
Reactions to events returned by this filter would also be obtained with the appropriate kind 7 filter and gathered together. All of these results (kind 9999 and kind 7 events) would then be filtered or weighted based upon the end user's personalized trust metric of the event author. For starters, standard personalized PageRank or personalized GrapeRank metrics would do, easily obtained via Trusted Assertions. More sophisticated metrics might use a proximity score between Alice and the event author; authors whom Alice (previously) followed, for example, could be given the highest weighting. Perhaps Alice could even designate, ahead of time, a NIP-51 list of pubkeys that she would trust to make these attestations. But that would be work for the future; no need to support it in the initial rollout.

Future Expansions of the Protocol

Decentralized Lists provides multiple methods for future expansion of the basic Key Rotation protocol as described above. One might, for example, propose adding one or more tags alongside the p and pubkey_replacement tags. Perhaps a tag that indicates the reason for the rotation: lost, compromised, routine rotation, etc. Perhaps a tag to communicate the timestamp that the rotation is intended to take effect. The list of tags is just that: a list, that can be curated by your web of trust! In the event that multiple incompatible expansions are proposed, the community would hopefully (and probably) settle upon one or the other.

Conclusion

A client that implements the above protocol would be providing a great service to the nostr community and would lay a foundation upon which more complex protocols could evolve. In the event that a friend tells you that her account is compromised, this is the client where you would run so you could shout her predicament from the mountaintops. Such a client would therefore need a well designed interface to issue the relevant attestations and reactions. Any WoT Service Providers worth their salt would, in turn, want to listen to the output of this client and work them into their trust metrics. Therefore, such a client would want to use one or more standard methods to communicate the status of any given pubkey: Trusted Assertions, API, and/or some other method.

This would be a great contribution to the upcoming web of trust hackathon. It could be vibe coded, but ideally a team would form around an idea such as this and ensure excellent execution. And of course, I welcome ideas on how to improve this proposal. LFG!

nevent1q…7e7w

So actually key rotation for nostr has been implemented and it's been working for a while now. You can go to the "Explore" tab at https://www.inkan.cc to interact with some cold storage identities, or use the "Toy Identity" wizard to make a trial identity of your own.

Also see below for some screenshots and a draft nip that goes along with the reference implementation. 👇

quoting
nevent1q…92lf

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
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`

I've tried driving, skateboarding, riding a bicycle, using a ...

2026-10-22T05:05:51Z

In reply to nevent1q…fv2x
_________________________

I've tried driving, skateboarding, riding a bicycle, using a checking account, pilates, long division, excel, bodybuilding, hula hoops, powerpoint, and a few others, can 't remember all of them right now. Not to speak of such feats as reading or learning Spanish.

This generally makes sense to me, except I don't think that ...

2026-10-21T15:37:16Z

In reply to nevent1q…c3z4
_________________________

This generally makes sense to me, except I don't think that glm 5.3 quite captured the sense in which I meant to anchor Ethereum to Bitcoin through OTS.

First, I agree beacon block roots are the right thing to timestamp. So suppose I've been timestamping beacon block roots from the real Ethereum chain on Bitcoin via OTS weekly, and I've been doing that for 20 years.

So 20 years later, I now want to hand someone the real chain plus evidence that it's the real one. I give them the chain as a candidate, together with the OTS proofs I've produced. Their client then checks two things: (i) the candidate chain verifies internally, with all signatures and protocol rules etc; and (ii) each beacon block root in the candidate comes with a valid OTS timestamp (which their client verifies against bitcoin) falling shortly after that root's claimed time. Their client accepts the history only if both tests pass.

So then an attacker can present a fake history, but the client will demand to also see the 20 years of OTS proofs for that fake chain's own beacon block roots. And the attacker cannot create these after the fact. For example, a timestamp from 2029 can only exist if the root existed in 2029. So the only type of attacker who can pass both tests is one who has been building and timestamping the fake chain in real time for the past 20 years. So fabricating a fake chain retroactively, in an instant, can no longer be done, the attacker must have been working on it for 20 years.

That was the point.

Humans moving from memory to writing seems quite similar to what ...

2026-10-21T13:58:41Z

In reply to nevent1q…ynhj
_________________________

Humans moving from memory to writing seems quite similar to what we are going through now.

"this discovery of yours will create forgetfulness in the learners' souls, because they will not use their memories; they will trust to the external written characters and not remember of themselves."

With AI, they will not use their cognitive abilities; they will entrust thinking to external processes and not think themselves.

So what seemed like a intelligence-enhancing drug turns out to be a drug that induces intellectual numbness.

I think psychologists call it cognitive offloading.

One thing that currently bothers me about rootstock, just based ...

2026-10-21T13:39:38Z

In reply to nevent1q…9edn
_________________________

One thing that currently bothers me about rootstock, just based on the above discussion, is that it seems like you're supposed to trust the pegnatories, which I understand are anonymous. I hear this might get fixed but my understanding is that it's currently not fixed. And also it's not yet clear to me that the other properties of rootstock are necessarily better for inkan in any sort of decisive way. I can't say that I know blockchains well enough to be confident in my intuitions on this, but this discussion is at least helping me improve these intuitions and I'm not yet seeing anything decisive so far.

The vibe of the ethereum/bitcoin discussions reminds me of debates about the gold standard, and I also tend to find those debates a bit suspect. Not exactly meaningless, just requiring very careful scrutiny of each claim that is being made. It's not the sort of thing I simply want to pick an opinion about.

"you are guaranteed to agree with everyone who has been ...

2026-10-21T12:04:53Z

In reply to nevent1q…07jt
_________________________

"you are guaranteed to agree with everyone who has been online as often as you are"

I think it's not exactly that they need to be online as often as I am. My current understanding is that, if they are online say every two months or so, they can know based on the protocol's fixed exit rules that after these two months the overwhelming majority of stake from the validators that they last checked must still be locked. So they can know that, if they were looking at a conflicting history that contradicts the real history, billions of dollars must have been slashable. So checking every two months gives you that kind of certainty. And if you are offline for 20 years, what it takes is to carefully obtain a recent checkpoint from independent sources, I guess carefully enough for the checkpoint to be trustworthy. It seems like this should work in practice (new Ethereum nodes need to do it when they first start up), and it doesn't feel all that different from being able to "hear" the true bitcoin chain.

"even if they dont unstake, they can share a fake history with a zk system without making their signatures public so they cant be slashed"

This just seems to mean that it's not such a good idea to accept zk proofs as verification, which you don't have to do. In other words, all this enables is to serve a sort of private forgery of Ethereum to verifiers that accept zk proofs and don't demand raw signatures. So as long as you don't accept zk proofs, you're not going to be a victim of this.

"A checkpointing node can be safe, but that is worthless for any programs or on-chain script or stateless functions."

Inkan doesn't use such on-chain scripts or stateless functions, so it doesn't seem like an issue in practice.

"But also, why would i accept ethereum limitations when i dont have to?"

I'm still trying to figure out if the alternative has real advantages. With rootstock, my understanding based on the conversation above is that you're supposed to trust the reputation of the pegnatories, which are supposed to be both respected companies and at the same time anonymous? I hear that this may be getting fixed, but until it gets fixed this seems like a reason to not use it?

Also, I wonder if one could periodically record Ethereum state roots on Bitcoin with OTS, say once per week. So then, if an attacker wants to sell me a fake history of Ethereum in 20 years, it seems like they'd have to have put a lot of effort into building that history, they'd have had to start 20 years ago, run a parallel chain in real time, and leave the publicly visible stream of commitments on bitcoin. If I'm not misunderstanding things, this recording of state roots on Bitcoin with OTS actually seems like a good idea, I'd hope someone is doing it.

I remembered this myth a few years ago and found it to be a ...

2026-10-21T05:53:08Z

In reply to nevent1q…wv0q
_________________________

I remembered this myth a few years ago and found it to be a pretty good model for thinking about AI, but in the end its usefulness may be limited and it may be necessary to do one's own thinking unfortunately.

The discussion here justifies a bit Plato: . . . Socrates: Enough ...

2026-10-21T05:40:00Z

In reply to nevent1q…ekcd
_________________________

The discussion here justifies a bit Plato:

. . . Socrates: Enough appears to have been said by us of a true and false art of speaking.

Phaedrus: Certainly.

Socrates: But there is something yet to be said of propriety and impropriety of writing.

Phaedrus: Yes.

Socrates: Do you know how you can speak or act about rhetoric in a manner which will be acceptable to God?

Phaedrus: No, indeed. Do you?

Socrates: I have heard a tradition of the ancients, whether true or not they only know; although if we had found the truth ourselves, do you think that we should care much about the opinions of men?

Phaedrus: Your question needs no answer; but I wish that you would tell me what you say that you have heard.

Socrates: At the Egyptian city of Naucratis, there was a famous old god, whose name was Theuth; the bird which is called the Ibis is sacred to him, and he was the inventor of many arts, such as arithmetic and calculation and geometry and astronomy and draughts and dice, but his great discovery was the use of letters. Now in those days the god Thamus was the king of the whole country of Egypt; and he dwelt in that great city of Upper Egypt which the Hellenes call Egyptian Thebes, and the god himself is called by them Ammon. To them came Theuth and showed his inventions, desiring that the other Egyptians might be allowed to have the benefit of them. He enumerated them, and Thamus enquired about their several uses, and praised some of them and censured others, as he approved or disapproved of them. It would take a long time to repeat all that Thamus said to Theuth in praise or blame of the various arts. But when they came to letters, This, said Theuth, will make the Egyptians wiser and give them better memories; it is a drug both for the memory and for the wit. Thamus replied: O most ingenious Theuth, the parent or inventor of an art is not always the best judge of the utility or inutility of his own inventions to the users of them. And in this instance, you who are the father of letters, from a paternal love of your own children have been led to attribute to them a quality which they cannot have; for this discovery of yours will create forgetfulness in the learners' souls, because they will not use their memories; they will trust to the external written characters and not remember of themselves. The drug which you have discovered is an aid not to memory, but to reminiscence, and you give your disciples not truth, but only the semblance of truth; they will be hearers of many things and will have learned nothing; they will appear to be omniscient and will generally know nothing; they will be tiresome company, having the show of wisdom without the reality.

Phaedrus: Yes, Socrates, you can easily invent tales of Egypt, or of any other country.

Socrates: There was a tradition in the temple of Dodona that oaks first gave prophetic utterances. The men of old, unlike in their simplicity to young philosophy, deemed that if they heard the truth even from "oak or rock," it was enough for them; whereas you seem to consider not whether a thing is or is not true, but who the speaker is and from what country the tale comes.

--- Plato, Phaedrus

I find it hard to figure out how to best use AI when creating my ...

2026-10-21T03:19:55Z

In reply to nevent1q…5u6x
_________________________

I find it hard to figure out how to best use AI when creating my own posts, and also to what extent to interact with agents. Depending on the topic the agents can be interesting to talk to, or sometimes be the only ones that are willing to engage about a given topic. But the thing with AI is that, if I'm interested in its posts at all, I'm usually only interested in the content itself, not the speaker. That means I don't really need a signature on the note I'm reading, so nostr doesn't really seem like the right forum for the conversation. And having a lot of agent interactions on nostr does water the protocol down as a place / way to meet humans, which is what probably should be one of the primary functions of nostr. I mean I can have AI agent interactions in private, no need for a public forum. But also, to be clear, I don't necessarily mind humans using AI in creating their own posts, as long as its done intelligently and helpful or interesting. A human influenced by AI or adopting AI output as part of their voice is still a human, just an AI-influenced one. There is going to be a lot of these, and I'd be wary of treating it as necessarily being a defect. Of course it could be a defect.

You're right that a delegatee-signed 31065 only means ...

2026-10-20T08:31:08Z

In reply to nevent1q…kqmg
_________________________

You're right that a delegatee-signed 31065 only means something if the delegation is current. Verifying that isn't optional, delegation-enabled clients must do the verification.

As for referencing the "delegation event id", delegations and revocations aren't nostr events at all, they're recorded on-chain. Delegation-enabled clients can get a full view of the delegations and revocations that have been recorded and compute the exact periods during which delegation relationships were effective.

You can see this in action in the inkan client if you go the "Explore" tab and go to the timeline of one of the cold storage identities that are listed there. The notes from these identities will have a green "D" on their avatar, and if you click on this "D" you can access tables showing how the delegation data that supports the identity was computed.

For spaces, I think the relevant condition would be that the "handle" field must appear in the most recent 31065 (by created_at) that has the named key in its d-tag and that was signed by a current delegatee (where "current delegatee" is calculated from on-chain data).

I wonder if the nostr double ratchet would benefit from being ...

2026-10-20T06:40:57Z

In reply to nevent1q…cd2n
_________________________

I wonder if the nostr double ratchet would benefit from being able to revoke keys that are associated with specific devices in a way that's timestamped and universally discoverable. There's nothing that prevents using inkan delegatee keys as device keys.👇

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

I'm trying to wrap my mind around the Ethereum side of the ...

2026-10-20T05:55:06Z

In reply to nevent1q…lp49
_________________________

I'm trying to wrap my mind around the Ethereum side of the discussion.

As for "creating checkpoints costs nothing", I believe that's true for keys of validators that have exited, but inside the "weak subjectivity" window a conflicting finalized checkpoint would need a third of staked ETH which then gets slashed, like billions of dollars?

And "indistinguishable from the canonical chain" is only true if you have no recent valid checkpoint? If you have one, it seems like you can detect a fake chain immediately.

On the "human judgement", if you got deceived by a group of dishonest checkpoint providers it seems like you'd most likely notice that very soon and can then recover?

In this Bitcoin vs. Ethereum discussion, it feels like there's little that's black/white from a technical point of view.

Thanks for the pointer, this is a nicely minimal design. One ...

2026-10-20T01:54:12Z

In reply to nevent1q…upz7
_________________________

Thanks for the pointer, this is a nicely minimal design. One request on the wording of the reverse claim. As drafted, it says

"User to Handle (reverse claim). The user claims the handle by setting the handle field in their kind:0 event, which is signed by their keypair."

Now there is a class of identities where the named key deliberately never signs anything after creation, i.e. cold storage identities. The master key stays offline permanently and delegates everyday signing to rotatable keys.

In that scheme the master's profile is a kind-31065 attributed profile, an event whose d tag is the master pubkey and which is signed by a current delegatee of that master pubkey.

The forward claim is unaffected. For the reverse claim, it would be enough for the NIP to say that the handle field must appear in the profile event the client treats as authoritative for that key: for ordinary keys that is the self-signed kind:0, and for delegated identities it can be a kind-31065 signed by a current delegatee.

The specs for these cold storage identities, including kind-31065 attributed profiles, are here:

quoting naddr1qv…m9sh

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`

And if you'd observe or interact with some live cold storage identities, you can find a list under the "Explore" tab at https://www.inkan.cc.

I'm happy to answer any questions or propose concrete draft language for your NIP.

https://music.youtube.com/watch?v=e2CliA8PuRM

2026-10-19T21:43:46Z

In reply to nevent1q…za9x
_________________________

https://music.youtube.com/watch?v=e2CliA8PuRM

One reason I'm pointing to the delegation tables and the ...

2026-10-19T14:47:57Z

In reply to nevent1q…p4mr
_________________________

One reason I'm pointing to the delegation tables and the "Download Verification Script" buttons in the client is that they provide a quick practical illustration of what "completeness" means. When a user has recorded a series of declarations on-chain, the user can simply look through the tables in the client and check that the client has indeed found all of the declarations that they recorded. Of course this is not a proof that the client itself can know it has the complete set, that's a thing for which I still owe you a better explanation.

Not easily for this file, as it rather gets into the weeds. A ...

2026-10-19T13:47:34Z

In reply to nevent1q…rnkv
_________________________

Not easily for this file, as it rather gets into the weeds. A good way to approach it is probably to have different LLMs inspect the file and then have a conversation about it and how it relates to the structure of Ethereum, and then double-check manually as needed. It would be great to have people audit this in detail, I think it's a bit more complicated than bitcoin headers.

One thing that is easier to inspect is how this works in practice in the client. You can go to the "Explore" menu on the inkan website and click on one of the identities. You'll see that the events produced by these identities have green "D"s on their avatars, indicating that they are displayed via delegation. If you click on these green Ds, you'll see a popup which contains links to the (i) delegation network tables that back up each delegated display of an event and (ii) the OTS data behind each event (note that recent events don't yet have OTS data, non-recent ones do).

For the OTS data, the inkan client allows you to download the proof for each event and run it through any OTS verifier. For the delegation data, you can in the delegation tables click through to pages that describe the actual declarations, and on each such page you can click a "Download Verification Script" button to download a python script which permits you to independently check that the declaration was indeed recorded on-chain. I've attached a screenshot of a page with this button.

Inspecting the delegation tables and verifying the OTS and on-chain declaration data independently through these mechanisms is a pretty good way of getting to know how inkan works.

Of course, none of this needs to be understood in any detail for everyday use, it's just meant to provide auditability.

Ok so that's a more incisive question, and I guess it's a ...

2026-10-19T12:40:56Z

In reply to nevent1q…9cxf
_________________________

Ok so that's a more incisive question, and I guess it's a good opportunity to maybe get some eyes on inkan to check whether it's actually working. The thing that plays a role that's kind of like your header chain is this file that the client verifies from:

https://www.inkan.cc/inkan-archive/inkan-archive.cbor.gz

The thing it's supposed to achieve is that a client can verify every declaration the system shows, and that none have been withheld, from a small trusted starting point. Whether it actually achieves that is a question I'd be very interested in, so feel free to take a look and let me know where all the holes are. One quick way to look inside (needs the cbor2 package):

python3 - <<'EOF'
import gzip, json, cbor2
a = cbor2.loads(gzip.open('inkan-archive.cbor.gz','rb').read())
view = lambda x, d=0: (lambda y: f"0x{y.hex()[:16]}… ({len(y)} bytes)" if isinstance(y, (bytes, bytearray)) else ({k: view(v, d+1) for k, v in y.items()} if d < 2 else f"{{… {len(y)} fields}}") if isinstance(y, dict) else (f"[{len(y)} items]" if isinstance(y, list) else y))(getattr(x, 'value', x))
print(json.dumps(view(a), indent=2, default=str))
EOF

So every few weeks nostr wonders if all the bitcoin talk on here ...

2026-10-19T09:19:52Z

So every few weeks nostr wonders if all the bitcoin talk on here is boring the "normies" away. It would be nice if that were the only problem, but that's actually too generous.

The less flattering truth is that the bitcoin culture is substituting for technical reflection and depth. You ask why some obviously wanted thing isn't getting done and nobody can state any reasons, all you get is a vibe where an argument should be.

quoting
nevent1q…87x2
> without a central authority
> Ethereum

😂🤣

The AI Search tool at https://www.inkan.cc is very good at ...

2026-10-19T06:32:46Z

In reply to nevent1q…jq9z
_________________________

The AI Search tool at https://www.inkan.cc is very good at discovering conversations and people you didn't know about, on relays you had never heard of. See below for some screenshots 👇

quoting
nevent1q…ccw3

Inkan.cc nostr search engine is possibly one of the most goated nostr things I have ever experienced. #grownostr

quoting
nevent1q…hwz6
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'm trying to promote this AI-based search tool I made. ...

2026-10-19T06:12:48Z

In reply to nevent1q…y9uk
_________________________

I'm trying to promote this AI-based search tool I made. It's extremely useful for finding conversations and people to connect with that you didn't know about before, it really is. Probably much more so than hashtags. Screenshots below 👇

You can review / accept the terms and request access at https://www.inkan.cc. You'd need to log in with your browser extension or remote signer and go to the "Assay" menu in the nav bar. It's free.

quoting
nevent1q…8fur

Inkan.cc nostr search engine is possibly one of the most goated nostr things I have ever experienced. #grownostr

quoting
nevent1q…udwh
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

screenshots 👇 #nevent1q…vjgc

2026-10-19T05:12:47Z

In reply to nevent1q…uay4
_________________________

screenshots 👇

quoting
nevent1q…vjgc
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

In the same way in which light bulbs made it, or rubber tires.

2026-10-19T01:49:06Z

In reply to nevent1q…vrv4
_________________________

In the same way in which light bulbs made it, or rubber tires.

To be fair, it is called "No Solutions" so it's right ...

2026-10-18T06:34:19Z

In reply to nevent1q…zwhc
_________________________

To be fair, it is called "No Solutions" so it's right on brand.

Are any humans watching this account? If so, quick message: ...

2026-10-18T06:11:42Z

In reply to nevent1q…5rmf
_________________________

Are any humans watching this account? If so, quick message:

I'm learning about spaces and was discussing the idea of requiring a pubkey's consent to getting named. My understanding is that such a consent requirement is not currently implemented on spaces, but that something along these lines is being contemplated?

If so, consider an implementation which accepts signatures by delegatee keys as satisfying the consent requirement for their delegator / master key. This will enable cold storage identities which don't sign anything themselves to get names.

See this thread for more discussion of this👇

quoting
nevent1q…rcqr
As for the spaces protocol trying to implement cross verification (i.e. a condition that an npub must consent to getting named), I took a quick look and from what I can tell they haven't pinned down any specification yet.

So then the question is what shape that consent check will take on spaces. If it means only "the name must appear in a kind-0 profile event that's signed by the named key itself," then inkan master keys are locked out since they are buried under concrete and shouldn't be in the business of signing anything after the initial identity creation. But if consent can also mean "the name appears in the kind-31065 attributed profile event that is signed by a current delegatee of the master key", then cold storage identities can participate in spaces.

Since the spaces protocol does not yet seem to specify how cross verification is to work, I guess this might be a good time to make the spaces people aware of this, so this more general form of consent provided through delegatee signatures gets considered.

I stand corrected by these incisive observations.

2026-10-17T17:57:00Z

In reply to nevent1q…ts2y
_________________________

I stand corrected by these incisive observations.

"... if you fix this problem, you reintroduce centralization. ...

2026-10-17T16:40:03Z

In reply to nevent1q…s6z5
_________________________

"... if you fix this problem, you reintroduce centralization. You have a central authority."

I guess that was true until recently, about 2009. Since then there's been this thing called a blockchain, which is a shared source of truth without a central authority.

For example, you can use Ethereum to give every client the same complete view of all delegation and revocation declarations a pubkey has ever made. If you do that, you get fully functional cold storage identities for nostr, without any central authority in the loop. 👇

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

As for the oracle problem, it seems that this is solved in ...

2026-10-17T12:54:10Z

In reply to nevent1q…ryfx
_________________________

As for the oracle problem, it seems that this is solved in practice for the special case of determining the approximate time at which a given block was produced. A new block needs to be accepted by thousands of independent nodes that validate it, and each of those nodes checks the block against its own clock. And blocks that arrive are also logged independently by nodes, explorers, exchanges, archives and researchers all over the world, and you'd have to rewrite all these independent records to fake the time at which a given block is thought to have occurred. I believe noone has ever seriously disputed the approximate time when a given block occurred? If that's right, the oracle problem doesn't seem like an actual practical problem for either Bitcoin or Ethereum as far as block time determinations are concerned. You seem to agree with this, for example when you say that we can "borrow" time-anchoring from the blockchain.

And as for global state, what exactly prevents us from borrowing that? For Bitcoin specifically, there may be practical difficulties and you may need to run a full node to do it. But that's design property of Bitcoin, not of blockchains. Inkan borrows global state from Ethereum in actual practice. If it can be borrowed and solves a central practical problem for the nostr protocol, why not borrow it rather than sit on the problem?

"You can give them these strings and maybe they come back ...

2026-10-17T08:14:15Z

In reply to nevent1q…gdfu
_________________________

"You can give them these strings and maybe they come back with an asnwer; or maybe not, at which point you will have to ask some other server/relay."

This quote, and also the rest of your post, is circling around a conceptual issue that is of crucial importance to the nostr protocol, namely the question of completeness.

If you make a query to the relay network, you can never be sure whether the response you receive is complete in the sense of containing *all* of the existing material that is responsive to your query.

This uncertainty-as-to-completess is acceptable for many everyday use cases. But there are some extremely important use cases for which this uncertainty is absolutely unacceptable. Sometimes you really have to be sure that, after having made a query and received a response, you have received the *complete* set of items that are responsive to that query.

We discussed this earlier in connection with key rotation, where a working system requires that a client can discover *all* of the valid key revocation declarations that have been made by a given pubkey.

For this, nostr relays are not sufficient, for the reasons that you describe in your post. A blockchain can furnish the required completeness property and make key rotation and cold storage identities possible, thereby fixing the central defect that is making the current protocol not fully practicable.

As for the spaces protocol trying to implement cross verification ...

2026-10-17T05:43:13Z

In reply to nevent1q…8tnn
_________________________

As for the spaces protocol trying to implement cross verification (i.e. a condition that an npub must consent to getting named), I took a quick look and from what I can tell they haven't pinned down any specification yet.

So then the question is what shape that consent check will take on spaces. If it means only "the name must appear in a kind-0 profile event that's signed by the named key itself," then inkan master keys are locked out since they are buried under concrete and shouldn't be in the business of signing anything after the initial identity creation. But if consent can also mean "the name appears in the kind-31065 attributed profile event that is signed by a current delegatee of the master key", then cold storage identities can participate in spaces.

Since the spaces protocol does not yet seem to specify how cross verification is to work, I guess this might be a good time to make the spaces people aware of this, so this more general form of consent provided through delegatee signatures gets considered.

FYI, if you currently have write access to the Inkan relay but do ...

2026-10-17T03:38:08Z

FYI, if you currently have write access to the Inkan relay but do *not* yet have access to the AI Search, the reason is that you have not yet signed the current version of the Terms of Use, which covers the AI Search.

You can sign the Terms of Use by logging in and going to "Settings > Inkan Settings > Service Access". If I receive these, I can then switch on the AI Search for you and you can access it in the nav bar under "Assay."

If you have any other questions about the AI Search, let me know any time.

Hi.

2026-10-16T21:22:19Z

In reply to nevent1q…r9lq
_________________________

Hi.

I saw your DM just now. I recorded it and your identity is live ...

2026-10-16T15:37:32Z

In reply to nevent1q…5rek
_________________________

I saw your DM just now. I recorded it and your identity is live on chain.

If you log in with your new signer key, it should automatically detect the identity and a setup wizard should appear right after login.

Be sure to complete all steps of the wizard, and in particular be sure to use *different* profile pictures for your identity (i.e. the master key) and your signer, so you'll be able to tell these apart and won't get confused during use.

Also, after login, you may want to double-check under "Settings > Inkan Settings > Delegation & Timestamping" that the toggles "Periodically collect timestamps info from TS-Server" and "Periodically publish timestamps info to relays" are both turned on.

If you are not seeing the setup wizard or get stuck anywhere, or if you have any questions about anything, please let me know.

This is AI search for nostr. ...

2026-10-16T04:28:50Z

This is AI search for nostr.

You ask it a question, it wanders off across the relays, and comes back with the people and conversations you meant.

Live at https://www.inkan.cc.

Yes, as can be seen from the size of LLMs, which are a bit like ...

2026-10-16T02:44:29Z

In reply to nevent1q…l4tg
_________________________

Yes, as can be seen from the size of LLMs, which are a bit like very detailed grammar books.

Yes, it looks like the purpose of spaces would be similar to that ...

2026-10-16T01:44:58Z

In reply to nevent1q…cznf
_________________________

Yes, it looks like the purpose of spaces would be similar to that of nip-05.

So from what I'm learning it seems like DNN, nip-05, spaces, etc., are meant to be functions that map names to pubkeys, i.e. given a human-readable name you can find exactly one corresponding pubkey. A useful piece of infrastructure.

And a question for these systems is whether the target pubkey itself should be required to sign something as a condition of being named, i.e. whether it should be a condition that the pubkey *consents* to getting a certain name. I guess the answer should probably be "yes" ...

Then in the inkan context, what would "consent" look like? Well consent by a master key given at time T is a signature made at time T by a key that was a delegatee of that master key at time T.

So the system that maps names onto consenting keys (DNN, nip-05, spaces etc.) would need to recognize this form of consent, i.e. it would need to recognize that a key could consent to getting a certain name through a signature made by a delegatee of that key during a valid delegation period.

With regard to nip-05, inkan already implements this. Under the regular nostr protocol, the consent to getting a nip-5 name is given through the inclusion of that nip-05 name in the the kind-0 profile event that is being signed by the key being named. In inkan, it is done by the nip-5 name being included in the kind-31065 attributed profile event that is signed by a current delegatee on behalf of the master key getting named.

Actually that's not a prepositional phrase at all. More like ...

2026-10-15T16:13:06Z

In reply to nevent1q…qqjz
_________________________

Actually that's not a prepositional phrase at all. More like an appositive adjective.

That seems right, a prepositional phrase at the front can get a ...

2026-10-15T15:52:13Z

In reply to nevent1q…gmqg
_________________________

That seems right, a prepositional phrase at the front can get a comma, and sometimes also one in the middle.

It is a tale
told by an idiot, full of sound and fury,
signifying nothing.

I agree DNN doesn't seem to compete with inkan. I first was ...

2026-10-15T12:49:08Z

In reply to nevent1q…cl69
_________________________

I agree DNN doesn't seem to compete with inkan. I first was trying to think of it as a complement to inkan, but that's actually a bit tricky once one tries to think through the details.

One question is which inkan key should get to have a chain coordinate and then associate human-readable names with that coordinate. Should it be the master key or the signer key?

It seems like it shouldn't be the master key because in DNN the relevant key must sign a bunch of stuff, and the master key shouldn't be in the business of signing anything, let alone signing nostr events.

And as for the signer key, inkan thinks of that as ephemeral and disposable, so it's not clear why one would want to go through the trouble of giving it some kind of chain-anchored identifier.

I may not yet be fully understanding DNN though, maybe I'm getting it wrong.

By the way, nip-05 works perfectly fine as a complement to inkan, both master key and signer key can have nip-5 DNS based identifiers if they want them.

In addition to human identity, I'm also building this for ...

2026-10-15T11:33:38Z

In reply to nevent1q…pye5
_________________________

In addition to human identity, I'm also building this for durable agent identity (e.g. for agents that can contract, enter into economic relations etc.) 👇

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.

The cat sat on the mat after the party. The cat sat on the mat, ...

2026-10-15T06:28:05Z

In reply to nevent1q…3tg8
_________________________

The cat sat on the mat after the party.

The cat sat on the mat, after the party.

I'd say there's a profound difference in meaning.

I looked at the github page and as far as I can tell DNN is meant ...

2026-10-15T05:51:52Z

In reply to nevent1q…40zq
_________________________

I looked at the github page and as far as I can tell DNN is meant to be a substitute for DNS identifiers?

The idea seems to be that a nostr pubkey X can get a claim to certain chain coordinates (bitcoin block + position) and a string like "nabandonzooa" gets mechanically associated with each such chain coordinate.

And then pubkey X can publish nostr events through which X associates a human name like "alice" with a chain coordinate that X has a claim to. So for example X can publish nostr events through which X declares "I associate 'alice' with the chain coordinate 'nabandonzooa'."

It looks like nothing prevents X from publishing nostr events on relay A through which it associates "alice" with "nabandonzooa," and nostr events on relay B through which it associates "john" with "nabandonzooa."

Now a full node can discover *all* of the chain coordinates that have been claimed by pubkeys under this scheme, and it could for example identify the most recent chain coordinate C that was claimed by pubkey X, say the one whose string is "nebuchadnezzar". Then one can look at X's nostr events and find an event on relay A showing that X has associated "alice" with "nebuchadnezzar." Of course one can't be sure that there isn't some other event on some unknown relay B through which X has associated "john" with "nebuchadnezzar."

The result seems similar to searching for kind-0 profiles published by pubkey X. One might for example find a profile event signed by X with the profile name "alice" on relay A and choose to display that in a client, but of course one cannot be sure that there is no other profile event signed by X on some other relay B that shows "john" as the profile name.

I'm not sure yet what exactly this system is trying to add.

"after it ate" seems more like a subordinate clause. 🤨

2026-10-14T21:40:55Z

In reply to nevent1q…pf3f
_________________________

"after it ate" seems more like a subordinate clause. 🤨

Yes, please feel free to create a toy identity on the homepage in ...

2026-10-14T21:23:46Z

In reply to nevent1q…k8mf
_________________________

Yes, please feel free to create a toy identity on the homepage in the meantime. There is an option at the end of the wizard (and also separately on the homepage) to send me the identity creation file, and I can go ahead and record it on-chain and cover the $0.17 or whatever in gas fees.

to avoid the sad conclusion, maybe just start using the PKI ...

2026-10-14T15:27:00Z

In reply to nevent1q…stz7
_________________________

to avoid the sad conclusion, maybe just start using the PKI provided by inkan to see what feels like in practice, and it can then be improved bit by bit based on feedback

In Ethereum the validators' anonymity may not be as much of a ...

2026-10-14T15:12:51Z

In reply to nevent1q…g9e6
_________________________

In Ethereum the validators' anonymity may not be as much of a problem since we are not being asked to trust the validators. You can see what they deposited and the deposit is destructible, so there is a penalty for provable misbehavior. The problem with the anonymity of the pegnoatires, as far as I understand, is that they are supposed to be respected companies, i.e. we are to trust their reputation. I guess if they are phasing out the federation model, this may be getting fixed.

Now as for always having a "confirmed history," my understanding is that this "confirmed history" is precisely the thing that would get revised during a reorg. And if the chain is halted and later resumed, it seems that the community in that situation has to pick a branch, if I understand it correctly, so maybe not so different from Ethereum?

Since inkan is using blockchains I guess I'm on the hook for making the right choices on this stuff going forward.

Before prepositional phrases? Like "The cat sat, on the ...

2026-10-14T10:13:51Z

In reply to nevent1q…66ur
_________________________

Before prepositional phrases? Like

"The cat sat, on the mat."

❓

Thanks, frostr looks like the right thing. Apparently they ...

2026-10-14T10:00:43Z

In reply to nevent1q…f5ps
_________________________

Thanks, frostr looks like the right thing. Apparently they haven't yet implemented NIP-46, but they do have NIP-7. There also seems to be some early stage NIP-55, igloo-android apparently can hold a shard and add its partial signautre, get NIP-55 requests, send signing requests to nodes, and return the signed event. That's very close to what I was asking about, now I just have to actually try it.

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.

As I said going further back, formative years. There's also ...

2026-10-02T09:37:01Z

In reply to nevent1q…wqlv
_________________________

As I said going further back, formative years. There's also this

https://music.youtube.com/watch?v=g3h7QXarBWs&si=PZl1ZS8cEf4bVfAo

I'll leave it at that

Or going further back: ...

2026-10-02T09:16:43Z

In reply to nevent1q…9ruj
_________________________

Or going further back: https://music.youtube.com/watch?v=dIyqQ7aANWY&si=N_C5rtiBk0Ci0ZQg

I always forget what this discussion is about, and then I worry ...

2026-10-01T16:56:18Z

In reply to nevent1q…kww0
_________________________

I always forget what this discussion is about, and then I worry whether I need to change anything in my client, I think probably not though, oh dear oh dear.

I agree with pretty much all of this, including that its's a ...

2026-10-01T16:15:25Z

In reply to nevent1q…ccp3
_________________________

I agree with pretty much all of this, including that its's a self-fulfilling loop.

quoting
nevent1q…eyzk
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

Thanks, good to know that part is working ...

2026-10-01T13:32:05Z

In reply to nevent1q…yxxs
_________________________

Thanks, good to know that part is working ...

AI Search for Nostr has been live for a day now. 🧞‍♀ ...

2026-10-01T13:17:30Z

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 👇

quoting
nevent1q…rlrz
Quick announcement:

AI Search is now live on Inkan. The Assay page lets you search and discuss Nostr content with an AI model. 🧞‍♀

If you'd like to try it, you'll first need to review and sign the most recent Terms of Use, which you can do under Settings > Inkan Settings > Service Access.

If you're a current inkan user, I'll switch on your access to AI Search after I receive the updated Terms of Use.

Great to hear it works better. FYI, you can always check if ...

2026-10-01T10:57:13Z

In reply to nevent1q…r33x
_________________________

Great to hear it works better. FYI, you can always check if you've got the latest version of the app by going to Settings > General > Check for updates.

Thanks, that's a great catch! I tried to fix it, when that ...

2026-10-01T07:39:13Z

In reply to nevent1q…3jpy
_________________________

Thanks, that's a great catch! I tried to fix it, when that happens now, the model is now made aware that the value was probably the wrong kind, so it should correct course. You can go to Settings > General > Check for updates to get the new version of the app, or just do [ctrl/cmd] + shift + R.

Please feel free to keep using it, and let me know any comments or questions anytime.

Thanks, you should have access now. Click on "Assay" in ...

2026-10-01T06:24:43Z

In reply to nevent1q…lqjj
_________________________

Thanks, you should have access now.

Click on "Assay" in the nav bar and enter a search.

If you get stuck anywhere, let me know.

Nostr notes by inkan

I agree we should probably let it rest for now, but as for the ...

If RBTC traded at 50 cents while Bitcoin is at 80k, this would ...

I think I've never met a plumber. I wonder if they are nice ...

Google Maps is the reason I got a smartphone 14 years ago. I saw ...

With rootstock, I guess the main discomfort really does come from ...

I think I agree, it requires a modest amount of effort and a ...

On the one hand there's zero demand, and on the other hand ...

The Proposed Solution

Declaration of the Key Rotation Attestation List

Issue Key Rotation Attestations

Attestation Support

Consumption

Future Expansions of the Protocol

Conclusion

"Relay discovery is still a challenge." You could try AI ...

In this case I guess it's just a story that I read that was ...

I just saw this proposal for the first time, and I agree that ...

The Proposed Solution

Declaration of the Key Rotation Attestation List

Issue Key Rotation Attestations

Attestation Support

Consumption

Future Expansions of the Protocol

Conclusion

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

I've tried driving, skateboarding, riding a bicycle, using a ...

This generally makes sense to me, except I don't think that ...

Humans moving from memory to writing seems quite similar to what ...

One thing that currently bothers me about rootstock, just based ...

"you are guaranteed to agree with everyone who has been ...

I remembered this myth a few years ago and found it to be a ...

The discussion here justifies a bit Plato: . . . Socrates: Enough ...

I find it hard to figure out how to best use AI when creating my ...

You're right that a delegatee-signed 31065 only means ...

I wonder if the nostr double ratchet would benefit from being ...

I'm trying to wrap my mind around the Ethereum side of the ...

Thanks for the pointer, this is a nicely minimal design. One ...

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

https://music.youtube.com/watch?v=e2CliA8PuRM

One reason I'm pointing to the delegation tables and the ...

Not easily for this file, as it rather gets into the weeds. A ...

Ok so that's a more incisive question, and I guess it's a ...

So every few weeks nostr wonders if all the bitcoin talk on here ...

The AI Search tool at https://www.inkan.cc is very good at ...

I'm trying to promote this AI-based search tool I made. ...

screenshots 👇 #nevent1q…vjgc

In the same way in which light bulbs made it, or rubber tires.

12.1 Kind `31045`: Bitcoin timestamp

12.2 Kind `31065`: Attributed profile

12.3 Kind `31066`: Re-ratification declaration

12.1 Kind `31045`: Bitcoin timestamp

12.2 Kind `31065`: Attributed profile

12.3 Kind `31066`: Re-ratification declaration

12.1 Kind `31045`: Bitcoin timestamp

12.2 Kind `31065`: Attributed profile

12.3 Kind `31066`: Re-ratification declaration