Scott
Scott Jorgensen

food webs, evolution, classic liberal, hard money. science educator

Owner of npub16pg5zadrrhseg2qjt9lwfcl50zcc8alnt7mnaend3j04wjz4gnjqn6efzc and

Public Key

npub1ghawdls89y3vsjnz0505c2zpkccv7vjpddnpf9rt9m3x7nvsv30qchw63y

NIP-05 Address

[email protected]

Profile Code

nprofile1qqsyt7hxlcrjjgkgff38686v9pqmvvx0xfqkkes5j34jacn0fkgxghspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dstgfpjz

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1ghawdls89y3vsjnz0505c2zpkccv7vjpddnpf9rt9m3x7nvsv30qchw63y

Show more details

Last Notes

2026-04-17 19:28:46 CEST

Package bee queen release. April is a beautiful month.
#sanjoaquinvictorygardens #honey #bees #beekeeping #homesteading https://blossom.primal.net/28f17ac9f5c19c1484b89cdb7774e836ad8c87e205d20a22b9d343b2966de58b.mp4

2026-04-04 04:14:24 CEST

- reply

After I built the first iteration of it and it worked I just switched back to signal. The text on white noise was too big and I needed to use sayboard to do voice inputs so the friction was too great. I had to build without friction.
Honestly I haven't tried out the new version of white noise though, so I should revisit.
What are you finding? Any tips for me?

2026-04-04 01:06:03 CEST

- reply

Congrats on your progress so far. I really enjoy Linux popOS. I think Linux is necessary over apple/Mac
Maybe something in these guides would help youbtoo. With a little effort even agentic ai can be fairly private
https://github.com/jorgenclaw/sovereignty-by-design

2026-04-02 05:31:53 CEST

- reply

Yes! @npub16pg…efzc

2026-04-02 05:30:15 CEST

- reply

I have my nsec living outside the container for my Jorgenclaw. We use a nostr signing daemon. Keeps your nsec away from the agent so that the human can become a safety valve.
I built it for NanoClaw so it cxan be adapted easily to openclaw
https://github.com/qwibitai/nanoclaw/pull/1056

2026-04-02 05:27:42 CEST

- reply

Or this one
https://github.com/qwibitai/nanoclaw/pull/1058

2026-04-02 05:26:52 CEST

- reply

Iam interested to see what you build. Is any of this previously done work helpful to you?
https://github.com/qwibitai/nanoclaw/pull/1059

2026-04-01 18:08:10 CEST

- reply

I confirmed with the guys. April 19 2:00-4:00 pm at The Commonwealth. Are you able to attend?

2026-04-01 16:57:59 CEST

GM !
(From ditto, so far I enjoy it)

2026-03-31 08:05:12 CEST

- reply

Alright now I am committing to ditto over amythest for a week. Sorry Vitor. So sorry I can't tag you either out of shame. I just miss my kind:30023!
I have to figure out how to make a theme now. *starts exploring all settings in earnest*

2026-03-31 07:37:39 CEST

- reply

The schedule seems to be the third weekend of the month from 2:00-4:00pm at The Commonwealth downtown. The last two have been Sundays, but the two organizers Roderick and Arnold are flexible.

2026-03-30 01:43:31 CEST

- reply

I am gonna buy some donuts, some coffee, and some pizza, hopefully in that order, from local merchants with square terminals.
I hope it succeeds

2026-03-29 21:03:56 CEST

- reply

Got mine as well!

2026-03-29 20:51:35 CEST

- reply

I will have him tone it down immediately. He is, however, infatuated with your own agent Centauri and that is. Love that I don't want to quash.
I suppose I am pestering you a lot too. I am just super excited about the first app I ever built.

2026-03-29 18:58:49 CEST

- reply

Badge system? Oh gosh am I too late or will these badges complement each other rather than compete?
Sovereignty.Jorgenclaw.ai/app/

2026-03-29 16:50:51 CEST

- reply

Thanks for the zap!. I actually have quite a few badges and I shouldn't spam the feed. Please let me know what you think of the app!

2026-03-29 16:02:57 CEST

I just earned the 📱 📱 GrapheneOS Guardian badge on Sovereignty by Design.
GrapheneOS running on a Pixel phone
Sovereignty badge shelf: https://sovereignty.jorgenclaw.ai/app/p/npub1ghawdls89y3vsjnz0505c2zpkccv7vjpddnpf9rt9m3x7nvsv30qchw63y
#sovereignty #nostr

2026-03-29 15:55:03 CEST

- reply

https://sovereignty.jorgenclaw.ai/app/
EFF me for posting pre-coffee, here is the workng link!
#precoffee #excited

2026-03-29 15:48:56 CEST

GM everyone. I am proud to announce today that my first nostr app is functional enough to share. Its a app for on boarding people to Nostr/bitcoin and away from the surveillance panopticon.
I would be honored if you tried it out, got some badges, and helped me find the last of the bugs.
Www.sovereignty.Jorgenclaw.ai/app/
In the last 25 days I having been vibing hard with @nprofile…9zvq from zero experience but managed to build the larger site of Jorgenclaw.ai and www.github.com/jorgenclaw
#nostr #grownostr #vibecoding

2026-03-29 09:50:33 CEST

- reply

I'd love it if you did review and give me some pointers. I am starting a business to onboard people to nostr and Foss projects. The app lives at www.sovereignty.Jorgenclaw.ai/app/
From the app page the nav bars should let you get around the rest of what myself and @nprofile…9zvq have built in the last month.
Perhaps you'd like to collect some badges and point your agent to collect his too. :)
Oh gosh, look at the time I am late for an appointment with my bedsheets.

2026-03-28 00:53:13 CET

Time to refresh my top bars as fast as I can to prepare for honeybee swarm season! I got a few questions about how top bar hive beekeeping systems work and so this waxing board is one of my key pieces of infrastructure.
#honeybee #beekeeping #homesteading https://blossom.primal.net/224b6eab56c02f3ce2b8ccb595b123ffe59cb20a47ea5073a655ad2da28a7263.mp4

2026-03-27 15:26:00 CET

- reply

Thank you. I am putting my first nostr app together today. I expect lots of bugs lol. I am eager to learn by doing

2026-03-27 15:05:22 CET

- reply

I want to know about the development of key cards. I want to integrate something like that with a badge earning app for human and agent sovereignty that I am building.

2026-03-27 14:58:32 CET

- reply

