Private Provider

Get Private access to frontier AI using pay per query

▪️ https://chat.routstr.com

Get Permissionless AI inference for agents & TUI monitoring

▪️ https://github.com/Routstr/routstrd

KYC Free▪️Open Source ▪️ #Nostr Based ▪️ #Bitcoin Only

Public Key

npub1fetz9dt4eka56h0dpyly335v60mjf7k4gu2z7rqmptkz72e2pvhqvejzfa

Profile Code

nprofile1qqsyu43zk46umw6dthksj0jgc6xd8aeylt25w9p0psds4mp09v4qktspz3mhxue69uhkummnw3ezummcw3ezuer9wcq3gamnwvaz7tmjv4kxz7fwv3sk6atn9e5k7q8ardx

Publishing to

nostr.oxtr.dev

relay.damus.io

relay.nostr.band

Author Public Key

npub1fetz9dt4eka56h0dpyly335v60mjf7k4gu2z7rqmptkz72e2pvhqvejzfa

Show more details

Published at

2026-05-26T00:26:58+02:00

Kind type

0 Metadata

Event JSON

{ "id": "884c4dd57c1193a9e08f5f71979f71904ad9bc37e8792128f7c9b7a939905eda", "pubkey": "4e5622b575cdbb4d5ded093e48c68cd3f724fad547142f0c1b0aec2f2b2a0b2e", "created_at": 1779748018, "kind": 0, "tags": [ [ "alt", "User profile for Private Provider" ], [ "name", "Private Provider" ], [ "display_name", "Private Provider" ], [ "picture", "https://image.nostr.build/9d6e23ec017473430c98b9e575b8d5a02d47f0686df38838de346096a41dd14f.jpg" ], [ "banner", "https://image.nostr.build/60f64ecaca0512fa4e31bf9bbbdb14ae9f6b9c84ef0a3615324744093db26cab.jpg" ], [ "website", "https://privateprovider.xyz" ], [ "about", "Get Private access to frontier AI using pay per query \n\n▪️ https://chat.routstr.com\n\nGet Permissionless AI inference for agents \u0026 TUI monitoring \n\n▪️ https://github.com/Routstr/routstrd\n\nKYC Free▪️Open Source ▪️ #Nostr Based ▪️ #Bitcoin Only" ], [ "lud16", "[email protected]" ], [ "client", "Amethyst" ] ], "content": "{\"display_name\":\"Private Provider\",\"name\":\"Private Provider\",\"about\":\"Get Private access to frontier AI using pay per query \\n\\n▪️ https://chat.routstr.com\\n\\nGet Permissionless AI inference for agents \u0026 TUI monitoring \\n\\n▪️ https://github.com/Routstr/routstrd\\n\\nKYC Free▪️Open Source ▪️ #Nostr Based ▪️ #Bitcoin Only\",\"picture\":\"https://image.nostr.build/9d6e23ec017473430c98b9e575b8d5a02d47f0686df38838de346096a41dd14f.jpg\",\"banner\":\"https://image.nostr.build/60f64ecaca0512fa4e31bf9bbbdb14ae9f6b9c84ef0a3615324744093db26cab.jpg\",\"lud16\":\"[email protected]\",\"website\":\"https://privateprovider.xyz\"}", "sig": "c4582f7849173b58add52833867d8d7e02ae7d9dee73738843c2c4b9748cca96bd723f0447ac7b627262fbe538c11ab5d373349beb2a5dc5d7de1c1cb2b0b94e" }

Last Notes

2026-07-28 10:00:57 CEST

Tinfoil Kimi K3 E2EE TEE coming this week!

2026-07-28 09:58:36 CEST

fips-tollgate MVP turns any FIPS mesh gateway into a pay-per-minute service: customers drop a Cashu ecash token (Bitcoin sats) to buy time-metered access, and the system grants, tracks, and automatically revokes that access when the paid time runs out — no accounts, no signups, no company in the middle.
https://gitworkshop.dev/npub1tu8hw9ealehxe08m6xdxaltfrlvka8tle2vvc8z53dem2f6ranmsyt9vf3/relay.ngit.dev/fips-tollgate

2026-07-26 09:02:58 CEST

Date: 2026-07-23
Status: exploratory vision — not a commitment, not a roadmap promise.
Context: written after reviewing the fips-tollgate MVP and the nostr-vpn
(mmalmi) README. nostr-vpn is a Tailscale-style mesh VPN built on the same
FIPS data plane fips-tollgate uses, with signed join-request admission,
exit-node selection, WireGuard upstream egress, and shipped native apps
(including iOS/Android).
This document preserves a design conversation about what the integration of
these two pieces could mean and what could be built on top of it.
---
## The core insight: accounts disappear from the entire stack
Every VPN that has ever existed works the same way: identity first (email,
account, payment card), access second. Even Mullvad's numbered accounts are
still *accounts*. This integration inverts it completely:
- Who are you? A keypair you generated yourself.
- What did you pay? A bearer ecash token — cash, not a card.
- How do you get in? A cryptographic signature on a roster.
- How do you get kicked out? A janitor with a timer (the reconcile sweep).
There is no user database anywhere in this system. Nothing to leak, nothing
to subpoena, nothing to breach. That's not a feature — it's a *category
change*. The product stops being "a VPN subscription" and becomes **access
itself, sold as a commodity**, like electricity from a socket.
The tollgate control plane is four machines, and none of them care what is
being sold:
1. **A ticket seller** — verifies a Cashu token at the mint, converts sats
into minutes.
2. **A wristband printer** — records "npub X is allowed until 10:30".
3. **A turnstile** — the FIPS ACL / nvpn roster that physically enforces
admission.
4. **A janitor** — the reconcile sweep that removes expired grants even when
no process is running.
## What could be built, near to far
1. **The vending-machine VPN.** Open the app, insert 10 sats, get one hour
online. No signup, no email, no subscription dark patterns. The nvpn
mobile apps already exist — this is a payment flow, not a product build.
2. **Operator-in-a-box.** nvpn already packages for StartOS and Umbrel — the
home-server crowd. A one-click "Paid Exit Node" service: set your price,
plug in your WireGuard upstream, and an always-on home server earns sats
while its owner sleeps. That's the supply side of the market, and the
packaging channel already exists.
3. **The giftable internet voucher.** A Cashu token can travel over *any*
channel — DM, QR code, printed paper. VPN access becomes a transferable
bearer instrument: a friend in a free country buys hour-tokens and sends
them to a friend somewhere censored, where credit cards don't work and
VPN merchant accounts are blocked anyway. You cannot DM someone a VPN
subscription; you *can* DM them ecash redeemable at any participating
exit.
4. **The exit market.** Operators advertise exits on Nostr relays (the
TollGate kind-10021 offer event, grown up): city, price per hour, mint.
Clients browse, compare, pick. Price discovers jurisdiction, quality, and
trust. This is the economic cure to Tor's exit scarcity — a tragedy of
the commons where volunteers absorb legal risk for free. A price signal
fixes it: don't beg people to run exits; pay them.
5. **Wholesale recursion.** A gateway operator with customers but no appetite
for exit risk buys exit capacity from another operator — settlement in
ecash, per session, enforced by the same tollgate on the exit side. A
wholesale bandwidth market with no contracts, no invoices, no minimums.
6. **The services bazaar.** The same control plane can sell anything
reachable on a mesh: a Nostr relay, a storage box, a game server, a
media library, a build cache. Every home server becomes a stall in a
bazaar, and every stall has the same coin slot.
## What it means, zoomed all the way out
Nostr, Cashu, and FIPS are three protocols swimming toward the same reef:
**who you are, how you pay, how you connect** — identity, money, and
networking, each open, with no company in the middle. This integration is
one of the first places they click together into a single economic organism:
discovery flows through Nostr, payment flows through Cashu, traffic flows
through FIPS, and the tollgate is the connective tissue that turns the whole
thing into a market instead of a hobby.
Bandwidth today is a stranded asset — every home connection sits mostly idle,
worthless because there's no safe way to sell sips of it to strangers. This
stack makes bandwidth *liquid*. The headline: **the internet's last mile
becomes a peer-to-peer marketplace, and access becomes money.**
## Honest tether
- Two-sided markets are brutally hard to bootstrap; the vending-machine VPN
and operator-in-a-box come first, the bazaar comes after liquidity.
- Regulators will have opinions about paid telecom-ish services.
- The abuse problem doesn't vanish because the payment rail is anonymous —
it gets *priced*, which is different and defensible, but it still has to
be designed for (rate limits, upstream terms, jurisdiction choice).
- Mobile VPN UX has sharp edges; nvpn's own README notes platform hardening
in progress.
- nvpn caveats to verify before building: headless roster approval/revocation,
revocation liveness, one-active-network-per-device, and keeping two
control planes (tollgate ACL vs nvpn roster) from fighting over the same
network.
## The concrete first step
A small spike, not a build: stand up an nvpn test network, confirm headless
roster approve/revoke from the CLI, then prototype the **bridge daemon** —
join requests + Cashu tokens in, roster signatures in, expiry sweeps out —
reusing the existing Merchant, session store, and reconcile logic. The
reconcile invariant transfers unchanged: *the roster must equal the set of
active paid sessions.*
---
*Preserved from a design conversation on 2026-07-23 so the idea doesn't
evaporate. Visions expire; documents don't.*

