Package
@flashylabs/bastion
Bastion — a commercial gateway that puts a secure, authenticated, discoverable, payable machine interface in front of an existing website or API: /.well-known/agent derived from config, callers authenticated by delegation/1 chains, calls gated by pay-policy/1, a receipt per action. The revenue layer over the open Gateway specs, not a protocol.
version 0.0.0 · measured 2026-10-19 from a checkout · source: bastion
github.com/FlashyLabs/bastion — private-intended; not on npmA product, not a protocol, which inverts the usual rule: the discovery document is an output, the config is the input, and agent/1, delegation/1 and pay-policy/1 are upstream — referenced by name and never forked. The pure handler and the network edge are separate files, so every request flow is walked in a test with plain objects.
Status is v0 skeleton, in design: stage 1 (serve the derived document) is built; stages 2–4 (authenticate, evaluate, proxy) are designed only; stage 5 (the receipt) is a stub. Every response that reaches a designed-only stage says so — verified:false, evaluated:false, outcome:not_implemented — and a label does not turn green without the code and a test behind it.
Edge cases — each one paid for once
The proxy stage refuses to pretend
proxyToOrigin throws NotImplemented and the handler renders it as a 501 that names the endpoint it would have called; a 200 from a gateway that did not forward the call is a fabricated receipt. When the proxy is built it goes behind that seam and the 501 test is replaced by one driving a fake origin, never removed first.
The receipt signature is a digest and says so
The stub signs with an unkeyed sha256 labelled sha256-digest-unsigned: it proves the bytes have not changed since rendering and nothing about who rendered them. A keyed signature with a published verification key is stage 5’s design; until it lands the alg is not renamed.