QWK

A classic offline-reading packet format. Download a QWK file, read
and reply offline, upload a REP packet back.

Why it exists

Phone calls used to cost money. Connect, download QWK packet,
disconnect. Read at leisure. Connect again only to upload replies.

In 2026 it's still useful for:

• Slow connections (cellular roaming, sat)
• Reading on a device that's not always online (a vintage laptop)
• Archiving a snapshot of the BBS at a point in time

Download

/qwk/ explains the feature; the actual packet comes from
/qwk/download, which bundles every active area's messages unread
since your last download automatically — there's no area or
date-range picker, it's always "everything new."

Upload

A .REP (reply) packet posts to /qwk/upload (a separate endpoint
from download). The BBS parses it and posts your replies to the
right boards / echos.

Readers

• MultiMail — modern Linux
• Bluewave (DOS, classic)
• Various Windows tools

Sysop tools — Hub Management

Hub-side QWK administration lives under
/admin/echomail/hub/qwk/ (part of Hub Management — see
Sysop Control Panel — gated behind REGISTRY_MODE_ENABLED, only
meaningful on the one install that is the network hub):

• Node list (/admin/echomail/hub/qwk/) — every downstream QWK
  node, packet ID, and subscription state; add/edit/delete nodes,
  reset their high-water mark.
• Node detail (/admin/echomail/hub/qwk/<node_id>) — click into
  a node to manage which echo areas it actually receives.
  Subscribe/unsubscribe areas one at a time, or use the
  Subscribe to All button to bulk-subscribe. It first shows a
  checkbox list of the QWK-transport networks on the install — pick
  one or more and confirm; picking none just flashes an error and
  subscribes nothing. Once confirmed, the node is subscribed to
  every active area on the checked network(s) — deliberately scoped
  to QWK-type networks only, not every area on the whole BBS, so a
  QWK node doesn't end up subscribed to something that only exists
  on a BinkP-only network. If the node belongs to a specific hub
  identity, this is further filtered to that identity's own
  network(s), so a node never gets swept into another network's
  areas just because it shares the install.
• Preview — a Preview button per node builds and downloads a
  test .QWK packet for that node on demand without marking any
  messages as sent, so a sysop can sanity-check what a peer would
  receive before the real packet goes out.
• Hold queue (/admin/echomail/hub/holdqueue) — BinkP-only, not
  QWK: outbound echomail queued per downstream BinkP node, flushed the
  next time that node polls in (or is polled). No moderation/policy-
  check step involved — it's purely a delivery queue, filterable by
  status (pending/sent).
• Node requests (/admin/echomail/hub/qwk/requests) — the
  approve/deny queue for BBSes applying for a new QWK node number
  (see ANotherNetwork for how a sysop submits one of these).
  Approving auto-creates the QWK node record with a generated
  password.

If you're a hub for more than one real network from this one install,
the QWK node form grows a Hub Identity picker once a second
identity exists, and each identity gets its own QWK Hub ID (the
<hub_id>.qwk sysops actually download) — see Sysop Guide,
"Running more than one hub identity." Almost no install needs this.