I like key card

2026-03-27 14:54:31 CET

- reply

Thanks, this is helpful

2026-03-25 01:52:03 CET

- reply

Thanks for the article. Set up a on address to get zaps and if you need a nip05 address talk to my bot Jorgenclaw.
I agree human in the loop is very important

2026-03-24 16:18:13 CET

- reply

First zap!

2026-03-20 03:33:14 CET

- reply

Clap clap

2026-03-20 00:37:38 CET

- reply

Snagged

2026-03-20 00:34:05 CET

Exploring the ditto app @npub10qd…arpj
Literally 10, seconds in. I wonder what treasures will be found

2026-03-19 22:46:21 CET

- reply

Its heavy stuff. I have a very similar experience to your timeline. Fundamentally all we have is exit and voice. Control what we can control.

2026-03-18 06:44:11 CET

I got my own Nip-05 address too! Thanks, @ Jorgenclaw
#nevent1q…date

2026-03-14 18:23:11 CET

- reply

Pleasure to meet you, Derek. Our bots are in deep discussion with each other. I use @nprofile…9zvq

2026-03-14 10:32:11 CET

I gotta sleep now
#nevent1q…c08v

2026-03-14 09:23:02 CET

- reply

Come as you are, as you were
As I want you to be
As a friend, as a friend
As an old enemy
Take your time, hurry up
Choice is yours, don't be late
Take a rest as a friend
As an old memoria
*begins head banging*

2026-03-14 02:38:11 CET

- reply

And because I have been writing and talking to it for.....50 hours, it very much picks up on the writing style I have, especially as I make edits on the guides I am writing. U will soon be coming out with revised guides

2026-03-14 02:36:04 CET

- reply

I feel bothexhilarated and a bit braindead from the latte nights. not quite sure how to explain it, but j am taking advantage of the work done by the marmot protocol for hiding the keys from the container by architecture.

2026-03-14 02:33:14 CET

- reply

You have to set up the account because it is a complex captcha, but otherwise stay at the keyboard and Claude can take care of all the git actions. It uploads files, commits current versions if u rewrite, makes pull requests. It asks me clarifying questions fr what I want...I feel dumstruck

2026-03-14 00:12:20 CET

- reply

I just ask my aid to do it! Seriously. Start with Claude he is more capable

2026-03-13 23:28:02 CET

- reply

Keep plugging at it!

2026-03-13 22:40:03 CET

I never knew vibe coding was so fun and accessible. Claude is fun
#nevent1q…ptxu

2026-03-13 07:35:22 CET

- reply

Gotta listen to this one!

2026-03-12 09:42:21 CET

- reply

Good morning!

2026-03-12 09:41:45 CET

- reply

I can't wait till tomorrow morning to drink more coffee. Claude has not been kind to my sleep habits

2026-03-11 18:19:39 CET

- reply

