Nostr notes by

I’ve noticed that Social Media in general tends, at least in my ...

2026-08-21T12:01:48Z

In reply to nevent1q…2lg4
_________________________

I’ve noticed that Social Media in general tends, at least in my experience tend to react more likely to posting centered around Western Europe/Eastern America.

In PST (California) time that’s around 03:30 (3:30 am), 11:00 (11:00 am), & 15:00 (3:00 pm)

In EDT, it’s

6:30 (6:30 am), 14:00 (2:00 pm), and 18:00 (6 pm)

I don’t know how to translate that into other timezones because ‘Merica but hope that helps.

Nostr event nevent1qqsqc22t99djgx07d9mcnaftl2g6d880tqfmynarsw28z2hlp2y5jlcprpmhxue69uhkummnw3ezumrpdejz7atwd9nx7undqgsqc3wh630dkradmfppt5mv5rv6hgx8wxu96dchwe9c5y5dtezrungqqlhh2

2026-08-21T12:10:23Z

Scarcity is a myth, abundance is a truth.

I’ve seen a few. It’s kind of a shame that the conceptually ...

2026-08-21T12:13:14Z

In reply to nevent1q…m4j2
_________________________

I’ve seen a few. It’s kind of a shame that the conceptually better version of ecash is so underdeveloped and unused.

Beautiful!

2026-08-21T12:11:41Z

In reply to nevent1q…m3km
_________________________

Beautiful!

Looks like some federations exist https://observer.fedimint.org/

2026-08-21T12:11:04Z

In reply to nevent1q…s4j6
_________________________

Looks like some federations exist https://observer.fedimint.org/

Nostr event nevent1qqsprp379spy56g7nt7xnzhypg46jvaze8gudzagrm5ec07nl78j3aqprpmhxue69uhkummnw3ezumrpdejz7atwd9nx7undqgsqc3wh630dkradmfppt5mv5rv6hgx8wxu96dchwe9c5y5dtezrungfwra08

2026-08-21T12:06:04Z

Work is a redundant, & archaic boomer mindset.

Shoulders & Arms AMRAP: Overhead Press x6, Bent Over Row x6, ...

2026-08-21T12:06:11Z

Shoulders & Arms
AMRAP: Overhead Press x6, Bent Over Row x6, High Pull x6
AMRAP: Lawn Mower Row x8, Overhead Press x8
AMRAP: Zottman Curl x6, Tricep Kickback x8
AMRAP: Lateral Raise x5, Bicep Curl x5

Low impact
#proofofwatts #365days

😂

2026-08-21T12:04:22Z

In reply to nevent1q…70fz
_________________________

😂

PV and GM plebs! TGIF. #plebchain #coffeechain ...

2026-08-21T11:57:50Z

PV and GM plebs! TGIF. #plebchain #coffeechain

GM & PV #nostr ...

2026-08-21T11:56:36Z

GM & PV #nostr

How I feel when the Internet loses my old mommy-blog posts and ...

2026-08-21T11:56:04Z

In reply to nevent1q…rxvl
_________________________

How I feel when the Internet loses my old mommy-blog posts and Google search drops my teenage selfies.

Alright, changed the provider to Rizful. Still getting the same ...

2026-08-21T11:55:16Z

In reply to nevent1q…zs7j
_________________________

Alright, changed the provider to Rizful. Still getting the same error, but maybe the change hasn't propagated yet across relays. I'll try again this afternoon.

@npub180c…h6w6 You're going to make me handle 30818 and 11 ...

2026-08-21T11:54:54Z

fiatjaf (npub180c…h6w6) You're going to make me handle 30818 and 11 djot markup, aren't you?

Good morning 🌞 even Princess Aurora wants to sleep in today ...

2026-08-21T11:53:39Z

Good morning 🌞 even Princess Aurora wants to sleep in today 🥱

People who make Nostr about “earning money” aren’t ready ...

2026-08-21T11:50:17Z

In reply to nevent1q…m3lg
_________________________

People who make Nostr about “earning money” aren’t ready for Nostr.

Nostr is about the ability to shitpost to your heart’s content.

I had dabbled with making something similar to ColdIron as an ...

2026-08-21T11:48:27Z

In reply to nevent1q…9cyq
_________________________

I had dabbled with making something similar to ColdIron as an airgapped place to create Nostr identities and sign key delegation and revocation transactions.

I didn't go about it as thoroughly as you seem to have done. I basically started with Tails OS, asked an AI to strip out network functionality, and added the Inkan Management Utility, resulting in this:

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

I wonder whether the Management Utility would run inside ColdIron. I may take a closer look.

Even if someone broke in and stole your machine, you’d still ...

2026-08-21T11:48:19Z

