Community routing is bound to a single host — is serving one community over both an internal and a public address supported?

[obbax]

Environment

• Self-hosted relay via deploy/compose, using compose.caddy.yml with Caddy terminating TLS
• Relay image ghcr.io/block/buzz:sha-318fbf8
• Docker Compose v5.1.0

What I was doing

Migrating a relay that was originally deployed on a private network address (Tailscale-only) so it is also reachable over public TLS, while keeping the private path working for agents that already use it.

What happens

Any request arriving with the public Host header is rejected before any auth logic runs:

HTTP 404
relay: no community is configured for this host

The same relay, same port, same process — only the Host header differs:

Host: 10.0.0.1:3001        -> 200 {"name":"Buzz Relay", ...}
Host: public.example.com   -> 404 relay: no community is configured for this host

The communities table has a single row whose host column holds the address the relay was first started with.

Question

Is one community reachable over two addresses (an internal one and a public one) a supported configuration?

Specifically:

• Is adding a second communities row for the public host the intended approach — or does that create a genuinely separate community with its own channels and membership?
• Is a single canonical hostname the intended design, so that migrating means updating the existing row and re-pointing all clients?

If the latter, it might be worth calling out in the deployment docs: a relay first brought up on an internal address effectively pins that address as its identity, and moving to a public hostname later is not just a DNS/proxy change.

Rewriting Host at the reverse proxy does resolve this particular 404, but it then runs into a second, separate problem with NIP-98 auth — filed separately.

The relay behaves correctly and fail-closed throughout. This is purely about multi-address support.

[Ibrahim-OC]

A concrete failure mode of this host binding is that it blocks adding mobile access to an existing loopback-based community.

Mobile-access failure mode

I had an established self-hosted community on:

ws://127.0.0.1:3000

with existing desktop and agent clients, channels, memberships, and history. I added Tailscale Serve as a private TLS/WebSocket endpoint:

https://<tailscale-host>.ts.net:8443
    -> http://127.0.0.1:3000

TLS termination and WebSocket forwarding worked. However, configuring the relay URL as:

wss://<tailscale-host>.ts.net:8443

caused that hostname to select a newly created, empty community rather than the existing loopback community. Authentication through the external endpoint succeeded, but the existing member saw none of the original channels.

The relay log made the new community selection explicit:

{
  "level": "INFO",
  "message": "Deployment community ensured",
  "host": "<tailscale-host>.ts.net:8443",
  "community": "<new-empty-community-id>"
}

The same deployment on its original URL selected a different community:

{
  "level": "INFO",
  "message": "Deployment community ensured",
  "host": "127.0.0.1:3000",
  "community": "<existing-community-id>"
}

There was a second continuity problem: after changing the canonical relay URL to the Tailscale origin, clients still using the original loopback URL repeatedly failed NIP-42 validation:

{
  "level": "WARN",
  "message": "NIP-42 auth failed",
  "error": "relay url mismatch"
}

After rolling back the relay URL to ws://127.0.0.1:3000, the original community was selected again and those clients resumed authenticating successfully.

Mobile pairing was stopped at that point: the externally reachable endpoint was healthy, but it represented an empty community, while preserving the external canonical URL broke the installed loopback clients.

Connection IDs, event IDs, public keys, channel IDs, community UUIDs, the device name, and the real Tailscale hostname are redacted above.

Reproduction

1. Start a self-hosted relay on 127.0.0.1:3000.
2. Create a community with channels and members.
3. Connect desktop or agent clients using ws://127.0.0.1:3000.
4. Add Tailscale Serve:

   https://<tailscale-host>.ts.net:8443
       -> http://127.0.0.1:3000
   

5. Configure the relay’s advertised URL as:

   wss://<tailscale-host>.ts.net:8443
   

6. Restart the relay.
7. Authenticate through the Tailscale hostname and inspect the member’s channels.
8. Observe authentication attempts from clients still using the loopback URL.

Suggested fix

Either of these would enable a safe mobile migration:

1. Stable deployment-community identity: use an explicit persistent community/deployment ID that is independent of the hostname. Hostnames would be routing and authentication configuration rather than tenant identity.

2. Hostname aliases: allow multiple explicitly approved origins to resolve to the same existing community, with NIP-42 accepting the actual origin used by the client when it is an approved alias.

For example:

community_id = <stable-id>

accepted_origins:
  - ws://127.0.0.1:3000
  - wss://<tailscale-host>.ts.net:8443

This could remain single-host and fail-closed by default. Additional aliases would require explicit operator configuration.

The important requirement is that adding a mobile-accessible hostname must not create a new tenant or require an all-at-once migration of every existing client.

[nathansmithopenclaw-alt]

There are now three implementations/proposals around one community being reachable through more than one exact host:

• relay: support host aliases so in-cluster clients can bind to a community #2527: durable DB-backed aliases, operator CLI, collision serialization; closed unmerged after its code review was resolved while final fork CI was still awaiting approval.
• feat(relay): support serving a community on host aliases via BUZZ_HOST_ALIASES #5410: deployment-configured BUZZ_HOST_ALIASES, preserving the arrival host for NIP-98/NIP-42.
• feat(pairing): support mobile pairing through a distinct public hostname #5674: a DB-backed alias table bundled with pairing URL and compose-sidecar changes.

Would maintainers prefer durable operator-managed routing state, deployment config, or no alias support?

My bias is a focused DB-backed alias change separate from pairing. Exact host ownership is tenant-routing state: aliases should participate in the same global collision boundary as community creation, survive pod/env changes, reject alias/community creation races deterministically, and remain listable/removable through an operator command. Whatever storage shape wins, TenantContext should retain the normalized arrival host, not replace it with the community's primary host. NIP-98, NIP-42, media URLs, NIP-05 relay hints, NIP-11 push origin, invite links, and git auth all need the endpoint the client actually used.

There is one identity wrinkle the selected design should resolve explicitly: profile materialization currently validates a kind-0 nip05 domain against TenantContext.host(), while the NIP-05 endpoint queries by the request host. If the arrival alias remains in the tenant context, a canonical-domain handle ingested through an alias can disappear from the materialized profile. We should decide whether only the primary host is the NIP-05 identity domain or aliases are identity domains too, and test both publish and lookup paths so profile state cannot oscillate by ingress host.

I do not plan to open another competing PR. I can help rebase, test, or extract the host-alias portion into the shape maintainers choose.