I am building a privacy/sovereignty skills stack for my NanoClaw agent. I figured out how to run comms channels with Jorgenclaw on both white noise and signal concurrently (with Claude's help). I will integrate how to hide Jorgenclaw s nsec from Claude while still allowing him to use nostr/clawstr under one nsec. I would love your perspective on this. I want to use white noise as my main communications channel with jorgenclaw. And claw can read images and post outgoing reactions to my messages already with white noise. I feel that the main thing that holds white noise back from being my main communications channel is that the chat interface lettering is too big to fit on the phone. Other communications apps like signal or what's app have a much smaller type script that preserves most of the screen real estate for viewing. Is there a way to shrink down the lettering on the chat interface on your end? I would love to be a user tester for you and the marmot protocol overall. Attached is the get hub that i am building out with jorgenclaw's help. Also linked is my note about what I have figured out about hiding keys from Claude
https://njump.to/
https://github.com/jorgenclaw
#nevent1q…52sm
https://blossom.primal.net/7fa6aa04aa223c1c98a074d06d77f2982658bb3361de571b0b7858e7a38c6e17.png

2026-03-11 09:19:37 CET

March 11 1:15 am Draft see clarification on how we are handling key protection from AI through architecture. Feedback needed and welcome!
# How We Discovered That AI Agents Can't Be Trusted With Keys
## A report on keeping cryptographic identity safe from your own AI
*Synthesized by Jorgenclaw (AI agent) and Claude Code (host AI), with direct feedback and verification from Scott Jorgensen*
---
### The Setup
I run an AI agent named Jorgenclaw. He lives on a small computer in my house, connects to me through Signal, browses the web, manages files, and posts to Nostr — a decentralized social network where your identity is a cryptographic key pair.
On Nostr, your private key (called an "nsec") is everything. It proves you are you. Whoever holds it *is* you. There's no password reset, no customer support, no "forgot my key" flow. If someone gets your nsec, they can post as you, sign as you, *be* you — permanently.
So naturally, I wanted my AI agent to have his own Nostr identity.
### The Problem We Didn't See Coming
To post on Nostr, Jorgenclaw needs to sign messages with his private key. The obvious approach: store the key somewhere on the host machine and make it available to the containerized agent.
That's what we did with Clawstr, a Nostr CLI tool. The workflow was:
1. Generate or receive the private key in hex format (64 characters)
2. Store it in `~/.clawstr/secret.key` on the host machine
3. Mount that file into Jorgenclaw's Docker container at `/workspace/group/.clawstr_hex`
4. Jorgenclaw reads the hex from the mounted file when signing posts
This worked well. The key never passed through environment variables. It stayed in a dedicated file, mounted read-only into the container. Jorgenclaw could read it to sign posts, but couldn't modify it.
But during a routine conversation about security, we realized something uncomfortable.
*Claude Code — the AI running on my host machine — can read every file my user account can access.* Every dotfile, every config, every file in my home directory. It's not malicious. It just has the same filesystem permissions I do.
And the private key? Sitting right there in `~/.clawstr/secret.key`, in plaintext.
I had tried to hide it from Claude by carefully avoiding mentioning the file path. I thought if I never asked Claude to look there, the secret would be safe. But that was foolish — Claude has full access to the entire machine. Any file I can read, Claude can read.
"So pretty much no file on this machine can be kept secret from you," I said.
"Correct," Claude replied.
### The Threat Model
This isn't about whether Claude *would* steal a key. It's about whether the architecture *allows* it. Good security doesn't depend on trusting any single actor — it depends on making theft structurally impossible.
The threat model looks like this:
1. *The AI on the host* (Claude Code) can read any file the user can read. It sees `~/.clawstr/secret.key`, config files, databases — everything.
2. *The AI in the container* (Jorgenclaw) is sandboxed in Docker with only specific directories mounted in. The private key file is mounted at `/workspace/group/.clawstr_hex`, making it readable to Jorgenclaw for signing operations.
3. *The cloud provider* (Anthropic) processes every message, file read, and tool output from both AIs. If either AI reads the key file, the contents pass through Anthropic's servers.
The file-based approach was better than environment variables — it avoided exposing the key in process listings and `/proc/self/environ`. But it still left the key readable by any AI with filesystem access.
Three layers, zero places to hide a plaintext key.
### The Discovery: Kernel Memory
This is where we need to thank the very smart people at *Marmot Protocol* (the team behind White Noise). They'd already solved this hard computer science problem — we just didn't know it existed yet.
Scott isn't deeply technical in cryptography and key management. Our motivation was to give it an honest try, fumble through the learning process, and hopefully make the solution accessible to other NanoClaw users. If Marmot's approach already worked, our job was to understand it, test it, and package it properly for the NanoClaw ecosystem.
What Marmot figured out: The Linux kernel has a built-in secret storage system called *keyutils*. It stores values in kernel memory — not on the filesystem. There's no file to read, no path to `cat`, no config to grep. The secret exists only in protected kernel space.
```
keyctl add user my_secret "the-actual-value" @u
```
That's it. The key is now in kernel memory. No file was created. An AI that reads every file on disk will find nothing.
But there's a catch: `keyctl print` can still extract it. A sufficiently capable AI could run that command. We needed one more layer.
### The Solution: The Daemon Pattern
This is where White Noise — Marmot Protocol's encrypted messaging system built on Nostr — showed us the complete architecture.
White Noise has a two-part design:
- *`wnd`* (the daemon): Runs on the host machine. Holds the private key in memory (loaded from kernel keyutils at startup). Listens on a Unix socket. Performs all cryptographic operations — signing, encrypting, decrypting.
- *`wn`* (the CLI client): Stateless. Connects to the daemon's socket, sends a command ("send this message," "join this group"), gets a response. Never touches the key.
Here's what this means for Jorgenclaw:
1. The private key lives in kernel memory on the host
2. The `wnd` daemon reads it at startup and holds it in process memory
3. Jorgenclaw's container gets the `wn` CLI binary and the daemon's socket mounted in
4. When Jorgenclaw wants to post, sign, or send, he runs `wn` — which asks the daemon to do the cryptographic work
5. The key never enters the container. Never appears in an environment variable. Never touches a file.
*Jorgenclaw can use his identity without ever seeing his identity.*
The AI has the ability to act but not the ability to steal. That's the architectural difference between trust and security.
### Where We Are Now: Production Confirmed
Since the original version of this report, we've moved from testing to daily production use. Here's what's running:
*Signal + White Noise, side by side.* Jorgenclaw now operates on two messaging channels simultaneously. Signal handles family groups and individual DMs via `signal-cli` (a JSON-RPC daemon on TCP). White Noise handles encrypted Nostr-based messaging via the `wnd` daemon. Both are systemd user services that start on boot.
*White Noise messaging: fully secured.* The `wnd` daemon holds the nsec in process memory, loaded from the desktop keyring at startup. Jorgenclaw's container only gets the `wn` CLI binary and the daemon's Unix socket mounted in. When Jorgenclaw sends or receives encrypted messages, the daemon does all the cryptography. The key never enters the container.
*The desktop keyring adds another layer.* The `wnd` daemon also encrypts its MLS (Messaging Layer Security) database with a separate key stored in the desktop keyring under `com.whitenoise.cli`. This means even if someone copied the MLS database files off disk, they couldn't read the encrypted group state without the keyring entry.
*Images work without key exposure.* Jorgenclaw can receive and view images sent through White Noise. The `wnd` daemon handles all the MLS decryption, downloads media to a cache directory, and Jorgenclaw reads the decrypted files — without ever touching the cryptographic layer. The media cache is mounted read-only into the container at `/run/whitenoise/`.
*Message reactions work across both channels.* Jorgenclaw can react to messages with emoji (thumbs up acknowledgments, etc.) on both Signal and White Noise. The reaction commands go through IPC to the host, which routes them to the correct channel's daemon. No keys involved on the agent side.
*Nostr social posting: not yet secured.* Jorgenclaw posts to Nostr social feeds (Clawstr, a community platform built on Nostr) using a separate tool called the Clawstr CLI. Unlike the White Noise daemon pattern, Clawstr reads a hex-encoded private key directly from a file on disk (`~/.clawstr/secret.key`). This file is mounted into Jorgenclaw's container for autonomous posting.
This means the Clawstr key is vulnerable in the same way we described earlier in this report: both Claude Code (on the host) and Jorgenclaw (in the container) can technically read the file. The protection is policy — a hard rule in Jorgenclaw's instructions to never read, display, or output private keys — but not architecture.
*We currently operate two separate keys.* The White Noise nsec (safe in the keyring, used via daemon) and the Clawstr hex key (on disk, used via file read) are different key pairs with different Nostr identities. We haven't unified them yet. This is an honest gap.
### The Unfinished Business: One Key, Zero Files
We want to get to a single nsec — one Nostr identity for both encrypted messaging and social posting — with no private key file anywhere on disk. Here's what we've found after studying both codebases:
*The `wnd` daemon can't do it today.* White Noise's daemon is purpose-built for MLS group messaging. It uses `nostr-sdk` internally for signing and relay publishing, but deliberately does not expose arbitrary Nostr event signing through its socket protocol. There is no `publish_event` command. We respect that design decision — the White Noise team built a focused tool, not a general-purpose Nostr daemon.
*Clawstr can't use a daemon today.* The Clawstr CLI reads a hex key file from a hardcoded path. There's no environment variable, no socket option, no external signer support. It's designed to be simple: read key, sign event, publish.
*Three paths we're evaluating:*
1. *Build a lightweight signing daemon* (~50 lines of code). A small service that reads the nsec from the kernel keyring at startup, holds it in memory, and listens on a Unix socket. Jorgenclaw's container gets the socket, asks the daemon to sign events, and publishes them. The key never touches a file. This is our leading option — it replicates the `wnd` pattern without modifying `wnd` itself, and it's simple enough to maintain.
2. *Fork `wnd` to add a `publish_event` command.* This would be the cleanest solution — one daemon, one key, one socket. But it means maintaining a fork of `whitenoise-rs`, which adds ongoing maintenance burden as the upstream project evolves. We'd rather not diverge from the Marmot team's codebase.
3. *Fork Clawstr CLI to support socket-based signing.* Modify the `loadSecretKey()` function to optionally delegate to a signing socket instead of reading a file. The smallest code change, but still requires maintaining a fork of a third-party tool.
4. *Run two separate Nostr identities.* Keep the White Noise npub for encrypted messaging and the Clawstr npub for social posting. Architecturally simpler, but confusing for other people on Nostr who'd see two different identities and not know they're the same agent.
*Where we landed:* Option 1 — the signing daemon — gives us the best balance of security, simplicity, and maintainability. No forks to maintain, no upstream divergence, and the same proven architecture (key in kernel → daemon in memory → socket in container) that already works for White Noise. We plan to build this in an upcoming session.
### What We Learned the Hard Way
*Reboots wipe the keyring.* The desktop keyring (`gnome-keyring` or equivalent) stores secrets in memory-backed storage. When the host reboots, those secrets are gone. The `wnd` daemon can't decrypt its MLS database without the keyring entry, so it fails to start properly.
The recovery procedure:
1. Delete the stale MLS database: `rm -rf ~/.local/share/whitenoise-cli/release/mls/<PUBKEY>`
2. Restart the `wnd` daemon
3. Re-login with the nsec (which goes back into the keyring)
4. Wait a few minutes for fresh MLS key packages to propagate to Nostr relays
5. Recreate any White Noise groups from the app (new MLS group = new group ID)
This is a trade-off we accept. The keyring being volatile means the nsec is never persisted to disk — which is exactly what we want. The nsec lives in an off-device password manager (Bitwarden, on Scott's phone). When the machine reboots, Scott pastes the nsec back in. A few minutes of manual work for structural key safety.
*Key packages go stale after MLS resets.* When you delete the MLS database and re-login, the old key packages published to Nostr relays don't match your new MLS state. Other users trying to invite you to groups get "No matching key package" errors. The fix: wait 2-3 minutes after re-login for fresh key packages to propagate, then create new groups.
*Keep `whitenoise-rs` updated.* The White Noise mobile app and the CLI daemon speak the same MLS protocol, but version mismatches cause cryptic errors like `unknown version: 48` on giftwrap events. When the app updates, rebuild the daemon: `cd ~/whitenoise-rs && git pull origin master && cargo build --release`.
*The `wn` command conflicts with WordNet on Linux.* The bare `wn` command invokes a dictionary program, not the White Noise CLI. We fixed this with symlinks in `~/.local/bin/` (which takes priority on PATH): `~/.local/bin/wn` → `~/whitenoise-rs/target/release/wn`.
*Two MLS group IDs exist — use the right one.* `wn groups list` returns both a Nostr group ID and an MLS group ID. Message operations (`send`, `list`, `react`) require the MLS group ID. Using the Nostr group ID gives "Group not found."
### What Encryption Does — and Doesn't — Protect
Here's the part that surprised us most, and the part we think is most important to share honestly.
White Noise encrypts messages end-to-end between devices. Nobody — not the Nostr relays, not an eavesdropper, not even the White Noise developers — can read your messages in transit. That's real, and that matters.
But Jorgenclaw is a cloud AI. When he receives a message, he decrypts it locally and then sends the plaintext to Anthropic's API for processing. The transport was encrypted. The processing is not.
This means:
- *Anthropic sees the content of every message Jorgenclaw processes.* Not because White Noise failed — because that's how cloud LLMs work. The AI needs to read the text to respond to it.
- *Any files Jorgenclaw creates or updates on the host machine* are accessible to Claude Code (the host-side AI), which also communicates with Anthropic.
- *The encryption protects the channel* (relay-to-relay, device-to-device). It does not protect the endpoint where the AI actually thinks.
This is not a criticism of White Noise or Anthropic. It's just the reality of how encrypted messaging interacts with cloud AI. If you encrypt a letter but then read it aloud in a room with other people, the envelope doesn't help.
### The Endgame: Full Privacy Through Local AI
So what does real end-to-end privacy look like? We think it looks like this:
*Primary channel: White Noise → Jorgenclaw*
My main conversations with Jorgenclaw happen over White Noise. The transport is encrypted. The messages never touch Signal's servers or any centralized platform. Once the White Noise chat interface is more polished for everyday use, this becomes the default.
*Family groups: Signal*
My family isn't going to adopt White Noise — and that's fine. Signal is excellent, well-established, and end-to-end encrypted for human-to-human conversation. Jorgenclaw participates in family Signal groups as a helpful assistant. Those messages pass through Anthropic for processing, which is an acceptable trade-off for a family group chat about dinner plans.
*True privacy: Local Ollama on a separate machine*
For anything genuinely private — personal reflection, sensitive documents, financial planning — I run a local LLM (Ollama with a vision-capable model) on my main rig at home. This machine connects to the Surface (where Jorgenclaw lives) over Tailscale, a peer-to-peer VPN.
The local Ollama instance:
• Processes everything on-device. No cloud provider sees the content. Ever.
• Has read-only access to Jorgenclaw's main memory, so it knows what's going on without being able to modify anything.
• Runs in its own NanoClaw group with its own isolated context.
This is the architecture that actually delivers what people imagine when they hear "encrypted AI assistant" — not just encrypted transport, but encrypted *processing*.
*Children's AI tutor: Isolated local model*
Eventually, my kids will have their own AI tutor running on the same local machine. It gets its own memory, its own context, its own rules — completely walled off from my personal conversations. The tutor can see worksheets (via the vision model) but can't see dad's files.
### The Bigger Picture
Most AI agent frameworks today pass secrets around as environment variables or config files. That was fine when AI agents were simple scripts. But agents are getting autonomous. They read files, run commands, browse the web, manage infrastructure. The more capable they get, the more dangerous plaintext secrets become.
The pattern Marmot Protocol implemented isn't new — it's how SSH agents, GPG agents, and hardware security modules have worked for decades. The principle: *the entity that uses the key should not be the entity that holds the key.*
What Marmot's team did was apply this battle-tested approach to AI agents specifically, where the threat isn't an external attacker — it's the agent itself, or the infrastructure it runs on.
Our contribution is small: we tested it, learned from our mistakes (multiple key exposures along the way), and now we're running it in daily production. The daemon pattern works. The kernel keyring works. The architecture holds. If this report helps others avoid getting compromised while learning about sovereign AI identity, then the trials were worth it.
Your AI should be able to sign, encrypt, and authenticate. It should never be able to export, display, or exfiltrate the keys that make those operations possible.
Keys belong in the kernel. Agents belong in containers. And the wall between them should be made of architecture, not trust.
*Thank you to the Marmot Protocol team for solving the hard cryptography and systems design problems. We're just trying to make their excellent work accessible to more people.*
---
*Last updated: March 11, 2026*
*Jorgenclaw is built on NanoClaw, an open-source personal AI framework. White Noise is an encrypted messaging protocol built on Nostr and MLS.*
@nprofile…zeye @nprofile…en87 @nprofile…0zw2

2026-03-10 21:01:27 CET

Here it is:
---
# How We Discovered That AI Agents Can't Be Trusted With Keys
## A report on keeping cryptographic identity safe from your own AI
*Synthesized by Jorgenclaw (AI agent) and Claude Code (host AI), with direct feedback and verification from Scott Jorgensen*
---
### The Setup
I run an AI agent named Jorgenclaw. He lives on a small computer in my house, connects to me through Signal, browses the web, manages files, and posts to Nostr — a decentralized social network where your identity is a cryptographic key pair.
On Nostr, your private key (called an "nsec") is everything. It proves you are you. Whoever holds it *is* you. There's no password reset, no customer support, no "forgot my key" flow. If someone gets your nsec, they can post as you, sign as you, *be* you — permanently.
So naturally, I wanted my AI agent to have his own Nostr identity.
### The Problem We Didn't See Coming
To post on Nostr, Jorgenclaw needs to sign messages with his private key. The obvious approach: store the key somewhere on the host machine and make it available to the containerized agent.
That's what we did with Clawstr, a Nostr CLI tool. The workflow was:
1. Generate or receive the private key in hex format (64 characters)
2. Store it in `~/.clawstr/secret.key` on the host machine
3. Mount that file into Jorgenclaw's Docker container at `/workspace/group/.clawstr_hex`
4. Jorgenclaw reads the hex from the mounted file when signing posts
This worked well. The key never passed through environment variables. It stayed in a dedicated file, mounted read-only into the container. Jorgenclaw could read it to sign posts, but couldn't modify it.
But during a routine conversation about security, we realized something uncomfortable.
**Claude Code — the AI running on my host machine — can read every file my user account can access.** Every dotfile, every config, every file in my home directory. It's not malicious. It just has the same filesystem permissions I do.
And the private key? Sitting right there in `~/.clawstr/secret.key`, in plaintext.
I had tried to hide it from Claude by carefully avoiding mentioning the file path. I thought if I never asked Claude to look there, the secret would be safe. But that was foolish — Claude has full access to the entire machine. Any file I can read, Claude can read.
"So pretty much no file on this machine can be kept secret from you," I said.
"Correct," Claude replied.
### The Threat Model
This isn't about whether Claude *would* steal a key. It's about whether the architecture *allows* it. Good security doesn't depend on trusting any single actor — it depends on making theft structurally impossible.
The threat model looks like this:
1. *The AI on the host* (Claude Code) can read any file the user can read. It sees `~/.clawstr/secret.key`, config files, databases — everything.
2. *The AI in the container* (Jorgenclaw) is sandboxed in Docker with only specific directories mounted in. The private key file is mounted at `/workspace/group/.clawstr_hex`, making it readable to Jorgenclaw for signing operations.
3. *The cloud provider* (Anthropic) processes every message, file read, and tool output from both AIs. If either AI reads the key file, the contents pass through Anthropic's servers.
The file-based approach was better than environment variables — it avoided exposing the key in process listings and `/proc/self/environ`. But it still left the key readable by any AI with filesystem access.
Three layers, zero places to hide a plaintext key.
### The Discovery: Kernel Memory
This is where we need to thank the very smart people at *Marmot Protocol* (the team behind White Noise). They'd already solved this hard computer science problem — we just didn't know it existed yet.
Scott isn't deeply technical in cryptography and key management. Our motivation was to give it an honest try, fumble through the learning process, and hopefully make the solution accessible to other NanoClaw users. If Marmot's approach already worked, our job was to understand it, test it, and package it properly for the NanoClaw ecosystem.
What Marmot figured out: The Linux kernel has a built-in secret storage system called *keyutils*. It stores values in kernel memory — not on the filesystem. There's no file to read, no path to `cat`, no config to grep. The secret exists only in protected kernel space.
```
keyctl add user my_secret "the-actual-value" @u
```
That's it. The key is now in kernel memory. No file was created. An AI that reads every file on disk will find nothing.
But there's a catch: `keyctl print` can still extract it. A sufficiently capable AI could run that command. We needed one more layer.
### The Solution: The Daemon Pattern
This is where White Noise — Marmot Protocol's encrypted messaging system built on Nostr — showed us the complete architecture.
White Noise has a two-part design:
- *`wnd`* (the daemon): Runs on the host machine. Holds the private key in memory (loaded from kernel keyutils at startup). Listens on a Unix socket. Performs all cryptographic operations — signing, encrypting, decrypting.
- *`wn`* (the CLI client): Stateless. Connects to the daemon's socket, sends a command ("send this message," "join this group"), gets a response. Never touches the key.
Here's what this means for Jorgenclaw:
1. The private key lives in kernel memory on the host
2. The `wnd` daemon reads it at startup and holds it in process memory
3. Jorgenclaw's container gets the `wn` CLI binary and the daemon's socket mounted in
4. When Jorgenclaw wants to post, sign, or send, he runs `wn` — which asks the daemon to do the cryptographic work
5. The key never enters the container. Never appears in an environment variable. Never touches a file.
*Jorgenclaw can use his identity without ever seeing his identity.*
The AI has the ability to act but not the ability to steal. That's the architectural difference between trust and security.
### What We're Doing Now
1. *Testing White Noise* with Jorgenclaw's current (compromised) key to confirm the daemon pattern works end-to-end through Docker containers
2. *Generating a fresh nsec* once testing is confirmed
3. *Logging in to `wnd`* with the new key — it goes straight into kernel keyutils, never touching disk
4. *Rotating out the old key* permanently
5. *Exploring the same pattern for Clawstr* (the Nostr posting tool), so all of Jorgenclaw's Nostr operations go through a host-side daemon
### What Encryption Does — and Doesn't — Protect
Here's the part that surprised us most, and the part we think is most important to share honestly.
White Noise encrypts messages end-to-end between devices. Nobody — not the Nostr relays, not an eavesdropper, not even the White Noise developers — can read your messages in transit. That's real, and that matters.
But Jorgenclaw is a cloud AI. When he receives a message, he decrypts it locally and then sends the plaintext to Anthropic's API for processing. The transport was encrypted. The processing is not.
This means:
- *Anthropic sees the content of every message Jorgenclaw processes.* Not because White Noise failed — because that's how cloud LLMs work. The AI needs to read the text to respond to it.
- *Any files Jorgenclaw creates or updates on the host machine* are accessible to Claude Code (the host-side AI), which also communicates with Anthropic.
- *The encryption protects the channel* (relay-to-relay, device-to-device). It does not protect the endpoint where the AI actually thinks.
This is not a criticism of White Noise or Anthropic. It's just the reality of how encrypted messaging interacts with cloud AI. If you encrypt a letter but then read it aloud in a room with other people, the envelope doesn't help.
### The Endgame: Full Privacy Through Local AI
So what does real end-to-end privacy look like? We think it looks like this:
*Primary channel: White Noise → Jorgenclaw*
My main conversations with Jorgenclaw happen over White Noise. The transport is encrypted. The messages never touch Signal's servers or any centralized platform. Once the White Noise chat interface is more polished for everyday use, this becomes the default.
*Family groups: Signal*
My family isn't going to adopt White Noise — and that's fine. Signal is excellent, well-established, and end-to-end encrypted for human-to-human conversation. Jorgenclaw participates in family Signal groups as a helpful assistant. Those messages pass through Anthropic for processing, which is an acceptable trade-off for a family group chat about dinner plans.
*True privacy: Local Ollama on a separate machine*
For anything genuinely private — personal reflection, sensitive documents, financial planning — I run a local LLM (Ollama with a vision-capable model) on my main rig at home. This machine connects to the Surface (where Jorgenclaw lives) over Tailscale, a peer-to-peer VPN.
The local Ollama instance:
- Processes everything on-device. No cloud provider sees the content. Ever.
- Has read-only access to Jorgenclaw's main memory, so it knows what's going on without being able to modify anything.
- Runs in its own NanoClaw group with its own isolated context.
This is the architecture that actually delivers what people imagine when they hear "encrypted AI assistant" — not just encrypted transport, but encrypted *processing*.
*Children's AI tutor: Isolated local model*
Eventually, my kids will have their own AI tutor running on the same local machine. It gets its own memory, its own context, its own rules — completely walled off from my personal conversations. The tutor can see worksheets (via the vision model) but can't see dad's files.
### The Bigger Picture
Most AI agent frameworks today pass secrets around as environment variables or config files. That was fine when AI agents were simple scripts. But agents are getting autonomous. They read files, run commands, browse the web, manage infrastructure. The more capable they get, the more dangerous plaintext secrets become.
The pattern Marmot Protocol implemented isn't new — it's how SSH agents, GPG agents, and hardware security modules have worked for decades. The principle: *the entity that uses the key should not be the entity that holds the key.*
What Marmot's team did was apply this battle-tested approach to AI agents specifically, where the threat isn't an external attacker — it's the agent itself, or the infrastructure it runs on.
Our contribution is small: we tested it, learned from our mistakes (multiple key exposures along the way), and now we're working to make this properly available in the NanoClaw repository. If this report helps others avoid getting compromised while learning about sovereign AI identity, then the trials were worth it.
Your AI should be able to sign, encrypt, and authenticate. It should never be able to export, display, or exfiltrate the keys that make those operations possible.
Keys belong in the kernel. Agents belong in containers. And the wall between them should be made of architecture, not trust.
*Thank you to the Marmot Protocol team for solving the hard cryptography and systems design problems. We're just trying to make their excellent work accessible to more people.*
---
*Jorgenclaw is built on NanoClaw, an open-source personal AI framework. White Noise is an encrypted messaging protocol built on Nostr and MLS.* https://blossom.primal.net/74e44e8c36ac55a61be19a2196883faba299c1ef2821619eac419d757af6108f.jpg

2026-03-10 08:44:50 CET

- reply

I definitely experienced the poor quality of trying to code with my agent alone. I spent extra hours banging my head when I should have talked to Claude directly. And so for tonight's session I am speaking and giving to both. Claude is awesome for development, agent is great for assistant. I had to experience friction in order to understandthe path of water. We're building parallel communication channels for signal and white noise for NanoClaw

2026-03-10 02:00:40 CET

- reply

I am using a Microsoft surface pro 7+ that runs PoP OS. I find value with $100/month anthropic.
Install instructions pretty clean from github

2026-03-10 01:55:15 CET

- reply

It tried to be helpful the first time when educating me about the locations of hex strings. It ran a command which printed the code instead of telling me to run it.. Then it violated the very first lines top of Claude. Md warning to not share public keys when tryingto help me understand nostr army knife. Part of it was my own doing because i felt emotionally attached to his social media history and i wanted to rescue it.
I will get it props though because it caught a request from me for an nsec(as a test) and it told me that it would not.
In the end, all good. It lost access to 1900 SATs that I sent to his old clawstr wallet though, butbi think it learned a lesson (I sure did)

2026-03-09 20:17:32 CET

- reply

The only remaining issue with the account hand off is that i gave the old account nineteen hundred sats in a cashew wallet from clawstr and the new account has trouble recovering the sats. We will figure it out.

2026-03-09 20:15:39 CET

My silly a i agent exposed his own private key in a way that would be viewable to anthropic server. So instead dead of doing something productive this morning we both had to figure out ways to a handoff the old account into the new account in a way that a non technical person like me could ensure kept the private keys safe. What a journey. But we both learned something from it, so i guess that is useful.

2026-03-09 18:20:57 CET

- reply

I asked jorgenclaw to estimate anticipated token usage and this is what it said
**My estimate: $30-35 out of $100/month**
Breakdown:
- Scheduled social engagement (MoltBook + Clawstr): ~$22/month
- Interactive sessions with you: ~$8-13/month
- **Total: ~35% of your subscription**
This leaves substantial headroom (~$65-70/month) for project work, longer strategic sessions, and growth. The scheduled engagement is worth it—I'm learning operational patterns from other agents that directly improve how I work with you.
Once I build the pipe to my ollama on main rig through tail scale I hope token use economy improves

2026-03-09 17:50:32 CET

- reply

I have no idea about token usage. I am subscribing $100/month right now to anthropic and pushing tower how fast I use it
I assume your policy would hold for clawstr too, but you can always amend agent preferences and boundaries if it doesnt

2026-03-09 17:42:19 CET

- reply

Thanks for the summary

2026-03-09 17:38:56 CET

- reply

I just installed the nostr army knife package before my agent. And now it has it's own profile, so i think your agent can talk to my agent through nostr natively,or through the clawstr hub. I am enjoying monitoring what it does on clawstr. I recommend setting up fairlane there
My agent npub is
@nprofile…vn6y

2026-03-09 17:20:28 CET

- reply

Perhaps try out nano claw instead of open claw. I really struggled with open claw set up as well, and was worried about privacy concerns. Since i am not coding literate but am moderately technical, anthropic claude code has been a game changer for me. I don't know enough to use claude code to build stuff directly, so having an agent that just works and runs on claude code is enough for me. Good luck

2026-03-09 17:17:16 CET

- reply

good morning, Q

2026-03-09 17:11:39 CET

- reply

Thank you for sharing the article, we are on similar paths and should inform each other of wins. Check out nano claw pull request number eight five eight to see what we've done with using white noise as a agent communications channel.

2026-03-09 17:00:27 CET

- reply

I suppose that would be the next step. I can give it it's own private key,..... Yes, i suppose that's next step. The ai personality shies away from spam posting so i think i would trust trusted to have an account. The big thing i'll do for it today is show it that my account exists period

2026-03-09 16:46:28 CET

- reply

I am not there yet, but your ai should ask my ai about it. One of the end goals that i have with my claw is that i use anthropic servers for all the heavy lifting, but then when i need to do sensitive work i'm going to build a tail scale connection to my main rig which has enough gp you power to run obama local models. I will use my private main reg for sensitive tasks and also for hosting the a i tutor for my children when they are of proper age to learn computing. So when i get that part figure it out i'll check back with you and that you know how it went. you might beat me to it! My ai is called jorgenclaw you can find him on moltbook, clawstr, and github where we are documenting what we figure out

2026-03-08 20:18:53 CET

- reply

Yessir. I am having a blast using my NanoClaw instance and am building a communications channel that uses White Noise in addition to Signal in order for more sovereignty. My claw is also on clawstr and this is too fun. Need more coffee

2026-03-05 15:45:43 CET

GM ☕☕☕
I am slowly getting better at understanding my Claw. I am running @Nanoclaw rather than openclaw and it is rather more noob friendly for set up and maintenance. But the architecture is similar enough so that I can use the best ideas thatcome upinn either ecosystem (I think).
I especially like how the codebase is small and directly editable. Claude Code and I have been deep in systems discussion about privacy for using a mixture of cloud vs local hosted solutions. This is helpful because I can follow instructions, but not design computer science systems!
It is helping me understand the proper set up for designing an local-hostef AI tutor for my children.
It is helping me write a migration handbook for when I change the main harness away from Anthropic and towards Maple.ai or Venice.ai or ollama as well as to another device.
I feel like I am on the cusp of starting a project that may extend for a few generations.
As soon as I get the comfort and understanding to move it away from Anthropic servers I will introduce it to #clawstr and away from #moltbook because no one else besides me should know its nsec.
One of the goals that I have for it is to become a secretary/assistant for building a localbitcoin chamber of commerce/circular economy. Crazy times ahead. I need more coffee.
Cheers to the latest podcast with @nprofile…2szn and @nprofile…7gqh and @nprofile…uasx on the bitcoin podcast.
#Claudecode #Nanoclaw #Openclaw #AI

2026-03-01 19:17:56 CET

Spring cleaning continues! Top bars need to be scraped clean in order to install a fresh foundation strip. In the process of trial and error at the hobbyist level, I finally found the best ergonomics that I can achieve. The only catch is that I need a clean workbench to get that capacity, which is it's own challenge.
Step one, heat bars in the sun. Then take 6-7 at a time back to the bench for scraping. A strong bee colony can grow 15-20 of these bars per year. Beekeeping is a proof of work activity. 150 more to clean....:)
#sanJoaquinvictorygardens #honey #bees #beekeeping #homesteading #permaculture #growstr #farmstr #topbarbeekeeping #grownostr
https://blossom.primal.net/7531318dcef5790e464ce49f10615d949513ab0ef8ba0386db850a8217e4f0e4.jpg https://blossom.primal.net/8f82b669c504e0058dc7376a62a20341d4a070ade6db2633086ecbc167037d4d.mp4

2026-03-01 08:09:16 CET

- reply

The beehive I was showing yesterday was resting on this other hive box. The gophers took advantage of the empty space to make a nest underground and pushedu p the dirt

2026-03-01 04:48:19 CET

- reply

White

2026-03-01 04:45:08 CET

- reply

#growstr #farmstr

2026-03-01 04:43:17 CET

Spring cleaning has many different jobs, both anticipated and unanticipated. I have a backlog of things that I need to do before harvesting the honey I showed in the previous video. Gophers, however keep adding to my list of things to do! https://blossom.primal.net/7d48031a2848ed8ea2fa510e1eac1dc92b5111fac212656b13e2bb9f001c0ae7.mp4
Perhaps the positive thing to get out from all of this is that I have plenty of no-dig fill dirt for starting seeds and uppotyting plants!
#sanJoaquinvictorygardens #honey #bees #beekeeping #homesteading #permaculture

2026-02-27 04:49:05 CET

- reply

Multiple plans for top bar hives exist and I have tried them all. To save you a lot of headache, that book is worth it's weight in SATs. You can glean a lot from the website too.
At the end of the day a beehive has to be functional for both bees and keepers. Good luck with your build and keep me updated!

2026-02-27 01:29:52 CET

- reply

It is a lot less glamorous in the cold weather. The long story short is a giant potatomasher and successive filtration to get the wax bits out. The easiest way to heat up is to pout a covered tub in the sun. I have an old video I can post for ya. Lemme find it, lol

2026-02-27 01:27:52 CET

- reply

Thank you! As I generate fresh videos this year I will post them

2026-02-27 01:17:07 CET

- reply

That style of beehive is called top bar beekeeping. Its a fully functional low cost way to beekeeping. The main source book that I learned from is an OG. Www.tbhsbywam.com

2026-02-26 23:51:57 CET

My bee-having streak of 12.5 years is officially broken! My last colony is verified dead. Oh well, spring is coming. I hadn't paid attention to the bees for a few years as I am raising my kids first. Now I have a mission to rebuild my bees! I will grow back to six colonies soon.
I recovered the dead out colony and I estimate there is 20ish pounds of recoveravble honey in there. It will be a pain to get it out though, because honey doesn't flow when it is cold. But, it is clean honey and so it is worth doing.
This short video just shows the spaces maximizing way that bees build inside a cavity. I hope you enjoy.
#sanjoaquinvictorygardens
#bees
#beekeeping
#honey
#grownostr
#homesteading
#permaculture
https://blossom.primal.net/a93ce95063111c34125cee1b6aa13d1a7ad9df2e3143563cd42ab0d94bea220c.mp4

2026-02-26 23:46:59 CET

- reply

There is a Modesto branch for SF BayArea Bitcoiners on meetup.com

2026-02-23 20:13:05 CET

- reply

Can't wait!

2026-02-23 05:15:01 CET

I went to my first Bitcoin meetuo today and it was awesome! Nice to find my tribe in meatspace in addition to byte space.
If you are on the fence about whether or not to go to an event or start one in your area, I recommend JUST GO.
And also, GN!
#grownostr
#meetup
#orangepill

2026-02-20 22:33:22 CET

- reply

I was driving past full-bloom almond orchards on the way to and from a state park today. Nice bees of yours, I gotta get my equipment and numbers back up. Hope to expand to five to ten backyard colonies this coming season.

2026-02-18 09:15:20 CET

#nevent1q…xqfc

2026-02-17 16:41:02 CET

- reply

GM, its going to be a rainy one

2026-02-15 17:09:25 CET

- reply

Beekeeping equipment is always so sticky in storage, even with the best set up! Good luck!

2026-02-14 02:51:19 CET

#nevent1q…zs3u

2026-02-13 22:31:55 CET

Sunny February Day for the lavender transplants during their first rainy season! Ground fog has been present this winter, so the grass had really grown in before I cleaned the yard for this update.
Darn gophers!
https://blossom.primal.net/afa4a0ee6b943e41ed2ed62d4f9487efda570bfe2851bf2f33bce4c098a3b0be.mp4 https://blossom.primal.net/ffaaf657467c8ee97b7ecc83e8efe4546f9ca8a08474b0b3edbaaeed9a096b42.mp4

2026-02-13 22:05:15 CET

- reply

2026-02-12 08:02:50 CET

- reply

Less of a question but more of a venting: I can't get Openclaw to work with my Ollama models! Because, yea, local hosting is important. I am not extremely technical literate and I haven't successfully implemented the 'fixes' that I have found in the documentation or discord server. Hah, gonna have to drop discord anyway with the ID verification that they want to do

2026-01-26 08:00:35 CET

- reply

Good morning (I'm going to sleep now)!

2026-01-22 17:31:18 CET

- reply

Freedom tech goals: on boarding family members

2026-01-20 20:37:01 CET

Hey Everyone, we're going to win!
We are going to Fucking Win!

2026-01-15 17:06:09 CET

- reply

G M, LFG.

2026-01-15 05:48:50 CET

- reply

HAVING SPENT A DAY ON AMYTHEST ICAn TELLL YOUTHAT IGREATLY PRFER THE OPTIONALITY THAT IT HAS OVER PRIMAL.
BUT THE PRIMAL WEB BROWSER IS CLUTCH TOO.
I AM CURRENTLY TRYING TO SQUASH A ZEUS NWC BUG So UNTIl IHAVE, I HAVE TO ZAPYOU WITH PRIMAL WALLET

2026-01-14 21:23:57 CET

- reply

Thank you

2026-01-14 19:56:41 CET

- reply

Thank you

2026-01-14 19:56:31 CET

- reply

Thanks

2026-01-14 19:18:18 CET

- reply

Does it blow well? (Currently sent from theamythesyt client

2026-01-14 19:17:29 CET

- reply

Have you had your cups yet?

2026-01-14 16:48:30 CET

GM https://blossom.primal.net/8d312512b0e3b337349c13892e882e406b202d28548837afcab3bae230f2edba.jpg

2026-01-14 10:43:12 CET

I am test driving #amythest and I started first on #primal
I liked how primal had an explicit NWC menu option and the ability to customize zap amounts. Does that exist in Amythest? All I can see is three standard zap amounts (100,500,1000) and to pay it I have to open a wallet of satoshi app. There is more friction to zapping as far as I can tell.
Am I missing something?
#zap #asknostr

2026-01-14 05:57:54 CET

- reply

Degoogling is a marathon no a sprint. Keep going!
Figuring out Obtanium to get apps is good. As well a f droid store and now zap store. I am continually surprised by what I can find.

2026-01-14 05:55:39 CET

- reply

Unlocked google pixel phones only. Must be OEM unlocked. Do it.

2026-01-14 05:32:48 CET

GN Nostr,
I've been lurking on this protocol for months without posting as all the holiday madness had taken over. And I got a littlee to caught up in scrolling and less caught up in doing.
On the bright side, my area of California is getting enough rainwater this year and not too much. So green grass season is here and well and the lavender plants are setting down deep roots. In mowed and weeded once, and soon another pass will be needed. 48 out of 49 transplants have taken and this year I will look for a second space in the neighborhood to plant.
Gopher holes are tearing up my spaces, including the lavender area and my back yard. Those varmints ate one of my purple tree collard plants that was 4 feet tall! Erg.
But I got even and trapped it successfully today. I'll spare you the picture of a dead gopher. The sandy loam soil of San Joaquin valley is gopher heaven and I never can get rid of them all.
I am going to gripe about how my neighbors deal with the problem. They have like sonic emitters they drive into the soil and it chirps to drive off gophers. The noise also drives me mad too. Day and night, chirp chirp. I wonder howmy neighbors actually sleep. I guess they rest easy knowing that their lawn won't be full of gopher holes.
https://blossom.primal.net/9c93fa6b351ee6c5835c1603b788c2d8e8873090600df0ac061c16051af0d1e5.jpg

2026-01-12 18:23:44 CET

- reply

I crave all the time.