FidoNet: A Store-and-Forward Network Built from Bulletin Boards

FidoNet connected independently operated bulletin-board systems long before a household Internet connection was ordinary. Its central trick was not a novel physical network. It was a set of conventions and programs that let computers with modems exchange queued messages and files during brief, scheduled calls. People could leave a message on one system, disconnect, and later receive a response after several machines had relayed the traffic. That store-and-forward design turned local bulletin boards into a wide-area discussion and messaging network without requiring every participant to be online at once.

The network is often described as if it were a centralized service or a single protocol. The historical record instead shows an evolving federation: independently run nodes, coordinator-maintained address lists, software from multiple authors, technical standards, and local choices about which links to call. Tom Jennings’s 1985 history and operations document is especially valuable because it explains early practice close to the events, while later FidoNet standards show how the community formalized interfaces as the network grew.

From one BBS to a network of BBSes

The first Fido bulletin-board software ran on personal computers connected to telephone lines. A caller dialed a board, logged in, read messages, uploaded or downloaded files, and disconnected. A local BBS was useful on its own, but a user could only reach people who called that number. FidoNet’s software made boards exchange messages with one another, allowing a user to compose locally and send across a chain of systems.

Early nodes often called one another directly. As the number of boards grew, address assignment and routing needed more structure. Jennings’s account describes a network that began with simple node numbering and progressively added coordination conventions. The growth was social and operational as well as technical: a network of volunteer sysops required documentation, a way to discover reachable nodes, and rules that could survive software written by different people.

FidoNet should not be confused with an always-on packet network. It did not reserve a continuously available circuit or deliver each keystroke interactively between distant callers. It made asynchronous communication possible by storing messages at nodes until a scheduled call or a route opportunity moved them onward. This made the network compatible with the economics of the period: a home computer and modem could call at night, when long-distance rates were lower, and exchange only the queued material that needed transfer.

Addressing was a routing convention

FidoNet’s familiar address form is zone:net/node, with an optional point component for a system reached through another node. The address is not an Internet IP address and does not itself guarantee a physical route. It identifies a place in the FidoNet addressing hierarchy. A published nodelist associated node numbers with system and connection details, and coordinators organized the hierarchy into zones, nets, and nodes.

That distinction matters. The address described the network’s logical organization; actual delivery depended on mailer configuration, the current nodelist, routing files, time windows, and which system accepted traffic for which destinations. A node might send a message to a regional hub rather than make an expensive long-distance call to the final recipient. The hub could then forward it using another link. Route files and local policies provided practical flexibility, while the address hierarchy gave the community a shared map.

Coordination did not mean that one central server carried all traffic. FidoNet had network coordinators and a public node list, but individual boards still operated their own hardware and maintained their own users and message areas. The topology was distributed in operation yet administratively organized. This is different from both a wholly unstructured peer-to-peer mesh and a centrally hosted service.

Mailers, packets, and the dial-up session

A FidoNet system typically had a BBS application for local users and separate or integrated software for outbound and inbound transfers. A mailer watched for calls, exchanged identification, and transferred queued packets using a supported session and file-transfer protocol. The local system then unpacked messages into its message areas or retained them for onward routing. The exact software varied; the standards were intended to let independent implementations interoperate.

The first formal baseline, FTS-0001, documents basic message formats and an original session and link protocol family. Early file transfers could use XMODEM-style blocks with acknowledgments and retransmission. Such a design was understandable for unreliable modem links, but stop-and-wait behavior and small blocks could be inefficient on long or noisy transfers. Later standards, including FTS-0006, described enhanced session protocols and more efficient link options. That evolution is important: FidoNet was not frozen at its first protocol, and an early document should not be presented as the only transport used throughout its life.

Mail was commonly bundled for a call. Instead of leaving an expensive telephone connection open while users composed messages, a system could gather outbound traffic and transfer it in batches. Compression and restart-capable transfer protocols reduced connection time and repeated work. The network could be scheduled to call at specific hours, retry on busy lines, and exchange mail with a hub or peer. These mechanics are the reason FidoNet is more precisely described as store-and-forward than as a real-time chat network.

Netmail and echomail served different purposes

Netmail addressed a message to a user or node and was routed toward a destination. Echomail distributed a message area to many participating boards, so a contribution entered at one node could appear at other nodes subscribed to that area. FTS-0004, the Echomail specification, formalized conventions for message exchange and control information. An echomail area was more like a replicated discussion conference than a direct private message, although implementation and moderation practices varied across networks.