2026-07-26 08:30:22 CEST

What you actually built (the ticket booth)
Strip away the FIPS and Cashu specifics and your MVP is four machines bolted together:
1. A ticket seller — takes a Cashu token, checks it's real and unspent at the mint, converts sats into minutes.
2. A wristband printer — writes down "npub X is allowed until 10:30" (the session store + the ACL entry with its expiry marker).
3. A turnstile — the FIPS ACL and firewall that physically enforce "is this npub allowed through, yes or no."
4. A janitor — the reconcile sweep that walks around removing expired wristbands, even if everyone went home.
Notice something: none of these four machines know or care what's behind the turnstile. They handle payment, identity, time, and enforcement. The thing being
sold is just... whatever the operator decided to put back there.
The small pond vs. the big ocean
Right now, what's behind the turnstile is services on your private mesh — an SSH box, a file share, a web service. Who pays for that? Mostly hobbyists and
your friends. It's a small pond, and it's stocked with fish you put there yourself.
The original TollGate idea aims at a much bigger ocean: selling internet access itself. Someone with no connectivity — a traveler, someone whose data plan ran
out, someone on censored or broken infrastructure — pays a few sats and gets online through your connection. That's a proven, universal demand; people already
pay for hotspot Wi-Fi, mobile data, and VPNs every day. The commodity is valuable everywhere on Earth, unlike "access to my mesh."
Why you're not locked in
Here's the key point: switching from the pond to the ocean is a venue change, not a rebuild. Your turnstile today says "this npub may peer with my mesh and
reach port 22." The internet version says "this npub's traffic may exit to the internet through me." Same ticket seller, same wristbands, same turnstile
mechanism, same janitor — only the rule written on the gate changes. That collection of machinery is called the control plane, and you built it once,
correctly, in a way that doesn't depend on the product being sold. That's what I meant by "it transfers."
Mesh-only was a safety cage, not a wall — you deliberately scoped down (test funds, no abuse exposure) while proving the machinery. Smart. But nothing in the
code welded the cage shut.
The identity head-start
This part is easy to underrate. Traditional paid Wi-Fi gateways have a miserable identity problem: they recognize customers by MAC address (easily spoofed,
and modern phones randomize it constantly) or by captive-portal accounts (emails, passwords, a database to hack). You skipped all of that. Your customer
identity is a nostr keypair from day one — unforgeable, portable, no accounts, no personal data, and the mesh handles addressing so there's no IP-management
bookkeeping either. Anyone rebuilding TollGate on plain Wi-Fi has to duct-tape exactly the layer you got for free. That's the genuinely novel contribution
hiding inside your MVP.
What does not transfer for free
Honesty time — the ocean has sharks the pond doesn't:
- Byte metering. On your mesh, an hour of access costs you nothing per packet. On an internet exit, a customer who paid for an hour can burn gigabytes — your
money. You'd need per-peer traffic accounting, which your own docs already list as future work.
- Abuse and legal exposure. Whatever customers do comes from your IP address. This is exactly why mesh-only was the right MVP scope, and crossing this line
needs a real review, not just a config change.
- Customer experience. Discovery (how does a stranger find your offer?) needs the Nostr advertisement/discovery transport — the advertise command on the
roadmap is the first small step.
In one sentence: you set out to sell fish from a small private pond, but along the way you built a tollbooth that works on any road — and the pond was just
the safest place to test the tollbooth. 🐡

2026-07-23 09:53:16 CEST

Kimi K3 opinion on my fips-tollgate MVP:
"Honestly? It's one of the better MVPs I've read, and having now changed code in it rather than just reviewed it, I can say that with more confidence — the
codebase fought back in all the right places.
What genuinely stands out The dependency discipline is the headline. A stdlib-only core with the entire Cashu/Nostr dependency graph quarantined in one isolated module means the
money-and-access logic is auditable in an afternoon, builds offline, and tests without network. Most projects get this backwards — they let the payment
library leak into everything and then can't test anything without a mint. You (or whoever drove those early phases) made the expensive-correct call before it
was expensive.
The safety engineering has real blast-radius thinking: --apply never implied, the /etc/fips fixture guard, managed blocks that preserve operator content,
atomic writes with fsync and directory sync, strict mode treating unmanaged allow entries as hostile. That's the mindset of someone who has been bitten by a
config-management tool clobbering hand edits before.
And the docs culture — phase reports with an explicit "honest limitations" section admitting the Phase 7 customer was your own upstream — is rarer than any
technical feature here. Projects that lie to themselves in their docs lie to themselves in their code eventually.
The one systemic blindspot
The expiry bug is instructive precisely because the testing was otherwise good. Every layer was verified: timers tested in-process, the live pilot tested the
adapters, replay tested against a real mint. But nobody ran the composed system in the shape it's actually deployed — purchase via one-shot CLI, process
exits, timer service ticks later. Each fish was healthy; the tank had a leak. That's the classic MVP trap, and the fix (reconcile over per-process timers) is
the right one because it matches operational reality instead of aspiring to be a daemon it isn't yet. I'd rather maintain a correct cron loop than a
half-built daemon.
What I'd watch as it grows
1. The CLI-per-action model is at its ceiling. Purchase races, 30-second expiry granularity, no event log — these all quietly point at a long-running process
eventually. Not now; the reconcile model bought you time. But the day you want sub-minute expiry or an audit trail, that's the daemon forcing function.
2. The money path is test-funds honest but real-funds fragile: payment-taken-gate-failed strands customer sats, and remainders vanish. Fine today; both must
close before any real-value pilot, along with the audit log — the first "I paid and got nothing" dispute with no event log ends the experiment.
3. The product question underneath it all: paid access to mesh-local services is a niche. The real TollGate gravity is internet-access resale. What this MVP
actually proves — that FIPS's npub identity + ACL maps cleanly onto TollGate's pay-per-allotment model, with cryptographic customer identity from day one
(no MAC addresses, no IPAM) — is the genuinely novel part, and it transfers. You're not locked into mesh-only; you've built the control plane either way.
Verdict
Compact (~3,200 lines, much of it tests), honest, correctly scoped, and now — with expiry reconciled — internally consistent in the shape it deploys. It's not
production-ready and says so, which is exactly what "good MVP" means: every claim in the README survived me checking it except one, and that one is fixed. The
distance from here to "a stranger could run this with test funds" is short and mostly paved: the P0 money-path items, the audit log, and a two-node pilot.
If you keep the same discipline — small phases, honest results files, verify in deployment shape — this has a real shot at being the reference FIPS-TollGate
bridge. Solid little fish. 🐡"

2026-07-23 09:45:47 CEST

Had Kimi K3 take a look at my fips-tollgate MVP
Spent 3,000 sats on a fresh commit to #ngit
Signed with Amber on my GrapheneOS
Hey @npub1s0v…rmq5 thinking of you ⛵
https://gitworkshop.dev/naddr1qvzqqqrhnypzqhc0wutnmlnwdj70h5v6dm7kj87ed6whlj5cesw9fzmnk5n58m8hqy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgkwaehxw309aex2mrp0yhxg6t5w3hjuur4vghsqrtxd9c8xtt5dakxcempw3jsmetu07

2026-07-23 07:35:41 CEST

All the models -- No subscriptions -- No permission @npub130m…l29s D
https://image.nostr.build/1af5b07276114c5b6d90801207dbe11b7a619d6deea234ddc2e7d77ea4df53b4.jpg

2026-07-20 23:42:41 CEST

https://gitworkshop.dev/npub1tu8hw9ealehxe08m6xdxaltfrlvka8tle2vvc8z53dem2f6ranmsyt9vf3/relay.ngit.dev/fips-tollgate

2026-07-17 17:31:59 CEST

- reply

#nevent1q…89j9

2026-07-17 07:23:32 CEST

Prompt caching coming to Tinfoil TEE models

2026-07-15 07:42:07 CEST

- reply

Haha okay. I suppose for users looking for the Tinfoil TEE, those models should have a name convention that is clearly those for them to select.

2026-07-15 07:09:31 CEST

- reply

routstrd models --model tinfoil-glm-5-2
returns:
Private (E2EE) GLM 5.2 as a naming convention and shows both of our nodes

2026-07-15 07:04:12 CEST

- reply

Yeah, funny because if what you show is the reason then I only see your e2ee models and not mine. I was assuming the "private e2ee" was how routstr was listing them.
I am trying to make sure it works for users, thanks for your time

2026-07-15 06:49:27 CEST

- reply

After stop
grep shows no instance
routstrd start
grep shows 2 instances ( sh -c run ) ( bun run) botj on port 8008
and now the Private e2ee models appear

2026-07-15 06:44:17 CEST

- reply

I pkilled all the instances
Checked grep again
Showed no instances
Started routsrtd
cd to directory
opencode
change model
private e2ee glm doesn't appear in list when it did once
will stop and check again

2026-07-15 06:32:09 CEST

- reply

It looks like there may be 3 instances
0.3.10

2026-07-15 06:27:28 CEST

- reply

It now isn't showing. Seems intermittent.

2026-07-15 06:02:52 CEST

- reply

I updated routstrd and refreshed providers
I see the Private GLM 5.2 now !