In reply to nevent1q…ut6j
_________________________

Even if someone broke in and stole your machine, you’d still have time to recover everything with the mnemonic and SCB. They’d just get a computer with nothing useful on it.

Timezones

2026-08-21T11:46:51Z

In reply to nevent1q…z5tn
_________________________

Timezones

Friday vibes https://v.nostr.build/vhbzbaO0LgIAWsUx.mov

2026-08-21T11:40:13Z

Friday vibes

No. I’m here for the technology, and ability to transact ...

2026-08-21T11:40:06Z

In reply to nevent1q…zunk
_________________________

No.

I’m here for the technology, and ability to transact without banks, governments, and institutions.

I will be honest greed was a motivator at first but the more I learned about crypto, finance, money, investing, and economics, the more I realized that Bitcoin should be a currency, and not a commodity/asset.

Friday advice https://v.nostr.build/PWgmciSGuCN2flNF.mp4

2026-08-21T11:38:56Z

Friday advice

Nostr event nevent1qqsqqqptkp2989q9klg2uyn0thu7tny3kpgj623e9fcmtrxjys653kgprpmhxue69uhkummnw3ezumrpdejz7atwd9nx7undqgsrc4vssrmywp62vw8fe3k5cjr6q6l6hqgyq24tnfnef76f5pf320se5uaxx

2026-08-21T11:36:39Z

@npub1n0s…lahe would it be possible to have an appearance ...

2026-08-21T11:33:39Z

Fabian (npub1n0s…lahe) would it be possible to have an appearance setting to change the size of the text in Nostur (npub1n0s…k6h0) ?

Mine. @nprofile…e43h

2026-08-21T11:17:19Z

In reply to nevent1q…twvp
_________________________

Mine.

Kräftig (nprofile…e43h)

Anybody can check that every member in a ring signature is a ...

2026-08-21T11:13:14Z

In reply to nevent1q…ewk2
_________________________

Anybody can check that every member in a ring signature is a valid ouput existing on the chain (membership).

They don't need to know which one is the true spend (unlinkability).

And, yet, we're talking to each other. 🤔 Magic 🪄 ...

2026-08-21T11:09:43Z

In reply to nevent1q…7r54
_________________________

And, yet, we're talking to each other. 🤔

Magic 🪄

All religion has love, yet love has no religion

2026-08-21T11:09:16Z

In reply to nevent1q…gywd
_________________________

All religion has love, yet love has no religion

Sounds very intresting. I hope to test this in the future. Thanks ...

2026-08-21T11:08:50Z

In reply to nevent1q…dqj3
_________________________

Sounds very intresting. I hope to test this in the future. Thanks for propagating.
When this works somehow, I am very happy.

gm nostr ☕️☀️ it’s a beautiful day, go out and share it ...

2026-08-21T11:08:49Z

gm nostr ☕️☀️ it’s a beautiful day, go out and share it with someone

Enjoy your walk.

2026-08-21T11:08:12Z

In reply to nevent1q…f388
_________________________

Enjoy your walk.

be that guy #nevent1q…3f2s

2026-08-21T11:06:22Z

be that guy

quoting
nevent1q…3f2s
you have a bug that's really hard to reproduce. the whole team is banging their head against it, trying various fixes, nothing works. but there's this one guy who comes in, slowly makes himself a coffee, calmly looks at everything, maybe asks a question or two, and after that sits down for five minutes at his desk. he pushes a few commits. bug fixed. you always need that guy. and i'm happy to pay premium tokens for that guy.

the more things change, the more they stay the same

The difference between me and you is that I know what I'm ...

2026-08-21T11:05:24Z

In reply to nevent1q…h0kt
_________________________

The difference between me and you is that I know what I'm talking about
and your autistically reeeeing "SHITCOINER" because you saw someone mention Monero.

Tell me why monero is a shitcoin.

I'll wait.

😂

2026-08-21T11:04:38Z

In reply to nevent1q…7vwn
_________________________

😂

😂

2026-08-21T10:55:34Z

In reply to nevent1q…mhjk
_________________________

😂

And break interoperability with every other client?

2026-08-21T11:04:23Z

In reply to nevent1q…ckg3
_________________________

And break interoperability with every other client?

Nostr event nevent1qqsqqqq29qvexqrjw34ge9h4gpx5akugd28tf8lqljdk8mpmcd9p9qqprpmhxue69uhkummnw3ezumrpdejz7atwd9nx7undqgswum4p82uluhz2dr40nvdrflspffntgqghc58w9fs57nx6jkdkuaq2mcmrz

2026-08-21T10:58:23Z

In reply to nevent1q…xenw
_________________________

Publishing from NostrHub doesn't seem to work, even after I ...

