Allow T3 Connect to use attested environment-managed endpoints instead of relay-provisioned Cloudflare tunnels

[glopyglerky]

Problem

T3 Connect's managed remote-connection path currently couples account-wide environment discovery and connection authorization to a relay-provisioned Cloudflare tunnel. The contracts already distinguish endpoint provider kinds, but the current client linking flow selects cloudflare_tunnel, provisioning returns a Cloudflare connector token/runtime, and relay connection authorization requires a matching managed Cloudflare allocation.

Some self-hosted environments already provide a stable browser-trusted HTTPS/WSS endpoint through their own outbound-only connector or mesh. They should be able to participate in T3 Connect discovery, DPoP bootstrap, health, credential minting, revocation, and device handoff without asking the T3 relay to provision or own the data-path tunnel.

This is not a request to weaken endpoint authorization or accept arbitrary caller-supplied URLs.

Proposed narrowly scoped contract

Add a provider-neutral environment-managed endpoint mode alongside the existing relay-managed Cloudflare mode.

Conceptually:

relay_managed
  relay provisions endpoint runtime and returns connector configuration

environment_managed
  environment presents a stable HTTPS/WSS endpoint plus an endpoint-control attestation
  relay verifies and records it but does not provision the tunnel or receive its connector secret

The exact names can follow the repository's preferred vocabulary. A generic contract is preferable to a vendor-specific provider enum.

Link flow

1. The client obtains the normal relay link challenge.
2. The environment creates a link proof containing its descriptor, endpoint, requested T3 scopes, and an environment-managed endpoint attestation bound to the challenge, environment ID, endpoint origin, relay audience, provider/mode, generation, and expiry.
3. The relay verifies the existing environment signature plus endpoint control/attestation.
4. The relay performs bounded HTTPS health/identity verification against the exact endpoint with redirects disabled and private/loopback/link-local destinations rejected.
5. The relay stores the endpoint and environment keys. It does not allocate a Cloudflare tunnel and returns endpointRuntime: null (or an explicit environment-managed runtime variant).
6. Normal connect/status continues to use the existing environment health and credential-mint proof flow.

Client behavior

• Stop hard-coding cloudflare_tunnel as the only managed-link choice.
• Read a versioned link capability from the environment descriptor or link-state response.
• Preserve the current Cloudflare flow unchanged when the environment requests relay-managed provisioning.
• Allow old clients and old environments to fail safely under version skew.
• Keep direct host/pairing-code onboarding independent from T3 Connect.

Security requirements

An environment-managed endpoint must not be authorized from a URL alone. The relay should require all of the following:

• https and wss only, with matching canonical host/port;
• no URL credentials, query-carried secrets, fragments, redirects, or DNS rebinding to private/loopback/link-local space;
• challenge-, environment-, relay-audience-, endpoint-, provider/mode-, generation-, and expiry-bound proof;
• exact environment descriptor ID match;
• independent endpoint-control verification or a reviewed provider attestation chain;
• signed health and credential-mint responses using the linked environment keys;
• DPoP/holder binding for client credentials;
• endpoint replacement and key rotation as explicit generation changes;
• immediate unlink/revocation behavior;
• no provider connector token or private tunnel key stored by the T3 relay;
• unchanged authorization and allocation checks for the existing Cloudflare provider.

Concrete integration motivating this

Omnidia is building a memory-safe Rust, outbound-only mesh connector. Stock T3 clients would use normal HTTPS/WSS to an Omnidia public edge; the Omnidia-controlled edge-to-instance leg is carried over a mutually authenticated post-quantum-secure mesh. T3 would remain the discovery/authentication/credential control plane, not the tunnel provider or data relay.

The client-facing path remains ordinary TLS/WSS; this proposal does not claim end-to-end PQC and does not require T3 clients to implement Omnidia transport code.

Suggested implementation slices

1. Contract and schema addition with version-skew tests.
2. Provider-neutral relay authorization branch while retaining existing Cloudflare behavior.
3. Environment-managed link proof and endpoint-control verification.
4. Mobile/web linking selection based on environment capability.
5. Tests for forged endpoint, SSRF, redirect, DNS rebinding, stale generation, replay, key rotation, unlink, and old-client compatibility.

I am opening the issue before proposing code per CONTRIBUTING.md. I can prepare a small focused PR after maintainers choose the preferred contract shape.

[SonyStone]

Adding a user perspective in support of separating T3 Connect discovery/authentication from managed Cloudflare tunnel allocation.

I use three environments: a MacBook, a Windows PC, and a Docker container. I encountered provisioning failures, then a maximum-of-3-managed-tunnels error, and even Deregister failed. Details are in #14070. Connect now enables successfully on my PC with 0.0.44, so this is a feature request motivated by that experience, not a claim that the outage is ongoing.

The environment-managed HTTPS/WSS option proposed here would already help. As a separate, longer-term extension, would an optional direct connection mode be in scope?

• Keep T3 Connect account discovery and connection authorization.
• Attempt a direct connection using WebRTC DataChannels and ICE/STUN.
• Fall back to TURN or the existing managed HTTPS/WSS tunnel when direct connectivity is unavailable; allow self-hosted relay configuration where practical.
• Show whether a connection is direct or relayed.
• Consider separating the registered-environment limit from the managed-tunnel quota, so environments using their own connectivity do not require a Cloudflare allocation. P2P alone would not remove quota policy or relay costs.

I understand this goes beyond the original HTTPS/WSS proposal: the current HTTP/WebSocket transport would need adaptation, and authentication, revocation, reconnection, and desktop/web/mobile compatibility would need careful design. Direct connectivity is not guaranteed on every network.

I also saw the closing comment on #8852, which says P2P remote access is not planned. That implementation used Holepunch/HyperDHT and included unrelated changes.

Could maintainers clarify whether P2P transport is out of scope regardless of implementation, and whether the narrower environment-managed HTTPS/WSS option in this discussion is still something you would consider? That would help users decide between waiting for upstream support and maintaining a separate solution.