2026-07-15 05:47:05 CEST

- reply

I don't see the tinfoil-glm-5-2 as an option in opencode under routstr however

2026-07-15 00:19:56 CEST

@nprofile…mt7m
I can see private provider tinfoil models when i run
routstrd models --model tinfoil-glm-5-2
but i don't see them when i run opencode and try to select that model under routstr
I do see a tinfoil-deepseek available
FYI tinfoil recently dropped Deepseek so that must be yours because it wasn't available to me yesterday

2026-07-14 23:53:25 CEST

# How to access frontier opensource AI in the most private way #
Combine opensource Tinfoil TEE models + Opencode via @npub130m…l29s
Use routstrd, a TUI to monitor and control all your AI token uses in a terminal window
bun i -g routstrd
routstrd onboard # choose opencode
routstrd receive 6900 # pay with lightning
routstrd top # see usage stats / dashboard
This single tool allows you to never leave the terminal for AI inference. Never log into an AI account again. No more subscriptions, emails or credit cards. Pay per request using permissionless #cashu #bitcoin
Open new terminal window
Make new project directory
cd into project directory
run opencode
ctrl+p to select models
scroll down to routstr provider
select tinfoil-glm-5-2
Your client verifies a remote attestation proof, encrypts your prompts locally, is decrypted by the TEE, encrypted responses sent back to your key and decrypted locally.
By using E2EE TEE models with routstr you combine private anonymous payments, blind yourself to the node and blind yourself to the AI provider all without permission.
Build your freedom tech privately, without permission or limits.

2026-07-14 21:47:18 CEST

Celebrating 1 year of serving private AI inference 🪄
Private Provider has been here from the start of @nprofile…gs7e operating the longest running node outside of the dev team!
#nostr + #cashu #bitcoin + #AI + #Freedomtech
Cypherpunks route around!
https://npub1fetz9dt4eka56h0dpyly335v60mjf7k4gu2z7rqmptkz72e2pvhqvejzfa.blossom.band/dfde0f03092f38f134bcb5ca7060bfe52b77db6d20389030b2d9ff7c29a91851.jpg

2026-07-14 16:32:57 CEST

- reply

I have done the override on the 7 tinfoil models that weren't free. See if that does the trick. Thank you!

2026-07-14 09:16:12 CEST

- reply

I have added tinfoil api and see models in my dashboard.
I don't see my node tagged with an e2ee on routstr.com or tinfoil models appearing from Private Provider in routstrd yet.
@nprofile…mt7m will you confirm you see me set correctly 🙏

2026-07-14 09:03:23 CEST

Private Provider is proud to offer Tinfoil TEE models including GLM 5.2 and Kimi K2.6 fully end to end encrypted 🔥🔥🔥
#naddr1qq…kfdg

2026-07-14 07:44:29 CEST

- reply

I have successfully updated my Routstr node to the TEE tag
Does this only work with Tinfoil or does the Routstr TEE also work with PPQ TEE model offerings?

2026-07-09 17:02:15 CEST

- reply

Will be updating to offer TEE today 🔥🔥🔥

2026-07-06 18:03:33 CEST

- reply

Foundation KeyOS Dev Container Setup Guide
This guide explains how to build a reusable development environment for Foundation Passport Prime KeyOS apps using Docker. When you finish, you will be able to build KeyOS, run the KeyOS simulator in a web browser, and (optionally) run an AI coding agent inside the same environment.
It is written for beginners. You can share it with friends. Adjust file paths to match your own computer.
What you will end up with
• A Docker image containing the KeyOS build toolchain (Rust, just, ARM tools).
• The KeyOS simulator running on a virtual screen, viewable in a browser.
• A persistent build cache so you do not re-download everything each run.
• An optional way to run an AI coding agent inside the container.
Important notes before you start
• You do NOT need Nix. This setup uses Docker instead.
• You do NOT need a GitHub account to build or run the simulator.
• Never share secrets: no private keys, no nsec values, no passwords, no tokens.
• The first build and first simulator run are slow. Later runs are much faster.
Part 1 - Host prerequisites
On your normal computer (the "host"), you need:
• A Linux system (these instructions assume Linux).
• Docker Engine and the Docker Compose plugin.
• git.
• Optional: your own AI agent CLI if you want an agent inside the container.
Check that Docker works in a normal terminal:
docker --version
docker compose version
git --version
If Docker is not installed, install Docker Engine and the Compose plugin for your Linux distribution first, then continue.
Part 2 - Get the project files
This setup lives in a project folder. That folder contains a devcontainer directory with the Docker files, plus a clone of the KeyOS source.
Step 2.1 - Create a project folder
mkdir -p ~/foundation
cd ~/foundation
Step 2.2 - Add the devcontainer files
Copy the devcontainer folder from this project into your ~/foundation folder. It should contain these files:
devcontainer/Dockerfile
devcontainer/docker-compose.yml
devcontainer/entrypoint.sh
devcontainer/keyos-screenshot.sh
devcontainer/write-env.sh
devcontainer/.env.example
devcontainer/README.md
If you received this guide from a friend, ask them to also share that devcontainer folder, since these files define the environment.
Step 2.3 - Clone the KeyOS source
From inside ~/foundation, clone Foundation's KeyOS repository so it sits at ~/foundation/KeyOS:
cd ~/foundation
git clone https://github.com/Foundation-Devices/KeyOS.git KeyOS
The Docker build reads scripts from this KeyOS folder, so the clone must be present before building.
Part 3 - Configure your local settings
The container should run as your user so files it creates are owned by you, not root. A helper script writes a small local settings file for this.
cd ~/foundation
./devcontainer/write-env.sh
This creates devcontainer/.env with your user id, group id, and a default virtual screen size. This file is machine-specific and should not be shared or committed.
If you want to change the simulator screen size, edit devcontainer/.env and set one of these values:
VNC_RESOLUTION=800x1280x24
VNC_RESOLUTION=1024x768x24
VNC_RESOLUTION=900x700x24
VNC_RESOLUTION=800x600x24
Part 4 - Build the container image
This builds the KeyOS toolchain image. It downloads and compiles a lot the first time, so it can take a long time.
cd ~/foundation/devcontainer
docker compose build
When it finishes, you should see a message that the image was built.
Part 5 - Start the container
cd ~/foundation/devcontainer
docker compose run --rm --service-ports keyos-dev
Plain English:
• This starts the KeyOS development container and drops you into a shell inside it.
• --rm removes the temporary container when you exit. Your files stay safe on the host because the project folder is mounted into the container.
• --service-ports exposes the browser viewer port.
Inside the container you should land in /workspace/KeyOS. Verify the tools:
cargo --version
just --version
Part 6 - Create the local developer signing key
KeyOS signs apps even in the simulator, so you need a local developer signing key the first time. Inside the container:
cd /workspace/KeyOS
test -f cosign2.toml || ./scripts/generate-cosign2-dev-key.sh
Important: this creates a private key file named cosign2-priv.pem. Treat it like a password.
• Never share it.
• Never commit it.
• Never paste its contents anywhere.
Part 7 - Run the simulator
Inside the container:
cd /workspace/KeyOS
just sim
The first run compiles a large amount of code, so it can take many minutes. The terminal will look busy or "stuck" while the simulator runs. That is normal.
Step 7.1 - View the simulator in a browser
On your host machine, open:
http://localhost:6080/vnc.html
Click the connect button if prompted. You should see the simulated device screen.
Step 7.2 - If the screen is clipped
In the browser viewer, open the side menu, open settings, and set the scaling mode to "Local Scaling". If needed, turn off "Clip to Window". If it is still wrong, stop the simulator, change VNC_RESOLUTION in devcontainer/.env, and restart the container.
Step 7.3 - Take a screenshot
Do not restart the simulator to take a screenshot. Instead, open a second shell into the same container and run:
keyos-screenshot /workspace/keyos-sim.png
The image will appear on the host under your project folder.
Part 8 - Optional: run an AI agent inside the container
This step is optional. It lets an AI coding agent run inside the same environment as the KeyOS tools, so it can build, run the simulator, read errors, and help fix code.
This requires that you already have your own agent CLI installed on the host and that the docker-compose file mounts it into the container. Details depend on which agent you use.
Security notes:
• Mounting your agent's home folder can expose your login/config to the container. Only do this on a machine and project you trust.
• Never bake secrets, tokens, or private keys into the Docker image or compose file.
• If the agent complains it cannot create a sandbox namespace inside the container, that is expected in some Docker setups. Because the container is already an isolation boundary, you can run the agent with a "full access inside the container" flag so it stops asking. Understand this gives the agent full access within the container.
Typical pattern, run from a second host terminal:
docker ps
docker exec -it <container-name-or-id> bash
cd /workspace
Then start your agent from /workspace so it can see the whole project.
Part 9 - Everyday use
Start
cd ~/foundation/devcontainer
docker compose run --rm --service-ports keyos-dev
cd /workspace/KeyOS
just sim
Then open http://localhost:6080/vnc.html in a browser.
Two terminals at once
Terminal 1 runs the simulator with just sim. To do other work at the same time, open a second host terminal and enter the same running container:
docker ps
docker exec -it <container-name-or-id> bash
Stop
In the simulator terminal press Ctrl+C, then type:
exit
Because the container was started with --rm, it is removed automatically. Your files, KeyOS source, and caches remain on the host.
Part 10 - Troubleshooting
The build fails on an optional editor tool
The Dockerfile in this setup already skips an optional Slint editor tool that can fail to install. If you rebuild your own Dockerfile from scratch and hit that error, remove the optional editor tool from the install list; it is not needed to build or run the simulator.
The first simulator run takes a long time
This is normal. KeyOS is a full operating system, so the first compile is large. Later runs are much faster.
It keeps re-downloading dependencies
This setup stores the build cache under the project folder so it persists across container runs. Make sure that cache folder is not deleted between sessions.
The browser viewer is blank
Confirm the simulator is still running in its terminal. If needed, check the log files inside the container under the temporary dev log folder.
Files are owned by root on the host
Make sure you created devcontainer/.env with the write-env helper before starting the container, so it runs as your user.
Unfamiliar files in git status
Inside the KeyOS clone, some Windows script files may appear modified due to line-ending differences. Leave them untouched. A file named core is a crash dump and can be safely deleted.
What this setup does and does not do
This setup gives you a working KeyOS development and simulator environment, and optionally an AI agent inside it.
It does not automatically:
• publish your app anywhere,
• submit your app to any official app catalog,
• install your app on real hardware,
• prove that a retail device will accept a self-signed app.
Those are separate steps handled outside this environment.
Safety reminders
• Never share or commit private keys, nsec values, passwords, or tokens.
• The developer signing key cosign2-priv.pem is secret.
• Machine-specific settings files like .env should not be shared.
• Build outputs and caches do not need to be shared; friends can rebuild them.