2026-08-21T10:58:09Z

In reply to nevent1q…nzmp
_________________________

Publishing from NostrHub doesn't seem to work, even after I set my relay list.

Thanks, posting NIPs through NostrHub seems to be broken. I was ...

2026-08-21T10:56:33Z

In reply to nevent1q…r9vx
_________________________

Thanks, posting NIPs through NostrHub seems to be broken. I was able to publish a 30817 through your imwald client, here it is:

quoting
nevent1q…8859
`draft` `optional`

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

## 1. How it works

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

## 2. Delegations between keys

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

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

## 3. How a direct delegation is created

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

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

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

## 4. How a direct delegation is terminated

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

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

## 5. Permanent key invalidation

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

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

## 6. Delegation timelines

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

## 7. Bitcoin timestamping of events

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

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

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

## 8. Attribution of events

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

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

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

## 9. Two profiles, one identity

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

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

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

## 10. Event kinds

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

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

### 10.1 Kind `31045`: Bitcoin timestamp

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

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

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

### 10.2 Kind `31065`: Attributed profile

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

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

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

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

## 11. Reference implementation

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

not in an ancient sense, but somehow. people don't care who ...

2026-08-21T10:23:42Z

In reply to nevent1q…tyyz
_________________________

not in an ancient sense, but somehow. people don't care who sits in the iron throne as long as the circumstances don't devastate their life

Day 233 🌻 ✨ "Gratitude is the best attitude." — ...

2026-08-21T10:40:18Z

Day 233 🌻

✨ "Gratitude is the best attitude."
— Anonymous

💫 "I am grateful for my unique gifts and talents."

🙏 Grateful for the teachings of the Stoics and the foundation of all philosophy.

https://gratefulday.space

Nostr event nevent1qqsqqqrml56zw7yv692e7pjgu9qxx5uzwmwjzezrg9exw87ndlyqjwcprpmhxue69uhkummnw3ezumrpdejz7atwd9nx7undqgsz72d2x0p28dzu9mejyy58jfyt9a9yngqzh5x7p7ske98p8zkx7ycyuk3mx

2026-08-21T10:22:23Z

are we having fun again fam?

yes. always

2026-08-21T10:21:27Z

In reply to nevent1q…tyyz
_________________________

yes. always

Nostr event nevent1qqsyf5hwxylk79wrc6cejv0tm8yew07c2eea5dp2jgv3qkkafqufm3qprpmhxue69uhkummnw3ezumrpdejz7atwd9nx7undqgsd6ejdteqpvse63ntf7qz6u9yqspp4z7ymt8094urzwm0x2ceaxxgjwlm0w

2026-08-21T10:16:56Z

https://www.welt.de/politik/ausland/article6a87e36489ff002330aa1d83/usa-spekulationen-um-trumps-assistentin-so-reagiert-melania.html

Melania Trump has reappeared, to quell speculation that Donald has replaced her with Natalie.

quoting
nevent1q…rzf6
It's funny how we all started talking about Natalie, but nobody noticed Melanie going AWOL.

Been watching people complain about the dating pool for 25 years, ...

2026-08-21T09:49:42Z

In reply to nevent1q…ewae
_________________________

Been watching people complain about the dating pool for 25 years, now. 🍿
The selection doesn't seem to improve, the longer you wait.

This thread is full of men who want a tradwife whose only ...

2026-08-21T09:43:00Z

In reply to nevent1q…jd54
_________________________

This thread is full of men who want a tradwife whose only emotional tools are bottle it up and ignore it. Less inconvenient for them so who cares what it does to her mental health over time.

Nostr event nevent1qqsp0xugfd4332s6dyfsek4rz5hpmx7nwmwckwzpy4ayajfmakr8x9qprpmhxue69uhkummnw3ezumrpdejz7atwd9nx7undqgsph3c2q9yt8uckmgelu0yf7glruudvfluesqn7cuftjpwdynm2gygmr7vwd

2026-08-21T09:42:57Z

How to scrub your web history ...

2026-08-21T09:39:40Z

How to scrub your web history

WORD5 #686 3/6* (Hard Mode) ⬛🟪🟧⬛🟧 ...

2026-08-21T09:33:51Z

WORD5 #686 3/6* (Hard Mode)

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

https://otherstuff.ai/word5/

Very sad to see this. I think eventually this will be corrected. ...

2026-08-21T09:21:58Z

In reply to nevent1q…3900
_________________________

Very sad to see this. I think eventually this will be corrected. But I do not want to think about the consequences to our societies. So much trust in so much evidence for coercion -.-

Oh Mara, is that you?

2026-08-21T09:20:40Z

In reply to nevent1q…nfq9
_________________________

Oh Mara, is that you?