- Add URL plugin effects (register, export_url, clear_urls) in core - Add PluginHostnameInfo, HostnameMetadata::Plugin, and plugin registration types - Implement plugin URL table in web UI with tableAction button and rowAction overflow menus - Thread urlPluginMetadata (packageId, hostId, interfaceId, internalPort) as prefill to actions - Add prefill support to PackageActionData so metadata passes through form dialogs - Add i18n translations for plugin error messages - Clean up plugin URLs on package uninstall
3.9 KiB
AI Agent TODOs
Pending tasks for AI agents. Remove items when completed.
Features
-
Extract TS-exported types into a lightweight sub-crate for fast binding generation
Problem:
make ts-bindingscompiles the entirestart-oscrate (with all dependencies: tokio, axum, openssl, etc.) just to run test functions that serialize type definitions to.tsfiles. Even in debug mode, this takes minutes. The generated output is pure type info — no runtime code is needed.Goal: Generate TS bindings in seconds by isolating exported types in a small crate with minimal dependencies.
Approach: Create a
core/bindings-types/sub-crate containing (or re-exporting) all 168#[ts(export)]types. This crate depends only onserde,ts-rs,exver, and other type-only crates — not on tokio, axum, openssl, etc. Thenbuild-ts.shrunscargo test -p bindings-typesinstead ofcargo test -p start-os.Challenge: The exported types are scattered across
core/src/and reference each other and other crate types. Extracting them requires either moving the type definitions into the sub-crate (and importing them back intostart-os) or restructuring to share a common types crate. -
Use auto-generated RPC types in the frontend instead of manual duplicates
Problem: The web frontend manually defines ~755 lines of API request/response types in
web/projects/ui/src/app/services/api/api.types.tsthat can drift from the actual Rust types.Current state: The Rust backend already has
#[ts(export)]on RPC param types (e.g.AddTunnelParams,SetWifiEnabledParams,LoginParams), and they are generated intocore/bindings/. However, commit71b83245b("Chore/unexport api ts #2585", April 2024) deliberately stopped building them into the SDK and had the frontend maintain its own types.Goal: Reverse that decision — pipe the generated RPC types through the SDK into the frontend so
api.types.tscan import them instead of duplicating them. This eliminates drift between backend and frontend API contracts. -
Auto-configure port forwards via UPnP/NAT-PMP/PCP - @dr-bonez
Goal: When a binding is marked public, automatically configure port forwards on the user's router using UPnP, NAT-PMP, or PCP, instead of requiring manual router configuration. Fall back to displaying manual instructions (the port forward mapping from patch-db) when auto-configuration is unavailable or fails.
-
Decouple createTask from service running state - @dr-bonez
Problem:
createTaskcurrently depends on the service being in a running state.Goal: The
input-not-matcheshandler in StartOS should queue the task, check it once the service is ready, then clear it if it matches. This allows tasks to be created regardless of whether the service is currently running. -
Clear service error state on fresh install/update - @dr-bonez
Fresh installs and updates should clear any existing service error state.
-
Implement URL plugins - @dr-bonez
Goal: Add a plugin system that allows services to register URL scheme plugins, providing additional ways for other services to connect to them (e.g. alternative protocols or transports).
-
Fix NAT hairpinning for LAN port forwarding - @dr-bonez
Problem: When a container accesses a service via a forwarded port on the host, the return traffic doesn't route correctly due to missing NAT hairpin rules. This causes container-to-host port forward connections to fail.
Goal: Add masquerade/SNAT rules so containers can reach services through the host's forwarded ports.
-
OTA updates for start-tunnel - @dr-bonez
Goal: Add an OTA update mechanism for the start-tunnel server so it can be updated in place without redeploying. start-tunnel is built from the same codebase as StartOS but runs as a separate service.