Guest links on a host's own public address, without T3 Connect

[Thoroslives]

What I'd like

A server setting that gives guest links a public hostname the host already has. With it set, a guest link would work on a machine that is not linked to T3 Connect.

Why

I run the T3 server on my own machine and reach it through my own reverse proxy and VPN. I don't link it to T3 Connect, because I'd rather keep any tunnel or cloud account out of the path to that machine. Guest links are the one feature I miss.

A family member who isn't technical often asks me questions that I pass to the agent and then relay back. A guest link would let them ask in the thread themselves, with me sending or dismissing each message. That is exactly how the beta already works.

What ties guest links to Connect today

As far as I can read the code, the server serves the guest page and its /api/guest routes itself. apps/server/src/guest/GuestShareService.ts uses Connect only for the link's hostname:

• create refuses with connect_unavailable when the tunnel has no hostname.
• authorize and the guest stream end a share whose host no longer matches the tunnel's hostname.

canShareWithGuestAtom in the web client checks the managed connect policy, but not whether the machine is linked.

The smallest change I can see

An optional server setting that holds a hostname. When it is set, connectHostname returns it instead of the tunnel's hostname. The link becomes https://<that host>/guest#..., and the host checks compare against it. When it is unset, nothing changes.

The operator's own proxy would expose only /guest, /api/guest and the page's assets on that hostname, and the guest links guide would say so.

Questions

1. Is this a direction you would accept?
2. Would you rather have it as a server setting, a CLI flag beside --host, or something else?
3. Does anything besides the hostname assume the Connect address, such as the cookie or origin checks?

If the scope suits you, I can open a focused PR with tests in your pattern.