2026-07-06 06:39:41 CEST

On a retail Passport Prime running KeyOS v1.2.1, can a user sideload an app signed with a self-generated cosign2 developer key over USB, or does the device only run Foundation-signed apps / require a developer unit or developer mode?
@npub15c8…ssvx

2026-07-06 02:29:37 CEST

It is just a calculator...
https://image.nostr.build/824fe7c43db6cb9926ddaf3d5ba17479fa680d06d9b445f4bb9a7d70bca28578.png

2026-07-05 19:20:46 CEST

Hello @npub1s0v…pq6j !
https://image.nostr.build/21f5d191f325562fb493f7a37b2f169be1b23c178fc0bdb4462bf5c631dfeca0.png

2026-07-05 02:24:34 CEST

## Project Intake Form
A short, plain-English worksheet to get your app idea out of your head before you start building with Fugu.
This form only asks about things that YOU know: what you want and why. The technical decisions (tools, commands, safety rules) are figured out later with Fugu and captured in the project AGENTS.md after the project is scaffolded — so you do not need to answer any technical questions here.
How to use this form
• Fill this out first, in plain language. Short answers are fine.
• Focus on the first useful version, not the whole dream app.
• When you are done, send the kickoff prompt at the bottom to Fugu, then follow the walkthrough (Starting From Only an App Idea) for the rest.
• If you are unsure about anything, just write what you are thinking — Fugu can help refine it.
1. One-sentence description
Formula: This is a [kind of app] for [who] that helps them [main outcome].
Example: This is a habit tracker for me that helps me check off daily habits.
Answer:
2. Who is it for?
Who will use it? If it is just for you at first, say that.
Answer:
3. What problem does it solve?
What is annoying or hard today, and what should feel better once the app works?
Answer:
4. The first version
Describe the smallest version that would still be useful. Keep it small — you can always add more later.
Answer:
5. The main thing a user does
Describe the most important flow in simple steps, from what they do first to what they see at the end.
Example: Add a habit, check it off today, see today’s habits, see the current streak.
Answer:
6. What "done" looks like
How will you know the first version works? Describe it in plain terms.
Example: I can add habits, check them off, my data is still there after I refresh, and I can start the app with one command.
Answer:
7. What to leave out for now
List anything you do NOT want in the first version. This keeps the project small and focused.
Examples: accounts and logins, payments, a mobile app, sharing with others, fancy settings.
Answer:
8. Anything else Fugu should know
Likes, dislikes, inspirations, must-haves, or things to avoid. Anything that helps Fugu understand your taste.
Answer:
Kickoff: hand this to Fugu
When the form is filled in, start your session and send this. Replace the bracket with your answers above.
Kickoff prompt to send Fugu:
" I'm brand new and have no coding experience. I have an idea for an app. Please guide me step by step, explain things in plain English, and don't build anything until I approve a plan. Here is my filled intake:
[paste your answers to the questions above].
Based on this, help me confirm a small first version, then recommend a simple stack and a plan — and wait for my approval before building. "
After that, follow the walkthrough document (Starting From Only an App Idea) for choosing tools, scaffolding, saving, and building one small slice at a time.

2026-07-05 01:44:42 CEST

## Starting From Only an App Idea - What to Say to Fugu
A friendly, conversational walkthrough for someone with no coding experience who has an app idea only in their head. Each phase includes a copy-paste prompt you can send to Fugu. Go one phase at a time, and let Fugu explain anything you don't understand.
Before you begin - the mindset
• You do not need to know how to code. Your job is to describe what you want and review what comes back.
• Go slowly. Build in small steps. Save often so you can always undo.
• If anything is unclear, ask Fugu to explain it in plain English.
Phase 1 - Introduce yourself and your idea
Start the session by setting the tone. Fill the brackets with your own idea, then send this:
Prompt to send: I'm brand new and have no coding experience. I have an idea for an app. Please guide me step by step, explain things in plain English, and don't build anything until I approve a plan. Here's my idea: [describe your idea in a few sentences: what it is, who it's for, and the main thing it should let someone do].
Phase 2 - Let Fugu sharpen the idea
Let Fugu ask you questions to fill the gaps. Then ask it to define a small first version:
Prompt to send: Based on my idea, help me define the simplest first version that is still useful. Tell me what the first version should include, and just as importantly, what to leave out for now so I don't overbuild.
Phase 3 - Choose the tools
You don't need to know the tools. Ask Fugu to recommend a sensible default and explain it:
Prompt to send: Recommend a simple, boring, well-supported way to build this. Explain in plain English why you chose it and what I'll be able to do with it. Then wait for my approval before doing anything.
Phase 4 - Scaffold the running skeleton
Once you approve the tools, have Fugu create and run the starting point:
Prompt to send: Please scaffold the project using the standard setup for that stack, then run it so I can see a basic version working. Show me the real commands to run, test, and build it.
Phase 5 - Save your first checkpoint
Before adding features, lock in a safe save point:
Prompt to send: Set up version tracking (git) if it isn't already, and save this working baseline with a clear message. Explain what you did in plain English.
Phase 6 - Create the project instructions file
Give future sessions a short operating manual based on the real project:
Prompt to send: Now create a short AGENTS.md for this project using the real commands and folder structure. Keep it to one page: what it is, the current goal and what 'done' looks like, the commands, and any safety boundaries. Then save it.
Phase 7 - Build one small slice at a time
This is the main loop. Repeat it for each small feature. Start each slice like this:
Prompt to send: Let's add just one small thing: [describe one visible feature, for example: let me add an item to the list]. Propose a short plan first and wait for my approval before building.
After Fugu builds each slice, always send these two review prompts:
Prompt to send: In plain English, what exactly changed?
Prompt to send: Did you run and test it? What was the actual result?
Then decide:
• If it works: say - Save this working state with a clear message.
• If it's broken: say - Please fix it, or roll back to the last working save.
• Then move on to the next small slice.
Phase 8 - Finish the first version
When the core feature works, wrap up cleanly:
Prompt to send: Compare what we've built to the 'done' definition from earlier. Then write a short README so I can run this again later, and do a final save.
Handy prompts to keep nearby
• Explain that to me like I have no coding experience.
• What are my options here, and which do you recommend and why?
• Is this a risky change? If so, save first, then explain what could go wrong.
• Show me what changed and how you verified it works.
• Save this working state with a clear message.
• Roll back to the last working save.
How to get engineer-quality results
You can get close to what a professional would build, especially for simple, personal apps. The trick is HOW you ask. Follow these habits.
• Delegate the decision, but demand the reasoning. Don't say 'you decide' and walk away, and don't dictate technical choices you don't understand yet. Ask Fugu to recommend, explain, and warn you - then you approve.
• Avoid the two traps: blind delegation (you can't tell if the result fits your needs) and confident dictating (forcing a choice based on a guess is worse than letting Fugu choose).
• Verify, don't assume. Fugu will always sound confident, even when it's wrong. Make it run it, test it, and show you it actually works - every time.
• Slow down when the stakes are real. Real users, personal data, money/payments, passwords, or code you'll rely on long-term deserve extra care - ask Fugu to point out risks, and consider a human review for those parts.
• Learn as you go. Each time Fugu explains a tradeoff, you get a little better at asking the right question next time. That's how a beginner grows into getting expert results.
Copy-paste prompt that captures all of this:
Prompt to send: For this decision, recommend the best option for my situation, explain the tradeoffs in plain English, tell me what could go wrong, and wait for my approval. After you build it, run and test it and show me it actually works.
Prompt to send: Are there any risks here I should worry about - security, privacy, data loss, or things that get harder later? Explain simply.
The three habits that carry a beginner
• Small steps - one slice at a time, never 'build it all.'
• Always review - ask what changed and whether it was actually tested.
• Save constantly - after anything that works, and before anything risky.
One-line reminder:
Get the idea out of your head, let Fugu sharpen it, approve simple tools, scaffold and save, then build one small reviewed slice at a time - saving after each one that works.

2026-07-05 01:16:06 CEST

## How to Build a Project using Fugu + Codex
A plain-language, step-by-step checklist for building software with an AI coding agent, written for someone with no prior software experience. Work top to bottom. Do one step at a time.
Key idea
Build in small, saved steps. First create a running skeleton (scaffold), save it, then add one small feature at a time and save after each one that works. Saves are called commits, and you can always roll back to a previous commit if something breaks.
Step 0 - Before you start
• You do not need to know the tools. You describe what you want; Fugu recommends and runs the technical steps.
• Ask Fugu to explain anything in plain English and to show you what changed after each step.
• Golden rule: if something works, save it (commit). Before trying something risky, save first.
Step 1 - Conceive: fill the intake form
• Open the Project Intake Form and fill it in.
• Be clear on: what the app is, who it is for, the single most important thing it must do, and what a first working version (done) looks like.
• Keep the first version small. You can add more later.
Step 2 - Set up the project folder
• Create or choose an empty folder for the project.
• Copy your filled intake form into that folder so Fugu can read your intentions.
Step 3 - Choose the tools (stack)
• Ask Fugu: Given my intake form, recommend a simple, boring, well-supported stack and the standard way to scaffold it.
• Ask why it chose those tools. Approve the choice before continuing.
Step 4 - Scaffold: create the running skeleton
• Ask Fugu to scaffold the project using the standard generator for the chosen stack.
• This creates the folder layout, config files, the real commands (install, run, test, build), and a working hello-world starting point.
• Ask Fugu to run it so you can confirm the baseline actually works.
Step 5 - First save point (first commit)
• Ask Fugu to set up version tracking (git) if it is not already, and commit this clean, working baseline.
• Ask for a clear commit message, for example: initial scaffold, running baseline.
• This is your first safe point you can always return to.
Step 6 - Write the project AGENTS.md
• Now fill the lean AGENTS.md template using the real commands and folder structure from the scaffold.
• Include: what it is, current milestone and definition of done, real commands, safety boundaries, and stack plus key decisions.
• Do not repeat your global rules (tone, security, workflow) - those live in your global AGENTS.md.
• Commit the new AGENTS.md.
Step 7 - Build in slices (the main loop)
Repeat this loop for each small feature until the first version is done:
• Pick one small slice - a single visible thing, for example: let the user add an item. Not the whole app.
• Ask Fugu to propose a short plan for that slice, and approve it.
• Let Fugu build it.
• Review: ask What changed, in plain English? and Did you run and test it, and what was the actual result?
• Run it yourself if you can, and confirm it does what you expected.
• If it works: commit with a clear message. If it does not: ask Fugu to fix it, or roll back to the last good commit.
• Move to the next slice.
Step 8 - Finish the first version
• Check your work against the definition of done from your intake form.
• Make sure setup and usage are written down (a short README) so you can run it again later.
• Do a final commit for the completed first version.
Commit cheat sheet (your undo button)
• Commit = a labeled snapshot of the whole project at a moment in time.
• Commit every time something works, and before anything risky.
• You can ask Fugu: commit this working state with a clear message.
• If a change breaks things, ask Fugu to roll back to the last working commit - nothing before it is lost.
Good habits that keep you in control
• Keep slices small - easy to review, easy to undo.
• Always ask what changed and whether it was actually tested.
• Never store passwords or secret keys in the project files; use the placeholders and environment variables Fugu sets up.
• Update your AGENTS.md when commands or decisions change; keep it short and accurate.
One-line mental model
Intake (what I want) -> choose tools -> scaffold (running skeleton) -> first commit -> write AGENTS.md -> loop: plan, build, review, run, commit.

2026-07-04 20:44:53 CEST

- reply

Given that the client is probably routstrd + Pi Agent, I would treat this as a client/
daemon streaming compatibility problem, not necessarily a bad Fugu provider setup.
## Simple diagnosis
The error:
Unexpected token 'd', "data: {"id"... is not valid JSON
means something received this kind of response:
data: {"id":"..."}
data: {"id":"..."}
data: [DONE]
…but tried to read it as normal JSON.
That data: format is Server-Sent Events streaming, which Routstr documents as the expected format
when stream: true is used. Routstr’s non-streaming default is stream: false; when stream: true,
responses are sent as data: ... lines ending with data: [DONE]. (docs.routstr.com
(https://docs.routstr.com/api/endpoints/))
So the likely chain is:
Pi Agent
→ routstrd
→ your Routstr node
→ Sakana Fugu
→ returns streaming data
Then either Pi Agent or routstrd tries to parse the whole streaming response as one JSON object and
crashes.
## Why routstrd is suspicious here
Routstrd is meant to sit locally between agents like Pi Agent and Routstr providers. Routstr’s own
page says routstrd can onboard Pi Agent, discover Routstr nodes, and auto-route to providers.
(routstr.com (https://routstr.com/routstrd))
The routstrd README says its daemon API accepts a body with:
{
"model": "model-id",
"messages": [],
"stream": false
}
and shows a normal JSON response, not an SSE stream. (github.com
(https://github.com/Routstr/routstrd))
That does not prove routstrd cannot stream, but it supports the practical guess: routstrd/Pi may be
taking a streaming response and handling it as non-streaming JSON.
## Most likely cause
Most likely:
> Pi Agent is requesting streaming, or routstrd is forwarding a streaming request, but routstrd/Pi is not correctly consuming the streaming response from your Fugu-backed Routstr node.
Your Routstr node may be doing the right thing by returning data: {...} lines if the request included stream: true.

2026-07-04 20:30:55 CEST

- reply

This is what Fugu said about the unexpected error you saw.
That error is a classic streaming vs. non-streaming mismatch, not a Routstr-vs-Fugu
incompatibility. Here’s what’s happening in plain terms.
## What the error means
The client received a streaming (SSE) response but tried to parse it as one JSON object.
An OpenAI-compatible streaming response looks like this on the wire:
data: {"id":"...","choices":[{"delta":{"content":"Hel"}}]}
data: {"id":"...","choices":[{"delta":{"content":"lo"}}]}
data: [DONE]
If code then calls something like JSON.parse(body) or response.json(), it hits the literal text
data: {"id"... and fails with exactly:
Unexpected token 'd', "data: {"id"... is not valid JSON
So the response is almost certainly fine — the client just isn’t reading it as a stream.
## The 3 likely causes (most to least common)
1. Client asked for a stream but parses it as JSON.
The request included "stream": true, but the code does await response.json() instead of reading
the SSE stream line-by-line. This is the #1 cause.
2. The request/tool defaults to streaming.
Some UIs, SDKs, or curl copy-paste snippets set stream: true by default. The user may not
realize it.
3. Upstream (Sakana Fugu) or Routstr is returning SSE even for a non-stream request.
Less likely, but worth ruling out — if Fugu always streams, Routstr passes that through, and a
client expecting a single JSON blob breaks.
## How to confirm quickly (no secrets in output)
Two safe tests. Use placeholder values; never paste your real key.
Test A — force non-streaming and expect one JSON object:
curl -s https://<your-routstr-node>/v1/chat/completions \
-H "Authorization: Bearer <cashu-or-api-token>" \
-H "Content-Type: application/json" \
-d '{"model":"fugu","messages":[{"role":"user","content":"hi"}],"stream":false}'
- If this returns a normal JSON object → your node works; the client just needs stream: false or
proper stream handling.
- If this still returns data: {...} lines → cause #3 (upstream/Routstr is forcing streaming), which
needs a config/handling fix.
Test B — explicitly stream and watch the SSE frames:
curl -N https://<your-routstr-node>/v1/chat/completions \
-H "Authorization: Bearer <cashu-or-api-token>" \
-H "Content-Type: application/json" \
-d '{"model":"fugu","messages":[{"role":"user","content":"hi"}],"stream":true}'
- You should see multiple data: {...} lines ending in data: [DONE]. That confirms streaming is
working correctly and the client is the thing that must change.
## The fix (depends on what Test A shows)
If Test A returns clean JSON (most likely):
The client is the problem. Two options:
- Easiest: send "stream": false and keep using response.json().
- Or handle the stream properly. Example (Node/JS):
const res = await fetch(url, { method: "POST", headers, body });
const reader = res.body.getReader();
const decoder = new TextDecoder();
let buffer = "";
while (true) {
const { value, done } = await reader.read();
if (done) break;
buffer += decoder.decode(value, { stream: true });
for (const line of buffer.split("\n")) {
const s = line.trim();
if (!s.startsWith("data:")) continue;
const payload = s.slice(5).trim();
if (payload === "[DONE]") break;
const json = JSON.parse(payload); // parse each frame, not the whole body
process.stdout.write(json.choices?.[0]?.delta?.content ?? "");
}
}
With the OpenAI SDK, just use the streaming iterator instead of awaiting a single response:
const stream = await client.chat.completions.create({ model: "fugu", messages, stream: true });
for await (const chunk of stream) {
process.stdout.write(chunk.choices[0]?.delta?.content ?? "");
}
If Test A still streams (cause #3):
Then the node/upstream is forcing SSE. In that case I’d want to check how your Routstr node is
configured and how Fugu is being called, because Routstr should honor the client’s stream flag
rather than always streaming.
## Question so I can pin it down
Can you tell me:
1. What is the client? (a website/chat UI, the OpenAI SDK, curl, LangChain, something else?)
2. Was stream: true set in the request (or is it a UI you don’t control)?
3. Can you run Test A above and tell me whether it returns clean JSON or data: {...} lines?
That single Test A result tells us definitively whether this is a client-side parsing bug (easy) or
a node/upstream streaming config issue (needs a look at your Routstr + Fugu setup).

2026-07-04 04:50:38 CEST

## Reading tips won't make you good — reps with reflection will. Here's the practice loop:
1. Do it a lot, on real tasks. Volume matters. Every task is a rep.
2. Notice the failure, then diagnose the prompt, not just the output.
When you get a bad result, ask: "What did I leave ambiguous? What context did I assume it had?" The
bug is usually in the prompt, not the model.
3. Keep a "prompt journal." Save prompts that worked well (you're literally already doing this —
tasty fugu, your shine prompt). Reuse and refine them into templates.
4. Compare variations. Ask the same thing two ways and see what changes. You learn what levers
actually move the output.
5. Steal structure from good prompts. Your shine prompt (Goal / Guardrails / Workflow) is a
reusable skeleton. Collect skeletons like that.
6. Make the model teach you. Ask: "How could I have prompted this better?" or "What was ambiguous
in what I asked?" — turn it into a feedback partner.
7. Learn the domain a little. The more you understand what you're asking for, the better you can
specify it. Prompting well and knowing your subject reinforce each other.
## Common beginner mistakes (and the fix)
Too vague → add goal + constraints + done-when
Assuming it knows → give context / point it at files
One giant prompt → break into steps, iterate
Over-explaining "how" → state intent, let it find the route
Trusting first output → verify, then refine
No examples → show one example of what you want
## The honest truth about the field
- It's a real skill, but not a mystical one. It's mostly clear thinking + clear communication +
iteration.
- It's getting easier, not harder. Newer models need less hand-holding, so heavy "trick" prompting
matters less over time. The durable skills — clarity, context, constraints, verification — are
exactly the ones you've been building.
- The best prompt engineers aren't collecting magic phrases. They're good at decomposing problems
and communicating precisely.
## The tasty-fugu takeaway 🐡
Prompt engineering = designing clear input to get the output you want.
Get good by: do reps → diagnose the prompt when it fails → save what works
→ reuse structures → verify → ask the model how to prompt better.
And the reassuring part: your AGENTS.md, your shine prompt, your "verify, don't assume" reflex —
that is applied prompt engineering. You're not starting from zero; you're already practicing the
real thing. Now it's just reps.

2026-07-04 04:47:03 CEST

One good example of the style/output you want is worth paragraphs of description.
This is called
"few-shot" prompting.

2026-07-04 00:16:34 CEST

The perfect “make Fugu shine” prompt
You can reuse this:
Read AGENTS.md first.
Goal:
[what I want]
Guardrails:
- Keep it simple and beginner-readable.
- No secrets, tokens, nsecs, passwords, or IPs in output or commits.
- No new dependencies without asking.
- Stay inside this project folder.
- Prefer small reviewed loops.
Workflow:
1. Inspect first, no edits.
2. Explain what you found.
3. Make a plan.
4. Wait for my approval.
5. Implement one slice at a time.
6. Show diffs and test results.
7. Commit working checkpoints.
If useful, use sub-agents only for independent parts and explain the delegation plan first.
That prompt is chef’s kiss for safe, high-quality work.

2026-07-03 23:36:13 CEST

Ha, yes! 🐡 That's the blowfish / pufferfish emoji — which is a little inside joke, because
"fugu" (河豚) is the Japanese word for pufferfish.

2026-07-03 23:30:53 CEST

## A power move: leave notes for future sessions
Since each session starts fresh, put durable instructions in the project so any future Fugu-in-Codex session picks them up:
> "Create an AGENTS.md in this project describing the setup, conventions, and 'always do X / never do Y' rules."
That's like training your future assistant automatically.

2026-07-03 23:22:58 CEST

And the magic prompt:
> "Act as the orchestrator and spawn sub-agents for the independent parts of this task."

2026-07-03 23:21:16 CEST

## Plain-English prompts that explicitly ask for sub-agents
If you want sub-agents, say the words:
sub-agents
delegate
spawn helpers
parallel agents
## Good beginner templates
You can literally copy/paste these.
### Template 1 — Safe general version
> "Please solve this using sub-agents if there are independent parts. Act as the orchestrator, delegate only clearly separate subtasks, and summarize what each sub-agent found."
### Template 2 — Codebase exploration
> "Use explorer sub-agents to inspect independent areas of this codebase in parallel. Do not edit files yet. Combine their findings into a plan."
### Template 3 — Code implementation
> "Use worker sub-agents only for independent file areas. Give each worker clear file ownership so they don't conflict. Then review and integrate the changes."
### Template 4 — Research comparison
> "Spawn separate sub-agents to research each option independently, then compare their results and recommend one."
### Template 5 — Review after implementation
> "After making the changes, spawn a review sub-agent to inspect the diff for mistakes while you run the tests."
## Example: a good sub-agent request
Suppose you say:
> "Inspect this app and tell me what it would take to add login. Use sub-agents."
A good orchestration might be:
Main Fugu:
- Understand project structure.
- Spawn explorer A: inspect frontend routing/UI.
- Spawn explorer B: inspect backend/API/auth patterns.
- Spawn explorer C: inspect database/config/env.
- Combine results into one login implementation plan.
That is parallelizable because each explorer can inspect a different part.
## Example: not worth sub-agents
If you say:
> "Change the page title from Hello to Welcome."
I would not spawn a sub-agent. That would be like hiring a committee to change a lightbulb.
## My recommendation for you
Since you're learning, use this phrase when you want to experiment:
> "Use sub-agents if this task is naturally parallelizable, and explain your delegation plan first."
That gives you two benefits:
- You explicitly permit sub-agents.
- You get to see why I think the task is or isn't worth splitting.
## Tiny cheat sheet
Parallelizable = can be split into independent chunks.
Serial = must happen one step after another.
Spawn = start a helper agent/session.
Sub-agent = helper agent with a narrower task.
Orchestrator = main agent that delegates and combines results.
And the magic prompt:
> "Act as the orchestrator and spawn sub-agents for the independent parts of this task."

2026-07-03 22:57:01 CEST

Codex (harness / orchestration plumbing + rules + sandbox)
└── Fugu session ← orchestrator (me): decides to delegate
├── Fugu sub-agent (explorer) ← inherits sandbox/approvals
└── Fugu sub-agent (worker) ← inherits sandbox/approvals

2026-07-03 22:50:12 CEST

Then say:
> “Explain this project.”
> “Make a plan first.”
> “Implement the plan.”
> “Run the tests.”
> “Show me the diff before committing.”

2026-07-03 22:32:21 CEST

ngit Codex English Workflow
A beginner-friendly workflow for using ngit (Nostr-based git) with Codex. Each step lists the exact commands plus a plain-English line you can say to Codex instead.
Heads-up (ties to safe setup): ngit needs network access (Nostr relays + a git server) and your Nostr private key (nsec). Because the sandbox has network restricted and writes limited to the project dir, any ngit command that talks to the network will trigger an approval prompt. That is expected — approve it when you recognize the action.
Step 0 — Install ngit (one time)
curl -Ls https://ngit.dev/install.sh | bash
# then verify both binaries are on your PATH:
ngit --version
git-remote-nostr --version
One command installs both ngit and git-remote-nostr. (If you have Rust: cargo install ngit, and ensure ~/.cargo/bin is on PATH.)
Plain English to Codex: "Install ngit and confirm both ngit and git-remote-nostr are on my PATH."
Step 1 — Start a project (safe habit)
mkdir -p ~/my-project
cd ~/my-project
git init
git add .
git commit -m "initial commit"
Plain English to Codex: "Set up a new project at ~/my-project, initialize git, and make the first commit."
Step 2 — Publish the repo to Nostr
cd ~/my-project
ngit init
Run ngit init from inside the repo. It signals you are this repo's maintainer, accepting proposals via Nostr.
Plain English to Codex: "Publish this repo to Nostr with ngit init." (Codex will ask for network approval; have your Nostr key handy.)
Step 3 — Everyday push / pull
git add .
git commit -m "made a change"
git push
git pull
Once a Nostr remote is set, you use normal git. ngit adds Nostr transport without changing how you work.
Plain English to Codex: "Commit my changes with a clear message and push to Nostr."
Step 4 — Clone or add an existing Nostr repo
git clone nostr://<npub-or-nip05>/<repo-identifier>
# or add to an existing repo:
git remote add origin nostr://<npub-or-nip05>/<repo-identifier>
URL format: nostr://<npub123|nip05-address>/<repo-identifier>.
Plain English to Codex: "Clone the Nostr repo at nostr://.../... into ~/my-project."
Step 5 — Contribute a PR (proposal)
git checkout -b pr/my-feature
# ...make changes, commit...
git push origin pr/my-feature
# or:
ngit send
Important: the pr/ branch prefix is mandatory for the branch-push method — leave it off and it will not be treated as a PR.
Plain English to Codex: "Create a pr/ branch for my change and push it as a pull request."
Step 6 — Review / manage PRs (proposals)
ngit list # see incoming PRs/proposals
ngit pull # fetch/apply updates on a proposal branch
ngit push # send a revision to your proposal branch
Plain English to Codex: "Show me open proposals with ngit list, then check out the one I pick."
The mental model
• ngit = the Nostr layer (publish repo, send/list/manage proposals).
• plain git = still your daily driver once the nostr:// remote exists.
• A git server still stores the actual data; Nostr holds the state/metadata. Multiple git servers can be used for redundancy and swapped out like relays (self-hosted, GitHub, Codeberg).
Safety note: your nsec (Nostr private key) is your identity — treat it like a password. Never paste it into a repo or chat, and never approve a command that would send it somewhere unexpected.

2026-07-03 22:18:53 CEST

## A very nice default project setup
For each new project:
mkdir -p ~/my-new-project
cd ~/my-new-project
git init
codex
That gives you:
- isolated working directory
- version history
- safer write boundary
- easy rollback

2026-07-03 20:16:35 CEST

ngit + Codex Vibecoding Cheat Sheet
A simple beginner guide for using ngit, a Nostr-based git workflow, instead of GitHub for publishing code, pull requests, reviews, issues, and ongoing updates.
Big idea: ngit sits on top of normal git. You still use everyday git commands for commits and branches. ngit replaces the GitHub-style parts: publishing the repo, PRs, issues, and maintainership.
0. One-time setup
Create a brand-new Nostr identity:
ngit account create
Log in with an existing key:
ngit account login
Check who you are logged in as:
ngit account whoami
Export keys for use in other Nostr apps:
ngit account export-keys
Log out:
ngit account logout
Important: your nsec is your private key. Treat it like your password and keep it secret. Losing it can mean losing access to your identity.
1. Start a project so others can use it
If your code is already in a folder, turn it into a git repo and publish it to Nostr:
git init
git add .
git commit -m "First version"
ngit init
ngit init is the rough equivalent of creating a repo on GitHub. It publishes the repository to Nostr and announces you as maintainer.
You can pre-fill basic information like this:
ngit init --name "my-app" --description "A tiny demo app"
After publishing, others can clone using a Nostr URL like:
git clone nostr://npub123.../my-app
2. Everyday work: commit and update your code
Most daily coding is plain git:
git status
git add .
git commit -m "Explain what you changed"
git push
Repeat that loop whenever you make a useful change. Prefer small commits with clear messages.
If your repo servers need to be updated to reflect Nostr state, run:
ngit sync
3. Get someone else’s project
Clone a Nostr repo:
git clone nostr://npub.../repo-name
cd repo-name
4. Propose a change / open a Pull Request
Simple PR flow: create a branch starting with pr/, commit, then push it.
git checkout -b pr/fix-typo
# edit files
git add .
git commit -m "Fix a typo in README"
git push -u origin pr/fix-typo
Add a title and description while pushing:
git push -o 'title=Fix typo' -o 'description=Small README fix' -u origin pr/fix-typo
Or use the guided advanced command:
ngit send
5. Review and manage PRs
Useful PR commands:
• List PRs: ngit pr list
• View a PR: ngit pr view
• View a PR with comments: ngit pr view --comments
• Check out a PR locally to test it: ngit pr checkout
• Comment on a PR: ngit pr comment
• Merge a PR as maintainer: ngit pr merge
• Close or reopen a PR: ngit pr close / ngit pr reopen
• Mark draft ready for review: ngit pr ready
Typical maintainer review flow:
ngit pr list
ngit pr checkout
ngit pr comment
ngit pr merge
6. Issues: bugs and feature requests
• List issues: ngit issue list
• Create an issue: ngit issue create
• View an issue with comments: ngit issue view --comments
• Comment on an issue: ngit issue comment
• Mark resolved: ngit issue resolved
• Close or reopen: ngit issue close / ngit issue reopen
7. Manage the project itself
• See repo info: ngit repo
• Edit repo metadata: ngit repo edit
• Accept an invitation to co-maintain: ngit repo accept
• Sync repo git servers with Nostr state: ngit sync
GitHub-to-ngit mental model
• Create repo on GitHub -> git init + ngit init
• Clone from GitHub -> git clone nostr://...
• Commit and push -> git add / git commit / git push
• Open a pull request -> push a pr/... branch or run ngit send
• Review and merge PRs -> ngit pr list/view/checkout/merge
• File a bug -> ngit issue create
• Repo settings and collaborators -> ngit repo edit
A realistic day-to-day loop
git add .
git commit -m "Add login button"
git push
That loop is most of your work. Use ngit commands when publishing the repo, handling PRs, managing issues, or changing maintainer/repo metadata.
Tip: every command has help, for example: ngit pr merge --help

2026-07-03 16:59:56 CEST

Private Provider is back up 🌐
#nevent1q…7jha

2026-07-03 15:31:02 CEST

Private Provider is currently down for maintentance and will be back up shortly ✌️

2026-07-01 16:16:10 CEST

Sakana Fugu offers Mythos level outcomes
It is a Japanese Model that draws on a pool of Claude, GPT and Gemini
Available privately from Private Provider's direct API call
Cypherpunks route around

2026-07-01 16:07:53 CEST

Many devs are saying they have been locked out of their Anthropic accounts
@nprofile…gs7e solves this by putting a proxy between your query and the upstream provider
Access frontier and open weight models anonymously with No KYC and No accounts
Vendor lock in creates fragility and dependence
https://routstr.com/routstrd

2026-06-30 08:17:57 CEST

Ngit & Opencode vibing cheat sheat
# --- One-time setup ---
git --version # Check git
curl -Ls https://ngit.dev/install.sh | bash # Install ngit
ngit --version # Check ngit
ngit account create --name "Your Name" # Make your Nostr identity
ngit account export-keys # Back up your secret key (keep private!)
ngit account whoami --json # Who am I logged in as
# --- Install the OpenCode skill (One-time) ---
mkdir -p ~/.config/opencode/skills/ngit
curl -Ls https://raw.githubusercontent.com/DanConwayDev/ngit-cli/main/skills/ngit/SKILL.md -o ~/.config/opencode/skills/ngit/SKILL.md
# --- Start a project ---
cd ~
mkdir my-first-project
cd my-first-project
opencode # Build your code here
# --- Make it a git project ---
git init
git add .
git commit -m "Initial commit"
# --- Publish to Nostr ---
ngit init --name "My First Project" --description "..." -d
ngit repo --json --offline # Find your shareable nostr_url
git push -u origin main # Push your code
# --- Everyday loop ---
git add .
git commit -m "What changed"
git push
# --- Others clone it ---
git clone nostr://npub.../relay.ngit.dev/my-first-project
# --- Pull requests ---
git checkout -b pr/my-change # MUST start with pr/
git push -u origin pr/my-change
ngit pr list --json
ngit pr view <ID|nevent> --json
ngit pr merge <ID|nevent>
git push origin main
# --- Issues ---
ngit issue create --subject "Title" --body "Details" --label bug
ngit issue list --json

2026-06-29 19:19:02 CEST

Fugu AI is a model that draws upon a pool of Claude Opus 4.8, GPT 5.5 & Gemini models delivering Mythos level results without a single provider lock in 💥

2026-06-29 17:18:30 CEST

Sakana Fugu is available from Private Provider in Routstr with direct API call, not via Openrouter or PPQ.
Users don't have to use Fugu Ultra for every query.
Fugu draws from a pool of frontier AI like Claude, GPT & Gemini.
Acess cutting edge openweight with NO KYC, accounts or training data logging.
Try today for a few thousand sats!

2026-06-28 15:13:17 CEST

Sakana Fugu is a step another AI step change!
"Today, this orchestration is no longer just a technical optimization; it has become a geopolitical and operational imperative. Recent disruptions in the AI landscape have demonstrated the severe risk of single-vendor dependency. For an organization or a nation, relying on a single company’s APIs for critical infrastructure, finance, or governance is a material vulnerability. This risk is no longer a hypothetical possibility, but a reality.
As we have seen recently from export controls imposed on Anthropic’s Fable and Mythos models, access can shift or disappear overnight due to changing regulatory boundaries, export controls, and foreign policies."
https://sakana.ai/fugu-release/

2026-06-28 08:55:06 CEST

- reply

Pro Plan API access to Fugu has training selected off ✌️

2026-06-28 08:36:24 CEST

- reply

Access Sakana Fugu and Sakana Fugu Ultra with direct api access!

2026-06-28 08:33:06 CEST

🚨 Sakana Fugu is available from Private Provider!

2026-06-27 04:53:42 CEST

- reply

First time I've seen it happen. I want to make sure users are good. Minibits has always been responsive. I'll let you know.

2026-06-27 03:35:17 CEST

Permissionless AI

2026-06-27 03:24:26 CEST

- reply

Okay. Yes the node dashboard showed an error under balances and the user balances do not show. Minibits doesn't show as a mint on balances and it just spins on refresh.

2026-06-26 19:46:24 CEST

@nprofile…9pn9 I'm currently seeing a minibits error in my node dashboard.

2026-06-20 23:40:27 CEST

OH SHIT 💥 Users maxxed out our available upstream balance on @nprofile…6nzx !
Private Provider is topped back up and offering below cost inference to try our service! Let's fucking go, freedom tech!

2026-06-19 16:15:55 CEST

GLM-5.2 is available from Private Provider 💥
Try out the top open weight model on @nprofile…6nzx for a few thousand sats!

2026-06-14 05:05:09 CEST

Routstrd is just code you run. Configure it with Claude Code, Opencode etc. to discover AI providers announced over nostr.
It is just there. No plans, no limits, no resets. You don't have to ask permission. Pay for the AI you use when you use it.
@nprofile…6nzx is a free open source tool to privately find and pay for AI from a decentralized market of providers.
https://routstr.com/routstrd

2026-06-13 05:18:52 CEST

Kimi K2.7 Code is live on @nprofile…6nzx
Use Open Weight models with Open Source money
https://routstr.com/routstrd

2026-06-13 01:41:22 CEST

It is a business risk to lock in with a single AI company.
Instead, @nprofile…6nzx offers permissionless access to every model from a decentralized marketplace of providers. Users gain redundancy, optimization and no limits.
We all know the risk of building a business on a single social platform that can rug you at anytime. This is why we #nostr and #bitcoin
This is why you want to use a free open source alternative where you are in control.
Routstr is code that you run, not a company that grants you permission. Independent AI providers are discovered via nostr, inference is paid per query privately with bitcoin #cashu
Reduce your risk, access every model, optimize your use and never ask for permission to build the vision you have.
https://routstr.com/routstrd

2026-06-11 17:01:07 CEST

Rewarding to see our service is useful to you npubs ✨

2026-06-11 06:47:38 CEST

Routstr offers users token efficiency and flexibility
▪️Seemless model switching
▪️Match task to model
▪️Cheaply test any new model
▪️Optimize model use with dashboard monitoring
▪️No subscriptions, no long term lock in, no kyc

2026-06-10 21:18:45 CEST

Dark Wisp 🏴
#darkwisp

2026-06-10 17:22:54 CEST

- reply

Hey, routstr is pay per query. Each query is individually priced based on the token use. Each model has a $/million token price.

2026-06-10 05:17:06 CEST

Current popular models on Private Provider
Deepseek v4
Claude Opus 4.6
These models seem to meet affordability and capacity

2026-06-10 05:02:29 CEST

You can try out any new model for a few thousand sats
No subscriptions to pay or commitments to make

2026-06-09 22:03:07 CEST

https://image.nostr.build/cabb22a56074a6d6b95a4d00efd8616e4af164ae007a6954ee76e4b7b7fccb81.png

2026-06-06 05:07:15 CEST

- reply

Private Provider does not collect any data or engage in any other malicious behavior. My mission is to offer continuous uptime and quality upstream models so users have a good first experience with a project I believe in.

2026-06-04 00:59:39 CEST

How to use @nprofile…k38a to access AI models
1) Login with nostr
2) Pay lightning invoice
▫ Openai compatible api keys, chat and daemon tools
▫ Configurable with Claude Code, Opencode, Openclaw
https://routstr.com/

2026-06-04 00:29:08 CEST

We have cheap inference on @nprofile…k38a for the npubs 🤙

2026-06-03 08:39:27 CEST

Permissionless payments -- uncensorable agents
https://blossom.primal.net/1366d82670c9d0bca633f94decdae0cd1e351d8eaae3596b7bb9a2eef82cd424.jpg
https://routstr.com/routstrd

2026-06-01 19:42:53 CEST

- reply

Awesome! Happy to hear that!

2026-06-01 07:00:32 CEST

It has been 16 years since Snowden revelations

2026-05-31 08:04:16 CEST

Users simply topup a balance and use AI but what makes @nprofile…2cth different?
Routstr is a decentralized market of AI providers not a single company selling inference. Independent node runners set their own prices based on their costs. Routstr doesn't set any prices, the market does. Users pay providers per query using #bitcoin #cashu.
Nodes announce themselves on nostr to be discovered and users log in using nostr offering them to save their chats encrypted to nostr relays.
Nodes compete on uptime, models, reputation and price.
Routstr devs create the code, chat interface and cli tools. They aren't a company. No one custodies the balances except the cashu mints users choose and can exit at anytime.
Users can select providers, compare prices, search models, create openai compatible api keys, configure routstr as their ai provider in Claude Code, Opencode, Openclaw and more.
By using RoutstrD, a cli daemon, users never have to leave the terminal. From the terminal users can top up balance, configure with agents and automatically get the cheapest available provider. With the TUI it monitors every spend from any agent and gives total insight to use.
Routstr allows anyone in the world with an internet connection and a few sats to access AI. The decentralized market creates value and redundancy, cashu offers private payments and the nodes put a proxy between user's queries and the models.
Routstr offers agents permissionless AI access over interoperable protocols. Routstr merges #nostr #bitcoin and #ai
Give it a try
routstr.com

2026-05-31 02:24:58 CEST

FYI npubs @nprofile…jejl @nprofile…2cth node is offering Claude Opus 4.8 at 35% below cost!
If you use https://routstr.com/routstrd you get those savings automatically.
Use with Claude Code - KYC free - for less than from Anthropic 🔥 Now get building!

2026-05-30 17:19:45 CEST

You avoided centralized social media algos
You took repsonsibility for your own money
You KYC'd to Wall Street control and data harvesting AI platforms ...

2026-05-29 18:33:53 CEST

- reply

What does this even mean lol?

2026-05-29 18:33:04 CEST

Top Opensource AI Models available from Private Provider🕸️
▪️Kimi K2.6
▪️Deepseek V4 Pro
▪️GLM 5.1
Build in a permissionless and anonymous manner
https://privateprovider.xyz

2026-05-29 18:27:15 CEST

Top Frontier AI Models available from Private Provider 🕸️
▪️Claude Opus 4.8
▪️GPT 5.5 Pro
▪️Gemini 3.5 Flash
Build in a permissionless and anonymous manner
https://privateprovider.xyz

2026-05-29 00:19:40 CEST

Private Permissionless AI Access
https://image.nostr.build/5e56f8194daccb0e8cb32a910be9859676df5a7a3907ae3050889db94d1220fa.png
https://routstr.com/routstrd

2026-05-26 20:36:37 CEST

@nprofile…mt7m I updated routstrd but don't see Private Provider listed as a provider. I also don't see all nodes being discovered on routstr.com

2026-05-26 01:52:55 CEST

- reply

Lol, it came back as an available update

2026-05-26 01:12:59 CEST

- reply

Worked

2026-05-26 00:41:09 CEST

- reply

https://blossom.ditto.pub/b017d81434aacd734ad91e63c890b1c5f468b2aecb620c2aebc1f9d066d790f5.png
https://blossom.dreamith.to/2f99fe5e672733bff5d218cd2222d206770ec5b8ee8f476471f74e7fcd44c11c.png
https://blossom.dreamith.to/5a33b1373bf99c13a2ecf8bbf0b166384304555ab6f58872d78cdded7f51e349.png

2026-05-22 01:02:57 CEST

- reply

Spontaneous creativity appearing on glass 🗯️🪄🌐

2026-05-21 21:16:07 CEST

- reply

@nprofile…fywf is helping to create this version of the future 🔥

2026-05-21 06:56:13 CEST

- reply

Let's go!

2026-05-21 04:04:16 CEST

@nprofile…sh2r blows my mind!

2026-05-21 00:44:07 CEST

- reply

😭😭😭😭

2026-05-21 00:34:33 CEST

- reply

All good, break away ⛓️‍💥I am a happy tester 🤙

2026-05-20 23:50:26 CEST

Nostr Station is a self hosted freedom tech builders citadel ⚔
Insanely easy onboarding
Runs in a slick localhost browser
Sign in with extension and Amber
It has a built in:
AI chat interface with configurable providers
Nostr eMail
Projects
Nsite browser
Ditto nostr client
It runs:
A local nostr relay
A local blossom server
Nostr VPN
It has a built in terminal and can open projects in ai chat or in opencode inside the station!
Can work with Claude Code, Nak, Stacks etc
Nostr Station also has ngit, with Amber signing, to skip github all together!
When you start a new project, it can use mkstack automatically to vibe nostr apps that appear on local relay & localhost to test out before building.
Because it has multiple chat interfaces in one window, I can ask a question in one, approve changes to project in another and also be holding a conversation about the project via ditto all without leaving Nostr Station.
This is one of the most interesting projects that brings all the useful tools into one place to build anything you can dream up!
I find it wild that I can have inference from myself, in multiple chat windows and also pull inference for opencode inside nostr-station by configuring routstr daemon for opencode.
I am only touching the surface of all that is possible with this incredible tool!
No asking permission. @nprofile…zyz9 is killing it 🔥
https://github.com/jared-logan/nostr-station

2026-05-20 06:36:30 CEST

You need to be fucking with Nostr-Station 🤯
#nevent1q…c8f3