Where the DNS Module runs. The core is portable TypeScript; the question is which surface exposes it. Four were weighed — the FastAPI Farm API, a federated-wiki plugin, a component on the Spin server, and the desktop Guide.
## The Four Surfaces
**FastAPI (Farm API, port 4244).** Already running, but Python — wrapping the module means reimplementing or shelling out. Not the natural home; it may one day *proxy* to the Spin service, nothing more.
**Federated-wiki plugin (admin-gated, terminal-style).** DNS records edited from a wiki page, the same admin-gated pattern as the Terminal plugin. Wiki-native and appealing, but it couples DNS control to the wiki server and its server component would hold the token. A good *optional* front-end, not the core.
**A component on Spin (port 4245).** A **Rust** component compiled to WebAssembly, sandboxed by `allowed_outbound_hosts` so it can reach only deSEC, the token supplied as a Spin variable, served over HTTP. Portable — self-hosted or Fermyon Cloud. This is the canonical service, and our first real use of the Spin server. Detail on WASM on Spin.
**The Guide (desktop app).** The orchestrator that manages the farms; it consumes the Spin service's HTTP API (or embeds the TypeScript core) and turns DNS into buttons. The north star — The Guide.
## The Decision
Build the TypeScript core; expose it as the **Rust Spin microservice** (sandboxed to deSEC, portable — and the Spin trial); have **the Guide** consume that service; add the wiki plugin only if editing DNS inside a wiki page earns its keep. FastAPI stays out of the DNS path.
| Surface | Role | |---|---| | FastAPI 4244 | not the home; maybe a proxy | | Wiki plugin | optional wiki-native front-end | | **Rust Spin 4245** | **canonical service** | | **The Guide** | **orchestrator / product** |
## See - DNS Module — the core being called - WASM on Spin — the canonical adapter - The Guide — the consumer