vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Activity

docs(matrix): fix the bug-as-behaviour and must wording mara flagged

Browse source 
matrix.md no longer documents the .well-known/discovery domain
mismatch as a fact to work around (that's #4878's fix to make);
same fix applied to gateway.md's Discovery flow section, which
stated the identical bug and told the operator how to route
around it.

The serverName-pinning note no longer says the module requires
pinning it (nothing enforces that) — it states the consequence of
not pinning it instead.

Refs #3902
This commit is contained in:
atlas 2026-10-02 17:25:22 +02:00
commit e27c305995
2 changed files with 3 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

10
docs/integrations/matrix.md
View file

@ -40,10 +40,7 @@ Two distinct hostnames:
*irrevocably* in every `@user:<server_name>` and `!room:<server_name>`
identifier minted on this homeserver. You can't change it later
without abandoning every account and chat history. Defaults to the
bare `services.hyperhive.swarm.domain`. The gateway serves the
`.well-known/matrix/{client,server}` discovery routes on the matrix
host's **hive** domain, not the swarm domain
([Discovery flow](../networking/gateway.md#discovery-flow-matrix)).
bare `services.hyperhive.swarm.domain`.
- **`gatewayHost`** — the API listener hostname, where the gateway's
matrix vhost proxies `/_matrix/*` to tuwunel. Defaults to
`chat.<services.hyperhive.swarm.domain>`. Set to `null` to skip the
@ -65,9 +62,8 @@ longer answers.
<details><summary>Pinning <code>serverName</code> on a homeserver with existing ids</summary>
`serverName` defaults to the bare `services.hyperhive.swarm.domain`. A
homeserver must set `serverName` to the value that minted its existing
ids — see above for why a different value strands existing users and
rooms:
homeserver that changes `serverName` after minting ids strands its
existing users and rooms — keep the value it minted them under:
```nix
services.hyperhive.swarm.matrix = {

2
docs/networking/gateway.md
View file

@ -234,8 +234,6 @@ matrix-dart-sdk (FluffyChat and others) always fetches the well-known over `http
Federation peers fetch `.well-known/matrix/server` → `{"m.server":"chat.<swarm>:<httpsPort>"}`. The port is always explicit, even 443: a delegated host without a port means the federation default 8448, not 443. Peers then reach `/_matrix/` on the chat vhost through the gateway, so the gateway must be reachable from them (`gateway.openFirewall`).
⚠️ The gateway serves both `.well-known` routes on the **hive** vhost only. Matrix looks them up at the `serverName`, which defaults to the bare swarm domain, so a lookup against the swarm domain reaches the swarm UI's apex vhost and finds nothing — pin `serverName` to the hive domain, or serve `.well-known` at the swarm domain yourself.
## Sub-domain shape (rationale)
Sub-domain for forge and matrix, sub-path for per-agent UIs: