why telnet first
================

from the dreambook: "we honor telnet. the protocol is the interface."

telnet is the native interface. a person with a terminal emulator gets the full
experience. no browser, no client download. `telnet mud.example.com 6789` and
you're in.

telnetlib3 gives us:
- NAWS (terminal dimensions — adapt viewport to window size)
- TTYPE/MTTS (client capability detection)
- GMCP/MSDP (structured data for rich clients like Mudlet)
- SGA (suppress go-ahead for modern line handling)
- async server with reader/writer streams

the MUD ecosystem has decades of protocol extensions built on telnet. we get
all of them for free by staying in the protocol.

a web client, when it comes, should just be a terminal emulator (xterm.js)
pointing at the telnet port. same protocol, different transport.

design consequences
-------------------

- all output is text + ANSI escape codes. no binary formats.
- line endings are \r\n (telnet NVT standard)
- input is line-based (readline). no raw keystroke handling (yet)
- server-side echo is complicated — MUD clients handle their own echo
  (see docs/lessons/charset-vs-mtts.txt for the will_echo story)
- NAWS tells us the terminal size. viewport adapts. small terminal = smaller
  map view. this is a feature, not a limitation.