HTTP: , FTP:, and Dict:?

Original Article ↗ Hacker News Discussion ↗

Obscure internet protocols like `dict://` still power command‑line dictionary lookups and even integrate with tools like curl, Emacs, and macOS’s Dictionary app, but many users are surprised they exist at all. Commenters explore how and why such specialized text-based protocols arose—optimized for low disk space, human readability, and simple parsing—and how they’ve since been crowded out by HTTP, JSON APIs, and corporate firewalls that block non‑web ports. The exchange broadens into a comparison of protocol and data formats (DICT, WHOIS, HTTP, XML, JSON, YAML), weighing human-friendliness, security, and interoperability against modern expectations of convenience and scale.

dict:// protocol and tools

  • Many commenters hadn’t heard of the DICT protocol before; others have used it for years and install dict/dictd on every machine.
  • The CLI client dict is widely available via package managers, but not typically preinstalled. Some argue it’s unreasonable to expect a newcomer to guess there’s a matching command-line tool.
  • Emacs and macOS have integrations (M-x dictionary, dict://word opening Dictionary.app). Behavior varies by browser and OS; sometimes it fails, sometimes it prompts to open an external app.

curl support and distro choices

  • curl dict://dict.org/d:Internet works on some systems but fails on Fedora’s default curl-minimal, which omits DICT support.
  • Switching to the full curl/libcurl packages restores DICT and many other protocols. Some see the minimal default as “crippling,” others frame it as a space/security tradeoff.

Design of old text-based protocols

  • Several people admire human/machine-friendly text protocols (status codes plus explanations, built-in help).
  • Others argue they’re messy in practice and prefer well-structured formats like JSON, or even binary protocols, for robustness and ease of parsing.
  • There’s debate over XML vs JSON: XML is defended as powerful and compressible but criticized for complexity and security footguns; JSON is praised for simplicity and readability but blamed for ecosystem inconsistencies (dates, number handling, top-level arrays, naming conventions).

Implementing and storing dictionary data

  • One detailed subthread explores how dictd stores data efficiently with dictzip (gzip-compatible, chunked for random access) and TSV indexes, comparing it to zip-based approaches and tools like strfile, ctags, and other index formats.
  • Conclusion: with modern hardware, compressed chunked storage (e.g., zip, ~256KB chunks) offers near-random-access performance with small size penalties.

Availability, licensing, and alternate sources

  • Public dict servers still exist (e.g., dict.org, FreeDict servers). Some users run personal dictd instances.
  • There is interest in classic dictionaries like Webster’s 1913 and OED, but full OED hosting is acknowledged as legally problematic; many existing OED data files are of unclear provenance.
  • Conversion from StarDict to DICT format is possible but yields mixed-quality results.

Protocol ossification and HTTP dominance

  • Commenters note how non-HTTP protocols (DICT, Gopher, WHOIS-like services) largely died as NAT, firewalls, and corporate/university filtering blocked most ports except 80/443.
  • Some lament being forced to tunnel everything over HTTP; others claim HTTP+JSON (or REST-ish APIs) is a pragmatic, even superior, common foundation.