Browser and Telnet#
Both transports create the same Nodehouse session. Choose based on client compatibility and transport security.
Browser terminal#
The browser loads the terminal over HTTP and connects to the board through a WebSocket on the same site. In production, place the HTTP service behind an HTTPS reverse proxy and preserve WebSocket upgrade headers.
Verify#
Open the site, sign in, leave the session idle long enough to exercise a keepalive, then enter a menu command. The connection should remain responsive until the configured board idle timeout is reached.
Telnet#
Telnet connects directly to the separate TCP listener and provides the closest traditional BBS experience. It is not carried through the HTTP reverse proxy.
test -n "$NODEHOUSE_TELNET_HOST" && test -n "$NODEHOUSE_TELNET_PORT"
telnet "$NODEHOUSE_TELNET_HOST" "$NODEHOUSE_TELNET_PORT"Verify#
The welcome art should render, backspace should behave correctly and menu input should not display Telnet negotiation bytes. If rendering is corrupted, try a client with ANSI colour and Telnet negotiation support.
Security difference#
HTTPS protects browser traffic in transit. Raw Telnet does not encrypt the username, password or session. Operators should state this clearly, and callers should use a unique board password.
If it does not work#
| Symptom | Check | Recovery |
|---|---|---|
| The browser terminal will not connect | The WebSocket origin | See The browser loads but the terminal does not connect |
| Telnet connects but the display is broken | Terminal emulation and character width | See Telnet does not connect or renders badly |
| You are unsure which transport to use | The security difference above | Telnet carries credentials in the clear; prefer the browser terminal over any untrusted network |