In 1977 the ARPANET already had Telnet, but Telnet was, frankly, a scroll-of-glass protocol. It assumed a printing teletype: bytes go one way, characters come back, cursor addressing is somebody else's problem. Meanwhile, at MIT and Stanford the interesting terminals were display terminals — Datamedias, Imlacs, and the fabled Knight TVs on the ITS PDP-10s — with cursor movement, screen erase, reverse video, and a keyboard sprouting META, SUPER, and HYPER keys that Telnet had no vocabulary to describe. SUPDUP, short for SUPer-DUPer, was Mark Crispin's answer.

The core idea is a virtual display terminal. Where Telnet negotiates options like "will you echo?", SUPDUP opens the connection by exchanging a fixed initial handshake describing the physical terminal: rows, columns, and a bitmask of %TO options — does it have overprinting? A visible bell? Can it move the cursor backwards? Erase to end of line? Once the server knows what the terminal can actually do, it sends a small stream of single-byte opcodes: %TDMOV (absolute cursor move), %TDMV0 (fast move within the current line), %TDEOF (erase to end of screen), %TDBS, %TDCR, %TDNOP, and so on. The server maintains a model of what your screen looks like and sends the minimum diff to update it. Any capable terminal, whether Imlac or ADM-3A, could be driven by the same server code — a genuinely novel abstraction in 1977.

Several design choices are worth pausing on:

• Server-side line handling. Unlike Telnet, there is no local echo negotiation dance. The server always echoes, because the server owns the screen model. That eliminates a whole class of half-duplex glitches that plague Telnet to this day.
• The 9-bit character. SUPDUP was born on 36-bit PDP-10s, and the keyboard model uses a 9-bit character with explicit CONTROL, META, and TOP bits. This is where Emacs's C-M-x conventions came from — SUPDUP could actually carry the chord, whereas Telnet mashed it into ESC-prefix sequences.
• Terminal-independent codes. SUPDUP predates termcap (1978) and terminfo (1981-ish). The insight that a protocol should carry semantic screen operations and let each end translate to its hardware is essentially what curses would later formalize on the client side.
• Graphics extension. RFC 746 later bolted on a vector-graphics extension for Imlac displays — one of the earliest attempts at a network graphics protocol, predating X11 by a decade.

SUPDUP was standard on ITS, TOPS-20, and TENEX; you could SUPDUP from MIT to Stanford in the late '70s and get a properly responsive Emacs session. It lost to Telnet for prosaic reasons: Telnet was mandatory, SUPDUP was optional, Unix arrived without a SUPDUP daemon, and VT100 escape sequences became the de facto lingua franca once DEC shipped enough terminals. By the mid-'80s SUPDUP was a curiosity.

But its DNA is everywhere. Every time you resize an xterm and the shell reflows, every time ssh forwards a SIGWINCH, every time tmux maintains a screen model and sends deltas to reconnecting clients, you are using ideas SUPDUP articulated first. And Mark Crispin — a teenage MIT hacker when he wrote this — went on to design IMAP, which carries the same instinct: let the server hold the authoritative model, let the client render it. SUPDUP is the road not taken that turned out to be the road we're on anyway.