Replication created familiar distributed-systems problems. The same message could traverse multiple links, so software and operators used origin and path information to avoid circulating copies indefinitely. Message identifiers and “seen-by” style routing traces helped systems decide where a message had already traveled. A malformed route or inconsistent configuration could create loops, duplicates, missing regions, or growing traffic. These were operational realities, not flaws that a single central server could resolve for everyone.

The difference between transport and user-visible area is crucial. A mailer might deliver a packet successfully to a node, while that node’s message-base software separately stored and presented the message. A user could see duplicated or absent messages because of routing, import, or area configuration even when the modem transfer itself had completed. FidoNet’s layered software arrangement made the network flexible, but it also meant that troubleshooting often involved more than one program and more than one administrator.

Standards emerged from working implementations

The FidoNet Technical Standards Committee maintained documents that describe message formats, nodelists, echomail, and transfer protocols. The historical sequence moved from proposal documents toward standards with versioned specifications. The current FTSC archive lists formal standards such as FTS-0001, FTS-0004, and FTS-0005, while archived histories document how technical contributors organized this work. Standards mattered because FidoNet was not produced by one vendor shipping a single software stack. Compatibility depended on shared formats and behavior across independently authored mailers and BBS programs.

The standards process should not be mistaken for a modern formal standards organization with universal enforcement. FidoNet conventions were adopted by a volunteer community and evolved through documents, software practice, and coordinator processes. Different software supported different subsets or extensions. A standard could describe a baseline while deployments used enhanced protocols where both endpoints supported them. The nodelist and standards therefore need to be read as records of both technical design and community governance.

Economics shaped the protocol

FidoNet’s architecture encoded its operating environment. Modems had limited throughput, phone calls cost money, machines were not continuously reachable, and volunteer sysops ran networks from homes or small organizations. Store-and-forward routing let an operator choose call schedules, hubs, and transfer windows. Users could read and compose messages offline, then let the next poll move them onward. That saved connection time and made international discussions possible even where bandwidth was scarce.

The price was latency. A message might wait until a scheduled call, miss a call because the line was busy, and wait through another retry window. A chain of hubs added additional intervals. There was no guarantee that a message would be delivered immediately or that a route remained current. Users learned to expect communication in hours or days rather than milliseconds. The system traded immediacy for reach and cost control.

The distributed model also relocated responsibility. Each sysop had to maintain a working modem, keep mail software configured, process packets, monitor storage, and coordinate routing. Network coordinators could publish lists and resolve administrative questions, but they could not repair every personal computer. The network’s reliability emerged from many local operators following shared procedures rather than from a centralized operations center.

Growth and the Internet transition

FidoNet expanded across national boundaries because its basic design did not depend on one carrier or one country-specific network. Local telephone access, compatible modem software, and an agreed routing plan could extend the system. International links still depended on telephone infrastructure, expense, local regulations, and volunteer capacity. The network’s reach should therefore not be confused with a single uniform global service.

As Internet access became more common, users could move discussions to Usenet or other online services and exchange mail through Internet gateways. This did not instantly end FidoNet. Existing communities, archives, local BBS culture, and low-cost access continued to matter. Some contemporary networks still use FidoNet-compatible technology. A historical account should avoid a simplistic “the Internet replaced it overnight” story; the shift varied by region and community.

FidoNet’s value to computer history lies in its working federation. It demonstrated that a network could emerge from ordinary computers and intermittent telephone calls, provided that software agreed on addresses, message formats, scheduling, and routing. It also made the human part impossible to ignore. The address hierarchy, nodelist, moderation, and volunteer coordination were not peripheral to the technology; they were how the technology operated at scale.

How to read the record

Jennings’s early account is a first-person operational history, not a neutral retrospective with every later correction incorporated. The FTSC standards are normative technical records, but they do not by themselves explain how every BBS implemented the documents. Later histories help describe growth and governance, though they should be checked against contemporaneous artifacts. Reading those materials together reveals a network that changed as contributors learned from real deployments.

FidoNet was neither a miniature Internet nor simply a set of isolated boards. It was an asynchronous, standards-based message network in which users interacted locally and systems synchronized later. That design helped connect communities without always-on infrastructure. Its compromises - latency, administrative work, fragile routes, and reliance on volunteers - were also the conditions that made it accessible to people who could not afford continuous connectivity.

Related:

Sources: