An out-of-band channel for game data and client capabilities that directly preceded GMCP.
- First seen
- 2008
- In use today?
- Yes
- Legacy?
- Yes
- Transport
- Telnet option 200
Current use and key considerations
Still encountered in Iron Realms-derived games and compatible clients, but new systems should use GMCP.
- Do not create new ATCP namespaces.
- Client identity and capability claims are not credentials.
Read the local ATCP reference →
A bidirectional package and JSON channel for vitals, rooms, characters, chat, UI, media, and other structured game data.
- First seen
- 2010
- In use today?
- Yes
- Legacy?
- No
- Transport
- Telnet option 201 with UTF-8 JSON
Current use and key considerations
The principal modern structured-data protocol across major MUD clients and several current engines.
- GMCP defines framing, not one universal package schema.
- Reject malformed JSON at the protocol boundary.
- Use an RFC 1143-style Telnet option state machine to prevent loops.
Read the local GMCP reference →
A bidirectional structured-data protocol supporting variables, reports, lists, arrays, and tables.
- First seen
- 2009
- In use today?
- Yes
- Legacy?
- No
- Transport
- Telnet option 69 with marker-delimited values
Current use and key considerations
Supported by several current clients and engines, especially in Diku-derived ecosystems, though its recommended vocabulary is not universal.
- It is not line-oriented text.
- Wire compatibility does not guarantee agreement on variable names.
- Malformed nesting must not corrupt the connection parser.
Read the local MSDP reference →
Publishes machine-readable server metadata such as name, player count, uptime, codebase, URLs, and supported capabilities.
- First seen
- 2009
- In use today?
- Yes
- Legacy?
- No
- Transport
- Telnet option 70 with VAR/VAL records
Current use and key considerations
Actively used by crawlers and directories, including MUDVerse, and supported by current engines and clients.
- Do not cache dynamic fields indefinitely.
- MSSP values are public metadata, not an authentication channel.
Read the local MSSP reference →
The original server-to-client compression protocol, later replaced by MCCP2.
- First seen
- 1998
- In use today?
- Not commonly
- Legacy?
- Yes
- Transport
- Early Telnet compression convention using zlib
Current use and key considerations
Retained only for specific old clients and historical implementations.
- Do not treat compression as encryption.
- Do not assume MCCP generations share one wire format.
Read the local MCCP1 reference →
Compresses the complete server-to-client byte stream after a negotiated start marker.
- First seen
- 2000
- In use today?
- Yes
- Legacy?
- No
- Transport
- Telnet option 86 followed by a zlib stream
Current use and key considerations
The mature and broadly implemented compression option for traditional MUD connections.
- The marker itself is not compressed.
- Later Telnet commands are inside the compressed stream.
- Compression provides no confidentiality.
Read the local MCCP2 reference →
Adds client-to-server compression as the reverse-direction complement to MCCP2.
- First seen
- 2019
- In use today?
- Yes
- Legacy?
- No
- Transport
- Telnet option 87 with client-to-server zlib
Current use and key considerations
Implemented by TinTin++ and some reference handlers, but adoption and practical bandwidth benefit are limited.
- Client command traffic is normally small.
- Compression is not security and does not protect passwords.
Read the local MCCP3 reference →
A draft for independently negotiated bidirectional compression using zstd, deflate, or no compression.
- First seen
- 2025
- In use today?
- Not commonly
- Legacy?
- No
- Transport
- Draft Telnet option 88 with negotiated codecs
Current use and key considerations
An experimental 2025 draft whose stated draft lifetime ended in March 2026; it is not a production baseline.
- The specification remains a work in progress.
- Compression is not a security mechanism.
- Deployment interoperability is not established.
Read the local MCCPX reference →
A MudForge-advertised experimental compression feature described as zstd-based, separate from MCCPX.
- First seen
- 2025
- In use today?
- Not commonly
- Legacy?
- No
- Transport
- No public interoperable wire specification located
Current use and key considerations
No public option number, framing specification, or independent interoperable implementation was verified.
- MCCP4 is not another name for MCCPX.
- Treat the current name as an implementation claim, not a standard.
Read the local MCCP4 reference →
Adds links, menus, formatting, entities, gauges, frames, images, and other interactive presentation features to text output.
- First seen
- 1998; v1.0 in 2003
- In use today?
- Yes
- Legacy?
- Yes
- Transport
- Telnet option 91 plus streaming markup
Current use and key considerations
Clickable SEND links remain useful and supported, while full implementations vary substantially between clients.
- Never pass untrusted player text into secure MXP.
- Do not assume negotiation means every MXP tag is supported.
- The full historical feature surface is complex and inconsistently implemented.
Read the local MXP reference →
A lightweight convention for clickable links and actions without its own Telnet option.
- First seen
- Date not established
- In use today?
- Yes
- Legacy?
- No
- Transport
- ANSI underline and OSC 68 conventions; advertised by MTTS
Current use and key considerations
Native adoption is narrow, with TinTin++ the clearest documented implementation.
- Do not use MSLP as the only hyperlink mechanism.
- OSC 68 forms are not equivalent to universally supported OSC 8 links.
Read the local MSLP reference →
Lets a server request sound or music playback, historically with optional web downloads.
- First seen
- Documented by 2001
- In use today?
- Yes
- Legacy?
- Yes
- Transport
- Telnet option 90 plus line-oriented SOUND and MUSIC triggers
Current use and key considerations
Still supported for compatibility, but MCMP is a cleaner choice for new media features.
- Reject absolute and traversal paths.
- Treat filenames and URLs as untrusted active content.
- Users must retain control over playback and downloads.
Read the local MSP reference →
A modern media package for sound, music, and video transported through GMCP.
- First seen
- Publicly documented by 2019
- In use today?
- Yes
- Legacy?
- No
- Transport
- GMCP Client.Media JSON package
Current use and key considerations
Most clearly implemented by Mudlet; any GMCP-capable engine can add it without another Telnet parser.
- Remote media remains an active-content boundary.
- Do not override client media preferences.
Read the local MCMP reference →
Uses repeated terminal-type replies to report client identity and a bitmask for UTF-8, colors, screen readers, proxies, MNES, MSLP, TLS, and other capabilities.
- First seen
- Date not established
- In use today?
- Yes
- Legacy?
- No
- Transport
- Convention layered on Telnet TTYPE option 24
Current use and key considerations
A lightweight and useful capability mechanism supported by several modern clients.
- Non-MTTS clients may return a different number of values.
- Reported capabilities are hints, not trusted identity.
Read the local MTTS reference →
Standardizes MUD-oriented client, version, charset, and capability variables over NEW-ENVIRON.
- First seen
- Date not established
- In use today?
- Yes
- Legacy?
- No
- Transport
- Telnet NEW-ENVIRON option 39
Current use and key considerations
Supported by TinTin++ and optionally by Mudlet, but less universal than TTYPE and MTTS.
- Never use environment values for authorization.
- Use MNES alongside, not instead of, TTYPE and MTTS.
Read the local MNES reference →
A package-negotiation framework associated mainly with MOO and MUCK clients, including editor and application packages.
- First seen
- 1990s
- In use today?
- Yes
- Legacy?
- Yes
- Transport
- In-band 7-bit ASCII lines beginning with #$#
Current use and key considerations
Still relevant inside its MOO/MUCK niche, but not a general replacement for GMCP.
- The session key prevents accidental framing collisions; it is not cryptographic authentication.
- Outside the MU* ecosystem, current support is limited.
Read the local MCP reference →
A generic bidirectional named-command protocol with package conventions for identity, capabilities, ping, time, and application messages.
- First seen
- Circa 2003
- In use today?
- Not commonly
- Legacy?
- Yes
- Transport
- Telnet option 93 with NUL-delimited command arguments
Current use and key considerations
Preserved and still available in a few implementations, but largely superseded by GMCP and MSDP.
- Implementations must cope with large subnegotiations.
- Do not design a new general protocol namespace around ZMP.
Read the local ZMP reference →
Publishes areas, rooms, coordinates, exits, and environments for client-side map creation.
- First seen
- Circa 2010
- In use today?
- Yes
- Legacy?
- No
- Transport
- XML map export over HTTP or files
Current use and key considerations
Used in the IRE and Mudlet mapping ecosystem; it is an export format rather than a session protocol.
- Bulk maps can reveal unexplored world data.
- Decide explicitly which rooms and metadata are public.
Read the local MMP reference →
A client-to-client chat and file-transfer protocol, not a normal MUD server option.
- First seen
- Date not established
- In use today?
- Yes
- Legacy?
- Yes
- Transport
- Separate peer-to-peer TCP connections between clients
Current use and key considerations
Retained in TinTin++, MUSHclient, and other compatible clients, but based on old peer-network assumptions.
- NAT and contemporary network security complicate the original model.
- Inbound messages and files are untrusted.
Read the local MMCP reference →
A peer chat and file-transfer protocol inspired by, but incompatible with, MudMaster chat.
- First seen
- 1999
- In use today?
- Yes
- Legacy?
- Yes
- Transport
- Separate client-to-client TCP protocol
Current use and key considerations
Historically associated with zMUD and still recognized by MUSHclient; it is not a normal server feature.
- Do not assume compatibility with MMCP.
- The original trust model predates modern network expectations.
Read the local zChat reference →
A hidden game-data channel created for Aardwolf and recognized by several compatible clients.
- First seen
- Date not established
- In use today?
- Yes
- Legacy?
- No
- Transport
- Game-specific Telnet option 102
Current use and key considerations
Actively relevant only for Aardwolf compatibility.
- It is a private game convention, not a portable standard.
- Do not copy it into a greenfield engine.
Read the local Aardwolf 102 reference →
Creates multiple terminal screen contexts that can be selected, shown, hidden, and resized.
- First seen
- Circa 2002
- In use today?
- Not commonly
- Legacy?
- Yes
- Transport
- Non-standard Telnet option 112
Current use and key considerations
Only a narrow Cryosphere and Crystal history is documented; no broad contemporary adoption was verified.
- The option number is not an IANA assignment.
- Contemporary client support is extremely limited.
Read the local MPLEX reference →
A draft shared-secret authentication mechanism between a MUD proxy and server.
- First seen
- Date not established
- In use today?
- Not commonly
- Legacy?
- Yes
- Transport
- Draft Telnet option 202 using HMAC-SHA1
Current use and key considerations
No verified production implementation was found, and the archived specification questions whether one existed.
- HMAC-SHA1-era shared-secret deployment is not a suitable new security baseline.
- Draft option numbers do not establish interoperability.
Read the local MPCP reference →
A Portal-client UI messaging protocol with identification, security-code, length, command, and data fields.
- First seen
- Date not established
- In use today?
- Not commonly
- Legacy?
- Yes
- Transport
- In-band length-coded lines beginning with #K%
Current use and key considerations
A legacy compatibility format for servers that explicitly targeted Portal for Windows.
- The security code is not a replacement for transport security.
- No broad contemporary client ecosystem exists.
Read the local Portal MIP reference →
Adds styling, images, sound, forms, links, panes, and historical VRML features for Pueblo-enhanced clients.
- First seen
- Mid-1990s
- In use today?
- Not commonly
- Legacy?
- Yes
- Transport
- In-band HTML-like multimedia stream
Current use and key considerations
Relevant to historical MU*, MUSH, and MOO deployments; not a modern general-client target.
- Rich markup crosses a substantial trust boundary.
- Do not globally switch ordinary user text into HTML.
Read the local Pueblo reference →
A BBS graphics protocol that was adopted by a small number of MUDs.
- First seen
- 1993
- In use today?
- Not commonly
- Legacy?
- Yes
- Transport
- In-band line-oriented vector and UI commands
Current use and key considerations
The preservation archive states that no clients in use support it today.
- It is not a viable default MUD UI protocol.
- Treat command-driven graphics as active content.
Read the local RIPscrip reference →
A GameScry-oriented game and status data mechanism described in community inventories.
- First seen
- Date not established
- In use today?
- Not commonly
- Legacy?
- Yes
- Transport
- Historical directory/status data convention
Current use and key considerations
No current authoritative public specification or active implementation was verified.
- Do not infer a wire format from secondary descriptions.
- A missing canonical specification prevents safe interoperability.
Read the local GSGP reference →
The base framing and negotiation layer beneath most traditional MUD sessions and MUD-specific Telnet options.
- First seen
- 1983
- In use today?
- Yes
- Legacy?
- No
- Transport
- TCP byte stream with IAC commands and subnegotiation
Current use and key considerations
Universal across traditional MUD servers and clients.
- One recv call does not equal one Telnet command.
- Keep protocol framing byte-oriented even when application text is UTF-8.
Read the local Telnet reference →
Controls which side echoes typed characters, especially while entering passwords.
- First seen
- 1983
- In use today?
- Yes
- Legacy?
- No
- Transport
- Telnet option 1
Current use and key considerations
A standard part of traditional interactive Telnet sessions.
- Incorrect state can expose passwords on screen.
- Echo state is independent from transport encryption.
Read the local ECHO reference →
Enables the full-duplex terminal behavior expected by modern interactive MUD sessions.
- First seen
- 1983
- In use today?
- Yes
- Legacy?
- No
- Transport
- Telnet option 3
Current use and key considerations
Commonly negotiated by MUD servers and clients.
- Suppressing ordinary GA does not imply EOR support.
Read the local SGA reference →
Marks an unambiguous completed prompt or record boundary.
- First seen
- 1983
- In use today?
- Yes
- Legacy?
- No
- Transport
- Telnet option 25 and command 239
Current use and key considerations
Supported by capable clients and recommended where precise prompt detection matters.
- Do not assume EOR merely because SGA is active.
- Provide ordinary text behavior for clients that decline it.
Read the local EOR reference →
Lets the client report terminal columns and rows and send later resize changes.
- First seen
- 1988
- In use today?
- Yes
- Legacy?
- No
- Transport
- Telnet option 31 with two unsigned 16-bit dimensions
Current use and key considerations
Broadly supported by current clients and engines.
- Dimensions are client-reported and may be zero or implausible.
- Display width differs from raw UTF-8 byte length.
Read the local NAWS reference →
Allows a server to request one or more terminal or client identity strings; MTTS extends the reply sequence.
- First seen
- 1989
- In use today?
- Yes
- Legacy?
- No
- Transport
- Telnet option 24
Current use and key considerations
Broadly implemented and the normal foundation for MTTS capability discovery.
- Do not assume a fixed number of replies.
- Client names are self-asserted.
Read the local TTYPE reference →
Exchanges named environment variables; MNES defines a MUD-oriented set of keys on top of it.
- First seen
- 1994
- In use today?
- Yes
- Legacy?
- No
- Transport
- Telnet option 39
Current use and key considerations
Implemented by several engines and clients, though MUD-specific use is optional.
- Environment values are untrusted and must not grant privileges.
- Request only values the application needs.
Read the local NEW-ENVIRON reference →
Negotiates the character encoding used for session text, with UTF-8 the practical modern target.
- First seen
- 1997
- In use today?
- Yes
- Legacy?
- No
- Transport
- Telnet option 42
Current use and key considerations
Common in current protocol-capable engines and clients.
- A selected encoding does not change protocol control-byte rules.
- Handle clients that decline or misreport support.
Read the local CHARSET reference →
Provides color, cursor movement, text styling, and the presentation substrate used by most MUDs.
- First seen
- 1970s–1980s
- In use today?
- Yes
- Legacy?
- No
- Transport
- In-band terminal escape sequences
Current use and key considerations
Universal in practice at varying capability levels.
- Unsupported sequences can make output unreadable.
- Control sequences embedded in untrusted text must be sanitized.
Read the local ANSI / ECMA-48 reference →
Protects credentials and session data with transport confidentiality, integrity, and server authentication.
- First seen
- 1990s; TLS 1.3 in 2018
- In use today?
- Yes
- Legacy?
- No
- Transport
- Encrypted transport beneath Telnet or WebSocket
Current use and key considerations
A baseline capability for new deployments, commonly offered on a dedicated secure listener or through WSS.
- Compression and legacy protocol security codes are not substitutes.
- Plain Telnet remains visible to the network.
Read the local TLS reference →
Provides a browser-compatible bidirectional transport that can carry text, an application API, or full Telnet negotiation.
- First seen
- 2011
- In use today?
- Yes
- Legacy?
- No
- Transport
- HTTP Upgrade to WebSocket, optionally protected by TLS
Current use and key considerations
Widely used for browser clients; WSS is the secure deployment form.
- A plain text WebSocket and Telnet-over-WebSocket are not interchangeable.
- Browser origin and authentication rules still apply.
Read the local WebSocket / WSS reference →
Adds clickable hyperlinks to terminal text; some clients provide additional action-oriented extensions.
- First seen
- Date not established
- In use today?
- Yes
- Legacy?
- No
- Transport
- In-band terminal OSC escape sequence
Current use and key considerations
Growing modern terminal support makes it a useful link enhancement alongside MXP and plain text.
- Client-specific extensions are not universal OSC 8.
- Do not hide essential commands behind links alone.
Read the local OSC 8 reference →
The foundational LPC inter-MUD protocol, using peer discovery and game-port offset conventions.
- First seen
- August 1992
- In use today?
- Not commonly
- Legacy?
- Yes
- Transport
- UDP full mesh between MUD servers
Current use and key considerations
Historically important and evolved into Intermud 2; not a recommended greenfield network.
- Player clients are not participants.
- UDP delivery and source identity require defensive handling.
Read the local CD Intermud reference →
A backward-compatible expansion of CD Intermud used by several LPC-derived mudlibs.
- First seen
- 1990s
- In use today?
- Yes
- Legacy?
- Yes
- Transport
- Primarily UDP mesh; later TCP additions exist
Current use and key considerations
Historical deployments and subsets may remain, but I3 is the more significant surviving LPC router architecture.
- UDP is unreliable.
- Different mudlibs may implement only subsets.
Read the local Intermud 2 reference →
An early inter-MUD network for Circle, Merc, Envy, and related servers using standalone daemons.
- First seen
- 1995–1996
- In use today?
- Not commonly
- Legacy?
- Yes
- Transport
- UDP between daemons; local Unix socket to the MUD
Current use and key considerations
An abandoned historical system.
- Position-dependent fields require strict validation.
- Do not expose the local control socket broadly.
Read the local Circle Intermud reference →
A peer-list-propagating UDP inter-MUD network historically popular in Europe.
- First seen
- 1990s
- In use today?
- Yes
- Legacy?
- Yes
- Transport
- UDP full mesh
Current use and key considerations
The current preservation overview describes it as still in use, though it remains a legacy architecture.
- Full-mesh UDP has authenticity, reliability, and scaling limitations.
Read the local Zebedee reference →
A router-based inter-MUD network associated with Merc, SMAUG, ROM, Diku, and related families.
- First seen
- Late 2004
- In use today?
- Yes
- Legacy?
- Yes
- Transport
- TCP star network with central routers
Current use and key considerations
Still described as in use, assisted by bridging with I3.
- The historical framing does not define modern text encoding clearly.
- A central router is a trust and availability dependency.
Read the local IMC2 reference →
A major LPC-oriented router network carrying channels, tells, mudlists, services, and out-of-band traffic.
- First seen
- 1990s
- In use today?
- Yes
- Legacy?
- Yes
- Transport
- TCP connections to synchronized routers using LPC data
Current use and key considerations
One of the strongest surviving traditional inter-MUD architectures.
- LPC-style payloads complicate non-LPC implementations.
- Routers and remote MUDs are separate trust domains.
Read the local I3 reference →
A basic centralized chat-oriented network created for AberMUDs.
- First seen
- Date not established
- In use today?
- Not commonly
- Legacy?
- Yes
- Transport
- TCP through a central router
Current use and key considerations
The current preservation overview describes it as effectively dead.
- No current ecosystem justifies using it as a default network.
Read the local AberChat reference →
A Merentha-oriented inter-MUD messaging system also known as Merentha Intermud.
- First seen
- Date not established
- In use today?
- Not commonly
- Legacy?
- Yes
- Transport
- Historical UDP mesh
Current use and key considerations
Preserved as a legacy network design without verified current deployment.
- Historical sources and deployments are sparse.
Read the local InterMer reference →
Connects worlds through a privileged bot account and special in-game commands rather than native outbound networking.
- First seen
- Date not established
- In use today?
- Not commonly
- Legacy?
- Yes
- Transport
- Central server logs into each MUSH as a bot
Current use and key considerations
A clever historical MUSH integration pattern with no broad contemporary deployment verified.
- A compromised central service receives an authenticated in-game foothold.
- The bot session is a security boundary, not ordinary player traffic.
Read the local MUSHLink reference →
A MUSHLink-derived network whose central service connected to participating worlds as privileged users.
- First seen
- 1997
- In use today?
- Not commonly
- Legacy?
- Yes
- Transport
- Modified MUSHLink central bot architecture
Current use and key considerations
New applications closed in 2010; the system is historical.
- The privileged-bot trust model carries substantial risk.
- The network is closed to new applications.
Read the local Mudnet reference →
An attempted evolution or revival of the Circle Intermud approach.
- First seen
- 1998
- In use today?
- Not commonly
- Legacy?
- Yes
- Transport
- Circle-style inter-MUD software
Current use and key considerations
Historical with no verified current network.
- Do not confuse the protocol name with the ROM MUD codebase family.
Read the local RoM Intermud reference →
An inter-MUD design in which an external spider uses MSDP and discovers support through the MSSP INTERMUD field.
- First seen
- Date not established
- In use today?
- Yes
- Legacy?
- No
- Transport
- A spider connects to ordinary MUD ports and uses MSDP
Current use and key considerations
Niche but architecturally convenient for an MSDP and MSSP-capable server.
- The spider connects through a public game endpoint.
- MSSP advertisements do not authenticate the network peer.
Read the local Arachnos reference →
A contemporary inter-MUD experiment using WebSocket transport.
- First seen
- Contemporary; date not established
- In use today?
- Yes
- Legacy?
- No
- Transport
- WebSocket-based star network
Current use and key considerations
A newer niche project worth watching, but not yet comparable in deployment with I3 or IMC2.
- Contemporary does not imply established interoperability.
- Router availability and governance remain architectural dependencies.
Read the local MUDVault Mesh reference →
An external network formerly used for cross-game chat and related services.
- First seen
- Date not established
- In use today?
- Not commonly
- Legacy?
- Yes
- Transport
- External routed network and web services
Current use and key considerations
The current MUD Standards overview describes Grapevine itself as apparently dead.
- Do not make a new architecture depend on an inactive external service.
Read the local Grapevine reference →
No protocols match those filters. Clear a filter or try a broader search.