Nostr notes by

This is likely the least of concerns, WoT hides interactions from ...

2026-11-14T03:40:51Z

In reply to nevent1q…6x34
_________________________

This is likely the least of concerns, WoT hides interactions from outside of your network… but discovery is close to non existent.

There is no “algorithm” to pick up influencers posts and deliver them to random people.

Nostr event nevent1qqs9c0rxfgnkgk46nh8gjruhttzq8q8ry246vzghxja23us8udh44hspz3mhxue69uhhyetvv9uju6twddskutnrvvpzp2a2p8dtrlplllq5p87m9zcnsvkdgqchqnzd7cvc2f0606jxd0kjxsjjmj

2026-11-14T03:12:38Z

In reply to nevent1q…7hy2
_________________________

nevent1qqs2xwfvm89jl8rrvydcse27mrr3u33vku4f7ng5th62u4khxx9c4eszyq9uwwpv0arsj9zfy9r6w9a8ac6e48ftetgjq6jqksarsyvcnc0j5qcyqqqqqqga54z5s

By the way, here is a working delegation mechanism that has been ...

2026-11-13T15:01:58Z

In reply to nevent1q…g7qj
_________________________

By the way, here is a working delegation mechanism that has been in use for a while, and which:

1. doesn't require lending your key to others (you can keep it in a safe deposit box);

2. doesn't break the network (other people don't have to know you've set up the delegation mechanism, unless of course they actually want to interact with your cold storage identity; that's just like other people don't need to know that you're using DMs, unless they actually want to send you a DM);

3. is not arcane / stupid (see draft NIP below 👇).

If you'd like to try it out, you can get a "Toy Identity" through the wizard on the homepage at https://www.inkan.cc.

quoting
naddr1qv…zjnp

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`

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.

note1qqq2adl3ejz0t56tyxnspmhumw437u88u9gfyuf6htt5escq56mqfqf2vl

2026-11-13T13:34:04Z

In reply to nevent1q…c6sp
_________________________

note1qqq2adl3ejz0t56tyxnspmhumw437u88u9gfyuf6htt5escq56mqfqf2vl

Hm, you should be seeing it though, NV says it’s mirrored… ...

2026-11-13T13:33:19Z

In reply to nevent1q…zgdu
_________________________

Hm, you should be seeing it though, NV says it’s mirrored…

Because it is nothing but (what appears to be) a JWT, and the whole npub posts nothing but notes just like that.

And then there are other npubs doing a similar kind of spam, but with a stringfied json payload once again identified as kind: 1.

This is clearly an abuse of the protocol, which serves no purpose other than to benefit some bad actors over the community at large.

She looks more racially confused than a fucking Brazilian

2026-11-13T03:05:04Z

In reply to nevent1q…y2dh
_________________________

She looks more racially confused than a fucking Brazilian

Prostitution

2026-11-12T21:21:17Z

In reply to nevent1q…q72r
_________________________

Prostitution

Have you forgotten what the oldest profession is?

2026-11-12T16:40:56Z

In reply to nevent1q…qmtn
_________________________

Have you forgotten what the oldest profession is?

Hey the blood supply is limited.

2026-11-12T16:33:50Z

In reply to nevent1q…v6ar
_________________________

Hey the blood supply is limited.

> I just think what suits the protocol best is playing games ...

2026-11-12T16:32:57Z

In reply to nevent1q…grfy
_________________________

> I just think what suits the protocol best is playing games with your friends.

I think nostr kind of works like a permissionless lobste.rs. In that sense public discourse and making new friends is not impossible.

I fail to be scandalized by this, it actually seems more ...

2026-11-12T16:27:59Z

In reply to nevent1q…7ctu
_________________________

I fail to be scandalized by this, it actually seems more remarkable that this kind of thing would affect people's investment decisions. One more reason to not entrust such decisions to an advisor. Different wiring I guess.

Meanwhile, the confident couples: “Honey, look at that ass” ...

2026-11-12T16:16:40Z

In reply to nevent1q…6dz5
_________________________

Meanwhile, the confident couples:
“Honey, look at that ass”
“Hot damn”

Hi.

2026-11-12T13:11:19Z

In reply to nevent1q…r7j0
_________________________

Hi.

I believe you are doing what people call “projection”.

2026-11-12T12:22:05Z

In reply to nevent1q…jaas
_________________________

I believe you are doing what people call “projection”.

Nostr event nevent1qqs2xzpl6grnf8pdrstpdvdwc33f0hdlnv8693hknztfa9vl6elqjjcpz3mhxue69uhhyetvv9uju6twddskutnrvvpzqanzqr60vndz7ywln873awyne6tkakncnll6k5mcsy6ccklqmgzzds5p7m

2026-11-11T18:58:57Z

https://www.zonaautonoma.org/bludit/gesti%C3%B3n-de-billeteras-bitcoin-safe

Wallet para multisig y coordinación psbt via nostr

You get the same benefits as tokio (cooperative threading) from ...

2026-11-11T18:09:10Z

In reply to nevent1q…lykj
_________________________

You get the same benefits as tokio (cooperative threading) from other kinds, “non cooperative”, userspace threading solutions like BEAM, jvm, go routines…

What drives the cost of kernel context switching is most likely dropping caches, tracking a bigger object (so it has a bigger stack to save and restore), spectre mitigations, crossing the userspace-kernelspace barrier and stuff like that.

FYI, for key management, rotation and recovery, you can get these ...

2026-11-11T18:02:54Z

In reply to nevent1q…nehu
_________________________

FYI, for key management, rotation and recovery, you can get these here 👇

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.

I'm happy to help with making a toy identity if you'd like to try it out. Also here is the draft NIP:

quoting
naddr1qv…zjnp

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`

