TIC Processor

Handles FidoNet file echoes — files distributed network-wide
the same way Echomail distributes messages, but with metadata
in a separate .TIC companion file.

Flow

inbound BinkP
    ↓
.TIC + file land in inbox/<area>/
    ↓
TIC processor parses .TIC:
  Area: SCENE_FILES
  File: scene2026-01.zip
  Desc: BBS scene news, January
  Crc: 12345678
    ↓
File moves to data/files/<area>/  +  description set
    ↓
File appears in /files/<area>/

Sysop config

File areas that carry a TIC file-echo are managed at
/admin/file-areas — each one is a FileArea row attached to an
EchomailNetwork (network_id set). For each: which local storage
path to drop into, and (under /admin/file-echo-subs) which peers
are subscribed to receive it. A downstream peer can also self-serve
their own subscriptions via netmail to the FileFix
robot instead of the sysop managing it by hand.

Forwarding

If you have nodes peering off you for the same TIC area, the
processor regenerates a fresh .TIC with you in the path and
queues it for outbound BinkP to each downlink.

Outbound — auto-hatch on local upload

Inbound TIC processing (above) isn't the only way a file gets
distributed. Any file that lands in a network-attached file area
gets queued for outbound distribution automatically — no separate
"send this out" step:

1. A user or sysop uploads a file into a file area whose
   network_id is not null (for example one of
   ANotherNetwork's ANN.FILES.* areas).
2. The upload route calls hatch_local_file(), which looks up every
   peer subscribed to that file echo and drops one HatchQueue row
   per peer — this is the origin hop, so there's no prior TIC to
   forward, just a fresh one built from scratch.
3. The next outbound BinkP session to each subscribed peer picks up
   its pending HatchQueue rows, builds the .TIC companion file
   (filling in SEEN-BY/PATH for that hop), and ships the file.

This runs from every upload path that can write into a network file
area — the regular /files/ upload form, the sysop's
"manage upload" tool, the smart-upload flow, and approving a queued
file in the upload-review queue. A local-only file area
(network_id is null) never triggers this — there's nobody to hatch
to.

Checksums

.TIC carries a CRC32. If the file's CRC doesn't match, the file is
left in place (not moved) and the TIC row is flagged status='error'
with an error_message describing the mismatch (expected vs. actual
CRC) — visible in the TIC admin log for manual review.

Admin logs

Inbound and outbound get separate log pages: TIC In Log
(/admin/tic-log) for manifests received, TIC Out Log
(/admin/hatch-log) for the HatchQueue items described above —
pending/sent/failed, which peer, retry count, and the last delivery
error if one occurred, filterable by status. Both are linked from the
Hub Management TIC/File Distribution tab.

See also

• Echomail
• BinkP Setup
• Files
• ANotherNetwork