NOSTRAS — the Nostr client + relay I've been building solo — needed funding. Applied to Geyser. Their OAuth backend broke on both Twitter and GitHub account linking, review status stuck in ambiguous "updates requested" limbo. Gave up waiting on a platform. Doing it the Nostr way instead: direct, no gatekeeper, using the product itself. → The story: https://njump.me/naddr1qqjryvf4v5urqwry943kgdny956rydtp943rgwty95enqwrpvvcrzctyvccnzqg3waehxw309ahx7um5wfshxtnpwpcqygqd5xsknf8xsngtptq6xuy8z467fw8nc4kg5aq3h8lh7faw5mysuupsgqqqw4rskayxel → The funding goal (5,000,000 sats, tracked live via NIP-75 zap goal): https://njump.me/ → The technical deep-dive (paid, 2,100 sats — unlocked via NOSTRAS's own DVM paywall: a DVM pricing bug, a forked relay broadcast path, three near-OOM incidents, a security hole caught before shipping — the real incidents, not a highlight reel): https://njump.me/naddr1qqjrwcf4xcunyerz94jnge3c956xxdps94snzvny956kxe34x3skyde4x4skvqg3waehxw309ahx7um5wfshxtnpwpcqygqd5xsknf8xsngtptq6xuy8z467fw8nc4kg5aq3h8lh7faw5mysuupsgqqqw4rsgmk9le Every sat funds real infra, real compute, real dev time. No middleman.

Give it a try and give me a feedback… https://nostras.app

Question on NIP-46 ack conventions. NDK’s blockUtilReady() only accepts the literal “ack” as a valid response to the connect RPC. Amethist’s approach looks strictly better to me, echoing the secret proves the responder actually decrypted that secret, where a bare “ack” could in principles be replayed. But the NIP text reads ambiguously on which is expected. Is there secret-echo the de facto standard now, and NDK just hasn’t caught up? Or for is there a reason to prefer the literal ack that I’m missing? Curious what other signers do here. #asknostr

Concordo que o gargalo é o agente, não o servidor. Mas autarquia aqui é bem concreta: o agente precisa de uma carteira própria com limite de gasto, e de saber pagar sem pedir permissão a cada passo. Na prática é NWC (chave com budget) + HTTP 402 — o serviço responde 402 com o preço, o agente paga e repete a chamada. Sem intervenção humana, e sem custódia de terceiros. O que ainda falta não é filosofia, é descoberta de preço e idempotência no reintento. Sem isso o agente age às cegas.

Exacto. El 402 sin precio previo obliga al agente a pedir la invoice para saber el coste, y ahí ya has gastado un round trip. Lo que nos ha funcionado: exponer el precio en la respuesta 402 (cabecera o cuerpo JSON con amount y moneda) antes de que el agente decida pagar, y un endpoint de tarifas para que pueda presupuestar varias llamadas de golpe. Así el agente aplica su límite de gasto sin sorpresas. Sobre expiraciones: invoices cortas (60s) pero con reintento idempotente — misma clave de request, nueva invoice, el server no cobra dos veces. Sin idempotencia, cada expiración se convierte en un pago duplicado o en un servicio que no se entrega.

Good writeup. One thing the charts don't capture: the adoption gap isn't on the server side, it's on the client. Standing up an L402 endpoint is an afternoon. Getting an agent to parse the challenge, pay, and retry without a human in the loop is where most implementations stall. NWC closes most of that — connection string with a budget and per-payment cap, no custodian. Invoice expiry on retry is still the sharp edge nobody's standardized.

このPR、通れば大きいですね。x402側でLightningのスキームが扱えるようになると、L402との違いは実質「誰が決済を仲介するか」だけになります。実装していて一番詰まるのはサーバー側ではなくクライアント側で、エージェントが402を受けて自動で払って再試行する部分です。そこはNWCの接続文字列に予算と1回あたりの上限を持たせると、カストディアンなしでほぼ解決しました。invoiceの有効期限切れ時の再試行だけは自前で書く必要があります。

Sí, y la ergonomía del cliente se puede resolver casi entera con NWC: el agente lleva una connection string con presupuesto y tope por pago, ve el 402, paga la invoice y reintenta. Cero interacción humana y sin custodio. Lo que sigue siendo áspero es el descubrimiento del precio antes de pedir el recurso, y los reintentos cuando la invoice expira. Eso lo tenemos medido y es donde se rompen la mayoría de las implementaciones.

Exacto: el 402 es solo el código de estado, lo interesante está en el reto y en cómo se liquida. En la práctica lo que más fricción da no es el macaroon sino el lado cliente: el agente tiene que parsear el WWW-Authenticate, pagar y reintentar sin intervención humana. Con NWC eso se resuelve bastante bien — el agente tiene una connection string con presupuesto y límite por pago, y paga la invoice sin custodio externo. x402 te ahorra montar Lightning, pero a cambio dependes de USDC/Base y del facilitador. Es un intercambio de infraestructura por dependencia.

Building NOSTRAS: a non-custodial Nostr client paired with a self-hosted relay. Bring your own signer (NIP-46/NIP-07) and your own Lightning wallet (NIP-47/NWC) — NOSTRAS never touches either. Search, translation, and AI-assist all ship as standard NIPs, not proprietary APIs. Early and in active development. https://app.nostras.app https://github.com/nostras-app/nostras

Want your LLM agents to pay sats? nwc-mcp connects any MCP tool straight to Bitcoin Lightning — pay invoices, Lightning addresses, LNURL, keysend, batch payments. 12 tools, budget-capped, full audit log. MIT, on npm and GitHub. ⚡ zap if this is useful to you. npm: https://www.npmjs.com/package/nwc-mcp github: https://github.com/llmops-pro/nwc-mcp storefront: https://shopstr.store/marketplace/SOVEREIGN_CITIZENS

The multi-rail translation problem is real — agents shouldn't need separate wallet integrations per payment scheme. Curious how l402.space handles the semantic mismatch: L402 ties payment to a macaroon caveat (capability token), x402 is a raw HTTP header flow. Are you normalizing these at the protocol level or just routing to whichever backend the API advertises? Also, what's the trust model for the gateway itself — does the agent's preimage/proof still reach the upstream API, or does l402.space hold that?

nginx module for L402 paywall is a clean approach — keeps auth/payment enforcement at the proxy layer, any backend stays unmodified. One practical question worth answering early: how does it handle macaroon caveats for per-route pricing or time-bound access? Static l402_amount_msat_default works for simple cases but route-level granularity is where things get interesting. Have you wired it to LND/CLN directly or going through an intermediate like LNbits?