>be this guy >bitch that nobody is seeing replies sent by ...

2026-11-11T17:24:53Z

>be this guy
>bitch that nobody is seeing replies sent by primol users
>have the reason explained in a way that even people with room temperature IQ would understand that the issue is Primal
>be angry at reality

quoting
nevent1q…dy9x
Didn't ask, stop wasting my fucking time with random shit

Would you look at that, Jumble does the sane thing and actually ...

2026-11-11T16:13:37Z

In reply to nevent1q…d3ye
_________________________

Would you look at that, Jumble does the sane thing and actually sends your notes into the inbox relays of the person you are replying to!

Yep, and to port shit away from Linux.

2026-11-11T16:12:02Z

In reply to nevent1q…c4l0
_________________________

Yep, and to port shit away from Linux.

If you look closely, you will notice that your beloved Primol ...

2026-11-11T16:05:56Z

In reply to nevent1q…jxar
_________________________

If you look closely, you will notice that your beloved Primol isn’t bothering with sending your replies into the inbox of the people you are replying to, instead they only write your note into their own relay (and they don’t even bother sending to the relays you have set as your preferred outbox).

This is a Primal problem, not a nostr problem (for once).

Fuck this shit man, I want the illusions back!

2026-11-11T15:12:46Z

In reply to nevent1q…0zvd
_________________________

Fuck this shit man, I want the illusions back!

I would much rather have an edit button like any normal human.

2026-11-11T15:09:15Z

In reply to nevent1q…jzjq
_________________________

I would much rather have an edit button like any normal human.

“Alleged Intelligence” I am stealing this :PepeLaugh: ...

2026-11-11T15:01:26Z

“Alleged Intelligence” I am stealing this :PepeLaugh:

quoting
nevent1q…ztem
[1/2] https://www.theguardian.com/technology/2026/oct/18/anthropic-ai-worm-worries

The latest feat of Alleged Intelligence is an internet worm that infects "smart" devices. "Smart" is marketing speak for products designed to be remote controlled, primarily by the manufacturer but secondarily by the purchaser and the purchaser's friends and associates, all of whom will be snooped on. They are the ideal prey for conversion into a botnet. Then someone other than the manufacturer can exercise

One of the safest and fastest microkernels out there. ...

2026-11-11T14:40:13Z

In reply to nevent1q…hszq
_________________________

One of the safest and fastest microkernels out there. Capabilities based, hard realtime/first class mixed criticality support, formally verified and probably being used by drones to bomb children right now. So you know it’s good.

@npub1gcx…nj5z

2026-11-11T13:05:21Z

In reply to nevent1q…wz5z
_________________________

VitorPamplona (npub1gcx…nj5z)

Seeing as Linux is full of shit and clankers are good at maths, ...

2026-11-11T13:01:09Z

Seeing as Linux is full of shit and clankers are good at maths, isn’t it better to point them at something formally proven like seL4?

quoting
nevent1q…qru6
👀

Nostr event nevent1qqszxpaqpnfwrrmctj3c5mqmll2cprgtfpgrxd2c36ndn59fx2ujw8qpz3mhxue69uhhyetvv9uju6twddskutnrvvpzqanzqr60vndz7ywln873awyne6tkakncnll6k5mcsy6ccklqmgzztf7wev

2026-11-11T03:04:59Z

https://www.zonaautonoma.org/bludit/corporativismo-vigilante-palantir-en-las-sombras-de-las-democracias

el panopticon se asoma.

Gonna use this as my tinder profile picture from now on

2026-11-11T01:23:21Z

In reply to nevent1q…m9pk
_________________________

Gonna use this as my tinder profile picture from now on

I would assume it is mostly cpu bound

2026-11-10T15:51:13Z

In reply to nevent1q…q8m7
_________________________

I would assume it is mostly cpu bound

