ostp/ostp-client
ospab a03e2c9855 fix(relay): stop rejecting every generated relay config at load
The relay is a transparent pipe now — it authenticates nothing and forwards to a
fixed next hop. Both the setup wizard and the `init` template write a relay
config with only listen + upstream_tcp + upstream_udp, and the relay runtime
uses exactly those. But UnifiedConfig::validate still demanded a non-empty
upstream_api_url — a field left from the old design where the relay
authenticated clients itself and pulled the key list from the target's API.

So the tool generated a config it then refused to load: every relay came up with
"Relay configuration must specify upstream_api_url." That is why relay "was
never finished" — it could not start from any config the tool itself produced.

Validation now matches the transparent relay: require both upstream addresses
(the runtime needs both carriers), and do not require the dead api_url. Leftover
api_url in an old config is still tolerated, just ignored.

Adds regression tests that load a config exactly as the daemon does
(deserialize into the one canonical UnifiedConfig, then validate) for all three
modes. This is the drift-catcher: whenever the wizard/template and the validator
disagree on required fields again, a test fails instead of a user's node
refusing to start.
2026-08-17 16:04:38 +03:00
..
src fix(relay): stop rejecting every generated relay config at load 2026-08-17 16:04:38 +03:00
Cargo.toml §A: remove WSS + Reality (TLS-mimicry); bump to 0.4.0 / AGPL-3.0 2026-06-27 16:29:42 +03:00
test_udp.rs fix: remove DNS interception on server, fix TUN routing on Windows and Linux 2026-05-28 12:30:06 +03:00