tiewave — a BlueWave gateway for Squish / HPT

tiewave bundles new echomail out of your Squish message bases into a BlueWave packet you can read offline, and takes the reply packet your offline reader produces and posts each message back into the system with hpt post. It is meant for the "limited internet in the woods" workflow:

   at home            in the woods              back at home
 ┌─────────┐  scan   ┌───────────────┐  toss  ┌──────────────┐
 │ Squish  │───────► │ BlueWave pkt  │ ─────► │ hpt post -x  │──► uplink
 │ bases   │ ◄─────  │ read + reply  │        │ (echo + net) │
 └─────────┘  (mm,   └───────────────┘        └──────────────┘
              BlueWave, etc.)

Written in Object Pascal (FPC 3.2.2). It reads the Squish .sqd/.sqi files read-only and never rewrites a message frame itself — every reply is injected through hpt post, so a bug here can't corrupt a live base.

Build

make            # produces ./tiewave
make install    # copies it to ~/Apps/tiewave (already on your PATH)

Only Free Pascal is required; the zip/unzip is done with FPC's built-in paszlib, so there are no external runtime dependencies.

Usage

tiewave scan [options]            build a BlueWave packet from new echomail
tiewave toss <reply> [options]    post the reply packet with hpt

Common options:

option	meaning
-c <file>	fidoconfig path (default /home/shawn/ftn/fidoconfig.cfg, or $FIDOCONFIG)
-v	verbose
-V, --version	print version and exit

scan

option	meaning
-o <file>	output packet name (default ~/Downloads/<id>.<day><seq>, e.g. TIEWAVE.mo0)
-i <id>	packet id / internal file basename (default TIEWAVE)
--all	ignore the .SQL read pointer and pack every message
--mark	advance each area's .SQL pointer to the newest packed message
-w <dir>	working directory for temp files

By default scan packs only messages newer than each area's read pointer and leaves the pointer untouched, so a re-run is harmless. Once you are happy that the packet reached your reader, run with --mark to advance the pointers so the next scan only picks up genuinely new mail. --mark prints the old and new .SQL value (with -v) so you can undo it by hand if needed.

tiewave scan --mark            # normal "give me the new mail" run
tiewave scan --all -o dump.zip # everything, pointers untouched (for testing)

The resulting packet (e.g. TIEWAVE.mo0) drops straight into an offline reader. For MultiMail, copy it into ~/mmail/down/.

The default name follows the traditional offline-mail scheme <id>.<day><seq>: a two-letter day-of-week code (su mo tu we th fr sa) plus a sequence character 0–9 then a–z, so several packets on the same day don't collide (TIEWAVE.mo0, TIEWAVE.mo1, …). The file is a zip; the extension is just the classic naming — readers detect the archive by content.

toss

tiewave toss TIEWAVE.new           # post replies and queue them for the uplink
tiewave toss TIEWAVE.new -n        # dry run: show what would be posted
tiewave toss TIEWAVE.new --no-export   # write to the base but don't queue to uplink

The reply packet may be:

• a zip archive, however your reader named it (.new, .rep, .zip …),
• an already-unpacked directory, or
• a bare .UPL file (its directory must also hold the NNNNN.MSG text files).

Each reply is posted with hpt post; echomail is posted with -x so hpt queues it for your links. Netmail replies are posted to your netmail area addressed to their destination. Use --hpt <path> if hpt isn't on $PATH.

toss is safe to interrupt or re-run. Each reply's text file is consumed (deleted) as soon as it posts, and after a clean run a file input is renamed to <name>.done — so running the same reply packet twice will not double-post. If some messages fail, the ones that already posted are gone and only the failures remain to be retried.

Typical session

# --- before leaving home ---
tiewave scan --mark -o /media/usb/TIEWAVE.zip

# --- in the woods ---
cp /media/usb/TIEWAVE.zip ~/mmail/down/
mm                      # read, reply; F2/! makes ~/mmail/up/tiewave.new

# --- back home ---
tiewave toss ~/mmail/up/tiewave.new
hpt toss                # (optional) also toss anything that came in

What gets packed

• Every Squish EchoArea in the config is listed in the packet's area list.
• Areas with new mail get their messages, in area order.
• Message text has the hidden control kludges (MSGID, PID, PATH, …) and the SEEN-BY: topology lines stripped; the --- tearline and * Origin: line are kept. Messages addressed to you by name are flagged personal.

Limitations / notes

• Echomail only for the packing direction (that's what lives in the Squish bases). The reply direction handles both echomail and netmail, since hpt post does.
• The reply packet is expected to be zip-compressed — the near-universal reader default. If your reader uses another archiver, unpack it yourself and point tiewave toss at the directory.
• Only the modern .UPL reply form is supported (the .INF advertises uses_upl_file = 1, packet version 3), not the legacy .UPI/.NET pair.
• Reply threading relies on the Re: subject; per-message reply kludges from the reader are not forwarded to hpt post.
• In the packet, messages are numbered 1..N per area (a Squish UID is a 32-bit value but the BlueWave FTI.msgnum field is only 16 bits, so the raw UID can't be carried safely). This is display-only and nothing in the reply path depends on it.

Files

file	purpose
tiewave.pas	main program (scan / toss, zip, hpt invocation)
squish.pas	read-only Squish base access + .SQL pointer
bwtypes.pas	on-disk record layouts (Squish + BlueWave)
ftnconfig.pas	minimal fidoconfig reader (address, sysop, echo areas)