SPITFIRE NG Technical Reference

Website reading edition · D1–D3 accepted source, schema 37. The older 0.1.0 binary download predates this work. A schema is the version of the board’s stored data layout; it is separate from CircuitNET protocol 1.4 and catalog format versions. Lower schema numbers below mark historical feature introductions, not the current baseline. Current status · Start here.

Caller sessions specifies atomic admission, exclusive account ownership, safe profile writes and interrupted-session recovery.

D1 deployment specifies authenticated releases, installation transactions, backup capacity and runtime rollback compatibility.

Conference Health specification describes native readership/activity and the optional caller bulletin.

Public network identity records canonical publication locations and service-state boundaries.

Current source implements N1–N6 networking and N7 FTN file networking. Native messages and files remain canonical; BinkP is transport only. No live public FidoNet participation is claimed.

Applies to: Current SPITFIRE NG source (main, schema 37)

Latest downloadable release: SPITFIRE NG 0.1.0 Development Preview

This reference follows current source. Release-specific behavior must be checked against the documentation shipped with that release.

The Technical Reference is the implementation-level map for advanced Sysops, contributors, integrators, and future maintainers. It points to the current canonical specifications rather than duplicating them into a second body of prose.

For task-oriented board operation, use the Sysop Reference Manual. For caller-facing instructions, use the Caller Guide. Historical evidence, original-runtime findings, and interoperability provenance remain in the research layer.

How authority is organized

The runtime is split into a transport-neutral caller/session engine, durable domain state in SQLite, confined project-managed bytes, versioned resource packages, and compatibility adapters. Stable identifiers, transactions, dispatch-time reauthorization, optimistic versions, leases, bounded parsers, and cold recovery protect that authority across concurrent nodes and failures.

Historical SPITFIRE documentation and controlled evidence define historical compatibility behavior. Modern comparison projects and protocol peers can inform implementation technique, but they do not redefine SPITFIRE.

Reference map

Project and system architecture

The Rust workspace currently contains sf-bbs for application/runtime orchestration, sf-core for portable domain and persistence behavior, sf-monitor for the capability-aware operator TUI and sf-legacy for bounded legacy parsing. The public workspace manifest remains the package-membership authority.

Database, schema history, and transactions

Schema history is documented in the component specifications and migration tests that introduced each version. Native runtime startup is the migration boundary; restore preserves an older supported snapshot exactly until normal writable startup migrates it.

Caller identity, access, and privacy

These documents define login identifiers, public handles, private profile data, credentials, caller lifecycle, security adjustments, subscription and name policy, caller-directory publication, session invalidation, and privacy-safe audit.

Messages and conferences

The message specifications cover conference authority, immutable shared payloads, delivery identities, CC fan-out, receipts, visibility, tombstones, copy/forward lineage, discovery, paging, and concurrent mutation.

Files, transfers, and storage

These are the canonical sources for stable FileId, lifecycle and integrity, inspection, requests and review, duplicate/policy handling, operation sagas, protocol engines, ephemeral batch queues, reservations and settlement, daily and ratio policy, zero-byte authority, storage roots/locators, read-only media, staging, active-use conflicts, and recovery.

Transports, nodes, and sessions

The common session engine owns caller semantics. Telnet, RAW, RLogin, SSH, stdio, serial, and modem adapters provide byte transport and bounded capability information; presentation and file-transfer protocols do not gain authorization from the carrier.

Presentation and localization

Character repertoire, terminal behavior, graphics protocol, and font/visual profile are separate capability layers. Planned presentation research does not become runtime capability until its interface, security, fallback, and client acceptance are implemented.

Backup, recovery, audit, and operator authority

Cold backup owns a validated consistent checkpoint. Online mutations remain daemon-authoritative and use typed domain commands; maintenance and offline operations require the ownership mode defined by the operator architecture. Audit records outcomes and identifiers without retaining secrets, raw terminal input, transferred content, or host paths unnecessarily.

Operator observability and reports

Schema 18 and B-017 implement retained operational events, daily summaries, retention, notifications, privacy-safe maintenance/status views, and bounded daemon-authoritative read APIs. Schema 19/B021-A transports those views through protected Unix sockets and Windows named pipes plus a noninteractive operator client. The protocol uses OS-backed local identity, version/feature negotiation, distinct capabilities, daemon generation, and dispatch-time authorization. Current sfmonitor presents those reads plus explicitly enrolled B021-B Actions in a responsive local TUI. The accepted integrated live-control milestone adds acknowledgement, time, page/chat, disconnect, and daemon shutdown without moving authority into the monitor. B021-C / sfconfig now provides shared typed configuration authority. Screen/export formats and report publication remain future work rather than alternate data owners.

Compatibility adapters and historical formats

Native semantic state remains distinct from legacy import, export, and publication. Parsers bounds-check every read, preserve unknown bytes when required, avoid unsafe structure casts, and use synthetic public fixtures.

