Skip to content

Document hosting without a domain (GRYT-273) - #25

Merged
sivert-io merged 1 commit into
mainfrom
claude/GRYT-273-document-hosting-without-a-domain
Aug 14, 2026
Merged

Document hosting without a domain (GRYT-273)#25
sivert-io merged 1 commit into
mainfrom
claude/GRYT-273-document-hosting-without-a-domain

Conversation

@sivert-io

Copy link
Copy Markdown
Member

The docs pushed everyone toward a tunnel and a certificate. For people joining on the desktop app, none of that is needed: forward three ports, hand out 203.0.113.10:5000, done. That path worked all along and was never written down.

New page: No domain, just an IP

Three ports, two environment variables, the address. Written as a tutorial rather than a reference.

Two things it makes a point of:

UDP is the one people forget. Voice doesn't travel over the chat connection and it isn't TCP. Forward 5000 and 5005 and everything looks fine until somebody joins voice and nobody can hear them.

ICE_ADVERTISE_IP decides whether voice works at all. A server behind a router advertises a private address nobody outside can reach, so chat works and voice fails, which is a confusing way to learn about it.

It also explains why a browser can't do this, because the obvious workaround (self-signed cert for something like dev.lan) can't work either and someone will try it before asking. No CA issues for made-up TLDs, so every device would have to install your root CA by hand.

Fixed a wrong instruction

quick-start said:

Connect using the Gryt desktop app or app.gryt.chat. Enter your server address (e.g. gryt.example.com or your public IP).

Those aren't interchangeable. A bare IP works in the desktop app and is blocked outright in a browser, because that's an HTTPS page opening a plain connection. Anybody following that line in a browser got a connection that silently never established. Split into the two cases.

Also

  • embedded.mdx said a tunnel is needed from outside your network. True for browser users only; now says so and links across.
  • Added a card to the deployment index and slotted the page into the nav after embedded.

On the writing

Ran it through the humanizer skill as asked. One judgement call: my first draft had zero em dashes, while embedded.mdx has 11 and docker-compose.mdx has 15. The skill is explicit that matching the author's sample outranks scrubbing that particular tell, so I put four back where a comma was doing too much work. A page conspicuously without them would read as written by someone else.

Verified

yarn build clean, 91 pages, no-domain.html renders.

Port numbers taken from the table in docker-compose.mdx (SERVER_PORT 5000, SFU_PORT 5005, ICE_UDP_MUX_PORT 443) rather than from memory.

🤖 Generated with Claude Code

The docs pushed everyone toward a tunnel and a certificate, which is only
true for people joining from a browser. On the desktop app a bare IP and
port works: forward three ports, hand out the address, done.

New deployment page saying exactly that, with the two environment
variables that decide whether voice works and the reason UDP is the one
people forget. Linked from the deployment index and from the embedded
server page, whose line about needing a tunnel from outside the network
was true only for browser users.

Also fixed quick-start, which told people to connect with the desktop app
or app.gryt.chat and enter "gryt.example.com or your public IP" as if
those were interchangeable. They are not. A browser will not open a plain
connection from an HTTPS page, so a bare IP fails there and works fine in
the desktop app. Anybody who followed that line in a browser got a
connection that silently never established.

The page explains why rather than only stating it, because the obvious
workaround — a self-signed certificate for something like dev.lan — cannot
work either, and somebody will try it before asking.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@sivert-io
sivert-io merged commit 157f819 into main Aug 14, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant