Run a QWK Network Hub

This howto describes how to configure your Synchronet BBS to act as a QWK network hub — that is, a system that other QWK-compatible BBSes call into to exchange networked messages. If instead you want to join an existing network as a node (caller), see dove-net or read about the Network Hubs... sub-menu in networks.

A QWK-netted BBS is a node, a hub, or both:

• A node calls a hub, uploads a REP packet, and downloads a QWK packet.
• A hub receives those calls, distributes incoming messages to other nodes, and packages outgoing messages for each node.

Being a hub doesn't require any extra server or service — Synchronet's regular Terminal Server handles QWK packet transfers. All you need is a properly configured user account for each node that will call your system.

For the on-the-wire details and conference-numbering rules of QWK networking on Synchronet, see qwknet.

Decide which sub-boards (message areas) you want to network. For each one, you'll typically want to create a message group dedicated to the network, with one sub-board per conference you intend to carry. Conference numbers in QWK packets follow the Group/Sub scheme described in qwknet — Group 1 / Sub 1 = conference 1001, Group 2 / Sub 3 = 2003, etc. Each node will configure those numbers on their end when calling you.

Set a Default Tagline for QWK packets in SCFG -> Networks -> QWK so each node receives identifying text in messages they import from you.

For every QWK node that will call your BBS, create a Synchronet user account:

1. Logon locally (or via the BBS) as New — or use useredit / uedit / the User Editor.
2. Use the node's QWK-ID as the user name (and alias, if you collect one). QWK-IDs are 1–8 characters, alphanumeric, and must start with a letter.
3. Give the account a security level high enough to read and post on every networked sub-board. Typically a dedicated level reserved for QWKnet nodes works well; otherwise grant access via flags or ARS.

The account must have the Q restriction set. The Q restriction is what makes the account a QWKnet node account rather than a regular user account:

• It drops the user straight to the QWK: prompt at logon, bypassing the normal logon procedure and menu shell.
• It allows the account to upload REP packets containing messages from any user name (the Net Status privilege), which is essential — a node forwards messages on behalf of its users.
• It allows the account to receive private posts addressed to other users (so you can route them onward in the network).
• It automatically excludes non-networked sub-boards from the QWK packets it generates.
• It causes locally-created messages exported into the REP packets to be tagged with your default tagline.
• Synchronet writes a NETFLAGS.DAT into the QWK packet for Q-restricted accounts (for compatibility with non-Synchronet QWKnet nodes; Synchronet itself ignores it).

In UEDIT / useredit, toggle Restrictions -> Q.

Two exemptions make life easier for high-frequency or long call-out nodes — set these on the node account in addition to the Q restriction:

• L — Logons per day. Removes the per-day logon cap so the node can call as often as it needs to.
• T — Time Online. Removes the per-call and per-day time limits so a single large QWK packet doesn't get cut short.

The Q restriction itself does not imply these — they're independent exemptions you set on the account.

Make sure the security level (and any flags / ARS) you assigned to the node account permits reading and posting on every sub-board you want to network with that node. A common mistake is creating the Q-restricted account and forgetting that a flag-gated sub-board is now invisible to it — the conference will silently drop out of the QWK packet.

If you maintain multiple node accounts and want to feed different sub-boards to different nodes, use per-sub-board access ARS to scope what each node sees.

The node sysop needs three things from you:

1. Your QWK-ID (set in SCFG -> Message Options -> BBS ID for QWK Packets). They'll enter this as the Hub System ID on their side.
2. The user name and password of the QWKnet account you created for them.
3. The conference numbers for each sub-board you're networking with them. (Group/Sub mapping per qwknet.)

If you're using something other than the standard *QNET (built-in QNET-FTP) module on your end, share the call-out details. For most modern Synchronet-to-Synchronet hubs, *QNET over FTP is the simplest path — see qnet-ftp.

QWK networking can also carry files between nodes and hubs. To send a file to a specific node, drop it into:

/sbbs/data/qnet/QWKID.OUT/

(Replace QWKID with the node's QWK-ID.) The next time that node calls and downloads its QWK packet, the file is appended to the packet.

Files arriving from a node land in:

/sbbs/data/qnet/QWKID.IN/

The sysop is notified of the new file. See QWKnet: Transferring Files Between Nodes and Hubs for details.

If you're a hub that connects multiple QWKnet networks or provides upstream routing, you can build a route map (/sbbs/data/qnet/route.dat) so NetMail addressed to systems you don't directly carry can be relayed through the right uplink. The qwknodes utility can generate route.dat from your node list. See qwknet for the routing rules.

• Watch /sbbs/data/logs/ for QWK-related log messages. The Synchronet Control Panel / umonitor also shows live activity.
• Use smbutil / chksmb to inspect the message bases the node is touching.
• If a node reports missing conferences in the QWK packet they received, double-check the node account's access to those sub-boards and that the sub-boards are actually flagged as networked.

• Synchronet QWK Network Extensions — protocol-level reference
• QWK packet format
• Network Configuration (SCFG) — including Network Hubs.../...QWK Network Hub (the caller side)
• User Restrictions (the Q flag)
• User Exemptions (L and T)
• qwknodes — manage QWKnet node lists / route maps
• qnet-ftp.js — built-in Synchronet QWKnet call-out module
• Join DOVE-Net — the node-side counterpart, useful as a worked example