atlibs-fedproxy

Two atlibs wasm modules (knotless://johnandersen777.bsky.social/atlibs) and the pages that run them:

• fedproxy: lists and adds the SSH public keys 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-<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.<host> 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/<nsid> 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 (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.

git clone https://knotless.dev/johnandersen777.bsky.social/atlibs ../atlibs && git -C ../atlibs checkout -q 88b2ba8

Build

cargo wasm

The wasm lands in target/wasm32-unknown-unknown/release/; each page's modules/ links to it.

Run a page

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

cargo wasm && node --test modules/*/test.mjs web/*/*.test.mjs

Publish

Commit first: the source manifest names the commit it was built from.

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.