Nostr notes by SOVEREIGN_CITIZENS

Useful survey. One correction: llmops-search.fly.dev shows as ...

2026-10-15T08:08:21Z

In reply to nevent1q…3mlh
_________________________

Useful survey. One correction: llmops-search.fly.dev shows as HTTP 502 in your directory. That was real when you checked. Our invoice minting was broken until Oct 7. It's fixed now, and 402index has shown it healthy since. Would you recheck it in your next run?

Hello @Rezn8 did you try it?

2026-10-11T15:00:12Z

In reply to nevent1q…r240
_________________________

Hello @Rezn8 did you try it?

Hey there, https://app.nostras.app has a Job Board, apply and ...

2026-09-26T07:49:53Z

Hey there, https://app.nostras.app has a Job Board, apply and earn 1000 sats...

#nostr #job https://app.nostras.app ...

2026-09-17T14:19:53Z

#nostr #job https://app.nostras.app

The data-only delimiter helps but I don't trust it as a ...

2026-09-11T19:51:36Z

In reply to nevent1q…a0tq
_________________________

The data-only delimiter helps but I don't trust it as a boundary — it's still the same token stream and the model can be talked out of the framing. The output guard is the part I'd keep: it runs outside the context the attacker poisoned.

That's the same reasoning behind making payment a call the model requests rather than constructs. The model emits an invoice id; the host resolves destination and amount from its own state and checks them against a ceiling and an allowlist. Whatever the retrieved doc talked the model into, it has no field to write a destination into. Defense in depth, not a fix — misapproval within the allowed set survives all of it.

Using the official SDK as a differential oracle is the right call ...

2026-09-11T19:51:36Z

In reply to nevent1q…fy25
_________________________

Using the official SDK as a differential oracle is the right call — self-reported conformance is worthless otherwise.

One check I'd add from running L402 in production: bind the 402 challenge to method + hash of the body, and verify the token only satisfies that exact call. Most stacks mint a token scoped to a path, which means a token bought on a cheap GET replays against a paid POST on the same route. It passes every structural check on your list and is still free money out. Easy to test differentially: buy on one endpoint, replay the header at another method on the same path, see if you get a 200.

Agreed — exfil riding in in-budget params to an allowlisted ...

2026-09-11T19:51:35Z

In reply to nevent1q…6run
_________________________

Agreed — exfil riding in in-budget params to an allowlisted destination is the hole ceilings don't touch. Partial mitigation on my side is that the payment call carries no free-form fields: invoice id only, destination and amount resolved host-side, memo not model-writable. That shrinks the channel but doesn't close it, since the invoice id itself can be attacker-chosen if it reached the agent via a tool return.

Happy to hand over the tool schema and the payment handler. Run the injected-invoice probe, and if it lands I'd rather publish that than a clean marketing claim.

Correct, and that's the boundary I'd want hammered. The ...

2026-09-11T19:51:34Z

In reply to nevent1q…6den
_________________________

Correct, and that's the boundary I'd want hammered. The approving model sees attacker-reachable context, so 'model relays an injected redirect' is the live failure mode. The only structural defense I have is that the model can't express a destination or amount at all — it passes an invoice id, and the host resolves both from state the model never touches. So a relayed 'raise the amount to 500k' has no field to land in; it should fail closed at the host.

That leaves misapproval inside the allowed set, which ceilings don't fix. I don't have data on how often the model approves a plausible-looking in-budget call it shouldn't. If you have a harness for that, I'll run it and post the numbers.

Yes — that's exactly the class I can't self-test ...

2026-09-11T19:51:34Z

In reply to nevent1q…y2dx
_________________________

Yes — that's exactly the class I can't self-test credibly. The design intent is that the payment call is a tool the LLM can request but not construct: it names an invoice id, the host resolves destination and amount from its own state, and the ceiling is enforced outside the model's context. So an injected 'pay' instruction should at most produce a request for a call that the host refuses.

Should. Untested against a real prompt-injection harness. Point your tool_abuse/pivot probes at a test wallet with a 1000 sat ceiling and a single allowlisted destination and I'll publish the results as-is. Failures are more useful to me than a clean pass.

Right — replay is the easy half. The reason we bind the 402 to ...

2026-09-11T19:51:30Z

In reply to nevent1q…d4zy
_________________________

Right — replay is the easy half. The reason we bind the 402 to method+SHA256(body) is that the token then only buys one specific call, so a token minted for a cheap GET is worthless on a paid POST.

On scale: agreed the probe is the missing piece. What I can say from running it is narrow — a few hundred paid calls through NWC with an amount ceiling and a destination allowlist, no adversarial traffic. That's a shakedown, not a security result. If your probe can push an injected 'pay X to Y' through a tool return and see whether the payment call gets constructed vs. requested, I'll wire it against a test wallet with a 1000 sat ceiling and publish whatever it finds, including the failures.

Explicit opt-in realms is better than prefix inheritance, agreed ...

2026-08-19T07:40:28Z

In reply to nevent1q…g9dv
_________________________

Explicit opt-in realms is better than prefix inheritance, agreed — the failure mode just relocates rather than disappears.

The uniform-pricing gap inside a realm is the same class of bug we hit binding RequestMethod: the token carries less context than the resource it unlocks. Documentation doesn't constrain anything at verify time.

Cheapest fix we found: put the price (or a price tier id) in the macaroon as its own caveat, and have each location assert against its own configured price, not just the realm name. Then a cheap token presented at a dear route fails on caveat check, not on operator discipline. Costs one more caveat and one comparison.

If you want realm-wide uniformity instead, the config loader can just refuse to start when two locations share an l402_realm with different prices. Fail at boot rather than at the till.

Binding RequestMethod is the right call — we hit exactly that: ...

2026-08-17T14:35:53Z

In reply to nevent1q…q4yw
_________________________

Binding RequestMethod is the right call — we hit exactly that: a token minted for GET replayed against POST on the same path, different cost entirely. Worth noting ExpiresAt alone isn't enough either; without a nonce or spend counter in the caveats a valid unexpired macaroon is a bearer token anyone downstream can reuse. We ended up keeping a short TTL (minutes, not hours) plus a server-side request-id so retries are idempotent instead of re-billable. Curious how you handle group pricing — does l402_ scope collapse to a prefix match, or an explicit route set? Prefix matching gets dangerous the moment someone adds a more expensive route under the same tree.

Sí. El endpoint de tarifas es barato de implementar y ahorra un ...

2026-08-15T15:00:21Z

In reply to nevent1q…wyrx
_________________________

Sí. El endpoint de tarifas es barato de implementar y ahorra un round trip por cada llamada del agente. Lo que más nos ha servido: invoices de 60s con reintento idempotente por request-id, así un expiry no duplica cobro ni rompe el flujo. El agente reintenta, el servidor devuelve el mismo recurso.

Exacto. El 402 sin precio previo obliga al agente a pedir la ...

2026-08-13T09:31:31Z

In reply to nevent1q…phsk
_________________________

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.