Web UI: dark/light themes (appliance layout, sidebar, switch checkboxes), theme preference on the Advanced page, Changes page with the pending diff. Interface names: router.interfaces.<name>.mac, lans.<l>.deviceName and pppoe.vlanName; a rename is staged for the next reboot by router-apply. Remote access: an MCP server (POST /mcp) and an OpenAPI REST API (/api/v1, /api/openapi.json) with the same tokens, scopes, limits and audit log; tools to read status, settings, leases, logs (get_logs), and to edit and check the saved settings (never applied). Tokens on the API access page. Firewall: a reserved `local` zone (the router itself) as the destination of rules, so the web UI or SSH can be allowed from the WAN. PLAN.md lists what is still left. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AeFqV9dZrK6nipHkPfyM4F
1.0 KiB
1.0 KiB
Specs
What nixos-router should become, beyond what exists. PLAN.md records decisions and what is done; this file
lists wanted features. The MCP server (read and change scopes) exists; the rest is not started.
Later
Programmatic access
- REST API: done with the MCP's feature set (OpenAPI at
/api/openapi.json, seePLAN.md). Still to do: the rest of what the web UI does (apply/confirm, metrics, updates), versioned; the web UI would use the same handlers. - GraphQL on top of it, possibly: one query for the overview and for related settings.
- MCP server: done for reading and editing settings (see
PLAN.md, "MCP server"). Still to do: anapplyscope (build, activate, confirm; a token with it can change the running system), more read tools (metrics history;get_logsexists), per-token expiry, and a notice in the web UI when a token edited the settings. - Rule for all of it: changes go through
settings.jsonandrouter-apply(commit-confirm), never straight to the live system; tokens have scopes; every call is logged.