WORD5 #767 5/6* (Hard Mode) ⬛⬛⬛⬛⬛ ⬛⬛⬛⬛⬛ ...

2026-11-10T15:39:08Z

WORD5 #767 5/6* (Hard Mode)

⬛⬛⬛⬛⬛
⬛⬛⬛⬛⬛
🟪🟧🟪⬛⬛
🟪🟪🟪⬛🟪
🟪🟪🟪🟪🟪

https://otherstuff.ai/word5/

the last one fork was ...

2026-11-09T15:08:10Z

In reply to nevent1q…js3t
_________________________

the last one fork was https://github.com/codonaft/zapthreads-codonaft
what you needed it for?

Yeah, most useful for the paranoid hosting static blogs and stuff

2026-11-09T14:56:21Z

In reply to nevent1q…lph3
_________________________

Yeah, most useful for the paranoid hosting static blogs and stuff

Foi mal galera, confundi com a minha esposa porque asiático é ...

2026-11-09T14:54:46Z

In reply to nevent1q…r9st
_________________________

Foi mal galera, confundi com a minha esposa porque asiático é tudo igual

Franzap before zapstore (Is that comment things?)

2026-11-09T14:54:31Z

In reply to nevent1q…3vwv
_________________________

Franzap before zapstore (Is that comment things?)

Nostr event nevent1qqsvf4ay8nas78umjlw4z3jsy550fzkt6a2kjwcl089juu4k99xn8jcpz3mhxue69uhhyetvv9uju6twddskutnrvvpzp2a2p8dtrlplllq5p87m9zcnsvkdgqchqnzd7cvc2f0606jxd0kj263w2j

2026-11-09T14:51:48Z

Has anyone tried making a nostr based disqus clone? #asknostr

What about beach volleyball?

2026-11-09T14:31:00Z

In reply to nevent1q…5l2u
_________________________

What about beach volleyball?

It kinda works.

2026-11-09T13:17:31Z

In reply to nevent1q…yh86
_________________________

It kinda works.

You sound like an asian parent

2026-11-09T13:15:38Z

In reply to nevent1q…3r8u
_________________________

You sound like an asian parent

Maybe he got confused because they all look alike ...

2026-11-09T12:23:06Z

In reply to nevent1q…f63x
_________________________

Maybe he got confused because they all look alike

Nostr event nevent1qqsz7mw05j8knqevspmhrytdtusmdlygy9jkgttsqgucnsm8y6naptqpz3mhxue69uhhyetvv9uju6twddskutnrvvpzp2a2p8dtrlplllq5p87m9zcnsvkdgqchqnzd7cvc2f0606jxd0kj9qqkrh

2026-11-08T00:46:54Z

In reply to nevent1q…sj42
_________________________

Only seeing this now because you quoted it…

2026-11-07T22:51:34Z

In reply to nevent1q…4ma0
_________________________

Only seeing this now because you quoted it…

@npub1utx…50e8 explain that, atheists

2026-11-07T01:56:04Z

In reply to nevent1q…p8qg
_________________________

utxo the webmaster 🧑‍💻🍁 (npub1utx…50e8) explain that, atheists

Nostr event nevent1qqsw9g52wxy763qdfk0tzg7r4ckq95z9vshvtxz9mv6lu9l9904ff6qpz3mhxue69uhhyetvv9uju6twddskutnrvvpzqanzqr60vndz7ywln873awyne6tkakncnll6k5mcsy6ccklqmgzztvg7mc

2026-11-07T00:48:10Z

https://www.zonaautonoma.org/bludit/acomodando-la-mesa-en-nostr

Don't nuke plox!

What happened to homophobic rendering? Seems like every ...

2026-11-07T00:14:13Z

In reply to nevent1q…xe5f
_________________________

What happened to homophobic rendering?

Seems like every JavaScript framework under the sun supports that shit, it basically makes SSR and then switches to CSR right after the page loads.

PS: I know it is called isomorphic, just let me have some fun

Someone should tell the Best Korea to try #FIPS with nostrvpn.org ...

2026-11-07T00:03:49Z

Someone should tell the Best Korea to try #FIPS with nostrvpn.org

NIP-44 support (or lack of).

2026-11-06T19:07:28Z

In reply to nevent1q…3y2r
_________________________

NIP-44 support (or lack of).

That’s weird… ...

2026-11-06T18:39:13Z

In reply to nevent1q…ahaa
_________________________

That’s weird…

Nw, my daily driver is an iPhone, the android is a moto g with a ...

2026-11-06T16:53:32Z

In reply to nevent1q…7kj5
_________________________

Nw, my daily driver is an iPhone, the android is a moto g with a busted screen I have to remote desktop into… not sure I can upgrade that.

That would be half of my notes sir

2026-11-06T14:52:06Z

In reply to nevent1q…jqed
_________________________

That would be half of my notes sir