NIP-98 auth rejects valid RELAY_URL when it includes a non-default port (self-hosted, WSS on non-443)

[Hus10sain]

Body
Summary

When RELAY_URL is configured with a non-default port (e.g. wss://example.com:3443), the relay correctly derives and registers the deployment community using the full authority including the port (via relay_url_authority / normalize_host in crates/buzz-relay/src/main.rs). However, NIP-98 HTTP Auth verification for the /query bridge endpoint appears to validate the request URL against a different normalization of RELAY_URL that drops the port and/or forces a fixed scheme, causing every authenticated request to fail with a URL mismatch — even though the client is using the exact RELAY_URL the deployment was configured with.

This makes it impossible to self-host a Buzz relay behind a reverse proxy on any port other than the implicit default for the scheme (443 for wss/https, 80 for ws/http).

Environment
Relay: self-hosted, ghcr.io/block/buzz:main, deployed via deploy/compose/compose.yml
Reverse proxy: Nginx, terminating TLS (Let's Encrypt), forwarding WebSocket upgrade to the relay container
Desktop: v0.5.2
RELAY_URL=wss://example.com:3443 (a port other than 443, chosen because port 443 was already in use by another site sharing the same domain)
Reproduction
Deploy relay with RELAY_URL=wss://your-domain.com:3443 (any non-default port for the scheme).
Confirm the deployment community is registered with the port included:
INFO Deployment community ensured host="your-domain.com:3443" community=""
Point Buzz Desktop's community Relay URL to wss://your-domain.com:3443, matching exactly.
Desktop connects (WebSocket upgrade succeeds, 101 Switching Protocols), then attempts NIP-42 auth / NIP-98 bridge requests.
Observe:
relay returned 401 Unauthorized: NIP-98: NIP-98 HTTP Auth verification failed:
URL mismatch: event has https://your-domain.com:3443/query,
expected https://your-domain.com/query

The "expected" URL in the error has the port stripped, despite RELAY_URL (used successfully for community host derivation) including it.

Expected behavior

NIP-98 URL validation should use the same host/authority normalization as community derivation (relay_url_authority / normalize_host), so that a RELAY_URL with an explicit non-default port is honored consistently across both code paths.

Suspected cause

Two independent normalization paths for the same RELAY_URL config value:

Community/tenant resolution (crates/buzz-relay/src/tenant.rs, relay_url_authority) — preserves the port.
NIP-98 HTTP Auth verification (bridge /query endpoint) — appears to reconstruct the "expected" URL using a default scheme/port instead of the configured RELAY_URL authority verbatim.
Additional context

This was discovered while trying to run mobile pairing (/pair, NIP-AB) over a dedicated HTTPS port on a self-hosted relay that shares its domain with another web application on port 443. Related regression also observed independently: #3514 (Mobile 0.4.12 does not decode Desktop 0.5.0 styled pairing QR) — not the same bug, but encountered in the same troubleshooting session and may be worth cross-referencing if investigating mobile pairing reliability on self-hosted deployments generally.

Happy to provide relay logs, full Nginx config, or test further changes if useful for debugging.

[ScaleLeanChris]

I traced this on current main. I do not think nip98_expected_url is dropping the port.

The current flow is:

1. /query reads the inbound Host header and bind_community normalizes it.
2. normalize_host removes only the default :80 and :443 ports. It preserves non-default ports.
3. nip98_expected_url builds its URL from tenant.host().

References: normalize_host, bind_community, and nip98_expected_url.

An expected URL of https://example.com/query therefore suggests that Buzz received or resolved the request as bare example.com. The likely port loss is before Buzz. A common cause is an Nginx proxy_set_header Host $host setting, or the default proxied host. The official Nginx proxy documentation states that $http_host passes the original Host header unchanged.

Could you share the Nginx location block, especially proxy_set_header Host? As a focused test, use:

proxy_set_header Host $http_host;

It would also help to check whether the Buzz community records or logs contain both example.com and example.com:3443. If only the :3443 form exists, a bare Host should fail tenant binding. A second bare mapping or stale row could explain why the request reached NIP-98 validation.

I would not change Buzz to use the global RELAY_URL authority during authentication. The current design deliberately binds authentication to the inbound tenant host. Substituting a global configured host would weaken that tenant boundary.

If this confirms the proxy behavior, I can add a short non-default-port reverse-proxy note to the deployment documentation.