# atlibs-fedproxy Two [atlibs](https://knotless.dev/johnandersen777.bsky.social/atlibs) wasm modules (knotless://johnandersen777.bsky.social/atlibs) and the pages that run them: - `fedproxy`: lists and adds the SSH public keys [fedproxy.com](https://fedproxy.com) reads from your PDS to expose your services, as the signed-in user, held to `records/fedproxy.json`'s scope. - `ingress`: serves HTTP and XRPC from a module at `https://did-key-.xrpc.fedproxy.com`, through the fedproxy did:key ingress relay. - `forward: true`: every request is one `com.fedfork.exec.ingress.request` call to the host with `{method, path, params, headers, body, callerDid}`; its output `{status, body, contentType, headers}` is the response. `headers` maps a name to a string, or to a list of strings for a repeated header (Set-Cookie); other entries are dropped. The relay drops the headers it owns (Connection and the other hop-by-hop ones, Content-Length, Strict-Transport-Security, Alt-Svc, Proxy-*), a Set-Cookie with a Domain, CR/LF/NUL, and past 64 values or 32 KiB; `contentType` wins over a Content-Type header. The relay itself answers CORS preflights and sets `Access-Control-Allow-Origin: *` unless `headers` sets it; send `Access-Control-Expose-Headers` for a header a browser must read. - `aliases`: custom host names (a list, or space/comma separated). After every registration the module sends `com.fedproxy.temp.xrpc.alias {hosts}`; the relay serves each host whose `_xrpc.` TXT holds this did:key (or its did-key host) and answers `alias#result {accepted, rejected}`, which is the run result's `aliases`. The TXT alone already routes the host while the module is connected; the frame reports whether the relay sees it. While any host is rejected the module sends the frame again every 60 s (the relay caches TXT answers, negative ones too, for 60 s), so a TXT record added after the connection is reported accepted without a reconnect. - `routes`: NSIDs whose `/xrpc/` requests become calls to that NSID, each served by a composition edge. A composition's instance `input` may fix `routes`, `deadlineMs`, `maxRequests`, `lifetimeMs`, `forward`, `aliases` and `relay` (module.json `config`), as atlibs-agents' `serve.json` does. ## Layout - `modules/fedproxy`, `modules/ingress`: the modules (Rust, against atlibs' `abi` SDK) - `web/fedproxy-ssh-public-keys`: a page for the keys; `web/fedproxy-webtiles`: the same as a [web tile](https://dasl.ing/tiles.html) (`tile/`); `web/ingress`: a page that serves through ingress - `records/`: the session record, published module snapshots (`records/wasm/`) and the tile (`records/tiles/`) ## Set up atlibs is a sibling checkout: Cargo fetches the `abi` crate from git, and the tests and pages import its JavaScript from `../atlibs`. ```bash git clone https://knotless.dev/johnandersen777.bsky.social/atlibs ../atlibs && git -C ../atlibs checkout -q 88b2ba8 ``` ## Build ```bash cargo wasm ``` The wasm lands in `target/wasm32-unknown-unknown/release/`; each page's `modules/` links to it. ## Run a page ```bash python3 -m http.server 8000 --bind 127.0.0.1 --directory web/fedproxy-ssh-public-keys ``` Open http://127.0.0.1:8000/?module=local to run your own build (without `?module=local` the page runs the published module record). ## Test ```bash cargo wasm && node --test modules/*/test.mjs web/*/*.test.mjs ``` ## Publish Commit first: the source manifest names the commit it was built from. ```bash atlibs login you.bsky.social atlibs publish --dir modules --dry-run --as you.bsky.social atlibs publish --dir modules --as you.bsky.social atlibs publish tile web/fedproxy-webtiles/tile fedproxy-webtiles --out records/tiles --as you.bsky.social ``` > **Today's atlibs builds only its own layout.** `atlibs publish` rebuilds in a container from > `Cargo.toml`, `Cargo.lock`, `.cargo`, `rust/src` and `examples/rust`, with `bash rust/src/build.sh`, so > it does not yet see `modules/`. Until it does, `--no-build` publishes your `cargo wasm` build, which > `atlibs verify` (that container rebuild) will not reproduce.