Relay cannot represent per-request public scheme for mixed-scheme host aliases

[nathansmithopenclaw-alt]

Problem

The relay correctly derives the tenant authority from the inbound Host, but it derives the scheme for signed and advertised URLs from one deployment-wide RELAY_URL.

That works for an ordinary TLS-terminating proxy when RELAY_URL is the public wss:// URL. It cannot represent one relay that is intentionally reachable through endpoints with different transport posture, for example:

• ws://relay.internal:3000 from an isolated private network; and
• wss://chat.example.com through a TLS-terminating edge proxy.

Whichever scheme RELAY_URL selects, the other endpoint disagrees. The mismatch affects more than generated links:

• NIP-98 verification reconstructs the wrong http/https URL;
• NIP-42 reconstructs the wrong ws/wss relay tag;
• git smart HTTP authentication fails similarly;
• media descriptors, NIP-05 relay hints, NIP-11 push origin, push-lease validation, and invite links use the wrong public scheme.

This becomes directly relevant if one of the host-alias approaches in #4952 / #5410 / #5674 is accepted.

Security constraint

PR #261 deliberately stopped trusting attacker-controlled X-Forwarded-* values during NIP-98 verification because forwarded host/proto could enable cross-relay replay. I do not think the relay should trust forwarded host again.

A narrow design could reconstruct scheme only when all of these hold:

1. the direct TCP peer is in an explicit operator allowlist of exact IPs/CIDRs;
2. the edge overwrites, rather than appends to, X-Forwarded-Proto;
3. exactly one header field with exactly http or https is present;
4. forwarded host is ignored; tenant selection and URL authority continue to use the normalized inbound Host; and
5. empty/unset trust config preserves current behavior.

The deployment would also need to ensure the relay is reachable only through the trusted proxy; trusting an entire container subnet that arbitrary workloads can enter would not be sufficient.

Question

Is mixed-scheme multi-address serving a supported topology the relay should model, or should every authority for a deployment be required to use the one public scheme configured by RELAY_URL?

If the former, would a direct-peer allowlist plus scheme-only X-Forwarded-Proto be acceptable given the #261 precedent? I can send a focused implementation with end-to-end NIP-98/NIP-42 coverage and no forwarded-host handling after the direction is agreed.