Protocol and interoperability evidence

The runtime implements ASCII, XMODEM Checksum, XMODEM CRC, 1K-XMODEM, 1K-XMODEM-g, YMODEM Batch, YMODEM-g Batch, ZMODEM Batch, and TeLink behind one transport-neutral engine boundary. Interoperability reports are evidence, not bundled peer software.

Extension and future-component boundaries

These documents describe boundaries and future work. A specification in this section does not, by itself, mean the component is implemented.

Technical documentation rules

  • Link to one canonical specification rather than cloning its contents.
  • State whether a claim is confirmed, inferred, modernized, or unresolved.
  • Keep historical evidence separate from modern engineering comparisons.
  • Document security, bounds, concurrency, failure, and recovery behavior with every state-changing interface.
  • Keep public technical documents free of private sample paths, credentials, caller identities, screenshots, and proprietary bytes.
  • Update the Sysop Manual or Caller Guide when an internal change alters what those readers must do or will observe.

Existing-document migration

Current top-level specifications remain canonical. Future work may move or summarize them under this directory one subject at a time, but only with link updates and an explicit replacement pointer. Research records and private continuity are not folded into this reference merely to simplify the tree.

The governing documentation and source-header rules are in Documentation Architecture and Source-Header Policy.

Typed configuration and sfconfig

B021-C is implemented: Configuration Authority specifies daemon-only online ownership, explicit locked offline ownership, revision/digest CAS, validated atomic replacement, receipt recovery, secret-safe projection, and sfmonitor handoff. The sfconfig manual documents the separate usable application. B021-D integration is complete and B-021 is VERIFIED.

Completed B-021 operator integration

B021-D is COMPLETE / ACCEPTED; B-021 VERIFIED. The closure report records final owner boundaries, regression/native evidence, and Windows deferrals.

QWK networking (N2)

QWK network reference documents typed partners, public/private exchange, native mailbox/transit, durable queues, provenance and recovery. Sysop procedure provides the operator path. Controlled Synchronet interoperability is tested; no public DOVE membership is claimed.

Native FTN core

FTN reference, Sysop manual and M047 acceptance cover implemented NetMail/EchoMail, points, multiple domains/AKAs, scanner/tosser, routing, shared queues and directory generations. No BinkP or live public participation is claimed.

  • BinkP transport: protocol, schema 24, custody, authentication, limits and restart/restore.

Networking operations and recovery — N5

See Networks operations for the cockpit, typed configuration, queue recovery and verified restore serial-floor reconciliation.

FTN hub services — N6

See hub authority contract for downstreams, subscriptions, AreaFix, bounded rescan, points and recovery. Schema 25; en-US 1.23.0 / 1,249 messages.

FTN file networking — N7

See FileEcho, TIC, hatching and FREQ for implemented authority and workflows. Schema 28; en-US 1.25.0 / 1,308 messages.

See the account and posting identity contract for schema 28 name privacy and sender stability.

C5 Events and CircuitNET operations

Native Events defines scheduler authority, clocks, concurrency, lifecycle and networking integration. Future shared Files obligations records the separate archive/scanner design gate.

C6 shared Files authority

Native Files custody defines content identity, bounded archive inspection, scanner results, publication fences and payload-aware backup. The CircuitNET 1.3 extension uses native Files and generic Events for bounded file distribution. See M069 for current acceptance.

C7 network catalog authority

Catalog schema, signing, chain and local generations define independent network identity, rollback protection and existing TLS/Events integration.

Catalog access and signing-key recovery

See Catalog access and signing-key recovery for the revised kit, Sysop access, generated identities and deliberate authority replacement. Member setup starts with the kit README.

Source: public docs/technical/README.md. Navigation is adapted for this site; stale overview version/networking labels are reconciled with the accepted D3 checkpoint.

Terms used by the references

  • Immutable message identity: a stable message identifier and original author/parent record that later edits do not replace.
  • Custody: recorded responsibility for accepted work or data; a network acknowledgement records one hop's acceptance, not final delivery to a caller.
  • FTN: FidoNet-style store-and-forward networking. BinkP carries queued FTN mail over a network connection; it does not itself define message policy or grant FidoNet membership.
  • QWK: a packet format for offline mail reading and replies; its networking adapter is distinct from CircuitNET.
  • Catalog Authority: the approved publisher and trusted public signing key for CircuitNET's official conference list.
  • Catalog generation/revision: a numbered edition of that list, separate from board schema and protocol version.
  • Dossier: a conference subscription list for one direct CircuitNET neighbor. Node ID identifies a BBS; ROOT, HOST and END describe network routing roles, not caller privileges.

D1–D3 implementation references

Update architecture · Session concurrency · Native message identity and threads · Accepted tests and platform limits.