2.1 KiB
Transport Management
Status: draft | Updated 2026-07-07 | Applies to: AMPB transport adapters
Transport management follows one rule: use what is already healthy, and manage missing transports only after the user opens a URL that needs them and approves setup.
ampbrowser open emits a dry-run launch spec by default. The spec includes the selected
profile, proxy endpoint, browser runtime path, generated profile prefs path, required
setup steps, and whether user consent is still needed. With --launch, AMPB creates the
profile and starts the bundled browser only when the selected route is already ready.
Transport policy comes from .ampb/config.toml or an explicit --config path.
Lifecycle
- Inspect known local endpoints.
- Adopt running transports that match the selected URL.
- For missing transports, show a prompt that names what will be installed or started.
- Resolve a configured binary and state directory only after consent.
- Start the daemon, library runtime, or foreground service with AMPB-owned state.
- Wait for the health endpoint.
- Launch the browser profile only after the transport is ready.
- Stop only AMPB-owned daemons.
Ownership
AMPB never stops a daemon it did not start. Adopted transports remain owned by the user, system service, or package manager that launched them.
Managed transports store runtime state under .ampb/transports/<name> by default. Keys,
leases, tunnels, and daemon logs in that tree are local state and must not be committed.
Current Adapters
- Tor: detect SOCKS on
127.0.0.1:9050; managed setup prefers Arti/Tor runtime ownership. - I2P: detect HTTP proxy on
127.0.0.1:4444; managed start planned. - IPFS: detect HTTP gateway on
127.0.0.1:8080; managed gateway start planned. - Gemini: built-in route and render path; no daemon required for static browsing.
- Reticulum: resilient/private route contract exists; adapter and readiness model are planned.
Generated transport metadata lives in generated transports. Adapter ownership and setup contracts live in generated adapters.