FidoNet is a worldwide computer network that is used for communication between bulletin board systems (BBSes). It uses a store-and-forward system to exchange private (email) and public (forum) messages between the BBSes in the network, as well as other files and protocols in some cases.
The FidoNet system was based on a number of small interacting programs. Only one of these interacted with the BBS system directly and was the only portion that had to be ported to support other BBS software. This greatly eased porting, and FidoNet was one of the few networks that was widely supported by almost all BBS software, as well as a number of non-BBS online services. This modular construction also allowed FidoNet to easily upgrade to new data compression systems, which was important in an era using modem-based communications over telephone links with high long-distance calling charges.
The rapid improvement in modem speeds during the early 1990s, combined with the rapid decrease in price of computer systems and storage, made BBSes increasingly popular. By the mid-1990s there were almost 40,000 FidoNet systems in operation, and it was possible to communicate with millions of users around the world. Only UUCPNET came close in terms of breadth or numbers; FidoNet's user base far surpassed other networks like BITNET.
The broad availability of low-cost Internet connections starting in the mid-1990s lessened the need for FidoNet's store-and-forward system, as any system in the world could be reached for equal cost. Direct dialing into local BBS systems rapidly declined. Although FidoNet had shrunk considerably since the late 1990s, it has remained in use even today despite internet connectivity becoming universally available.
__ / \ /|oo \ (_| /_) _`@/_ \ _ | | \ \\ | (*) | \ )) ______ |__U__| / \// / FIDO \ _//|| _\ / (________) (_/(_|(____/ (c) John Madil
There are two major accounts of the development of the FidoNet, differing only in small details.
Around Christmas 1983, Tom Jennings started work on a new MS-DOS–hosted bulletin board system that would emerge as Fido BBS. Jennings set up the system in San Francisco some time in early 1984. Another early user was John Madil, who was trying to set up a similar system in Baltimore on his Rainbow 100. Fido started spreading to new systems, and Jennings eventually started keeping an informal list of their phone numbers, with Jennings becoming #1 and Madil #2.
Jennings released the first version of the FidoNet software in June 1984. In early 1985 he wrote a document explaining the operations of the FidoNet, along with a short portion on the history of the system. In this version, FidoNet was developed as a way to exchange mail between the first two Fido BBS systems, Jennings' and Madil's, to "see if it could be done, merely for the fun of it". This was first supported in Fido V7, "sometime in June 84 or so".
In early 1984, Ben Baker was planning on starting a BBS for the newly forming computer club at the McDonnell Douglas automotive division in St. Louis. Baker was part of the CP/M special interest group within the club. He intended to use the seminal, CP/M-hosted, CBBS system, and went looking for a machine to run it on. The club's president told Baker that DEC would be giving them a Rainbow 100 computer on indefinite loan, so he made plans to move the CBBS onto this machine. The Rainbow contained two processors, an Intel 8088 and a Zilog Z80, allowing it to run both MS-DOS and CP/M, with the BBS running on the latter. When the machine arrived, they learned that the Z80 side had no access to the I/O ports, so CBBS could not communicate with a modem. While searching for software that would run on the MS-DOS side of the system, Baker learned of Fido through Madil.
The Fido software required changes to the serial drivers to work properly on the Rainbow. A porting effort started, involving Jennings, Madil and Baker. This caused all involved to rack up considerable long distance charges as they all called each other during development, or called into each other's BBSes to leave email. During one such call "in May or early June", Baker and Jennings discussed how great it would be if the BBS systems could call each other automatically, exchanging mail and files between them. This would allow them to compose mail on their local machines, and then deliver it quickly, as opposed to calling in and typing the message in while on a long-distance telephone connection. Jennings responded by calling into Baker's system that night and uploading a new version of the software consisting of three files: FIDO_DECV6 (the new version of the BBS program itself), FIDONET, and NODELIST.BBS. The new version of FIDO BBS had a timer that caused it to exit at a specified time, normally at night, and as it exited it would run the separate FIDONET program. NODELIST was the list of Fido BBS systems, which Jennings had already been compiling.
The FIDONET program was what later became known as a mailer. FIDO was modified to use a previously unused numeric field in the message headers to store a node number for the machine the message should be delivered to. When FIDONET ran, it would search through the email database for any messages with a number in this field. FIDONET collected all of the messages for a particular node number into a file known as a message packet. After all the packets were generated, one for each node, the FIDONET program would look up the destination node's phone number in NODELIST.BBS, and call the remote system. Provided that FIDONET was running on that system, the two systems would handshake and, if this succeeded, the calling system would upload its packet, download a return packet if there was one, and disconnect. FIDONET would then unpack the return packet, place the received messages into the local system's storage, and move onto the next packet. When there were no remaining packet, it would exit, and run the FIDO BBS program.
By June 1984 Version 7 of the system was being run in production, and nodes were rapidly being added to the network. By August there were almost 30 systems in the nodelist, 50 by September, and over 160 by January 1985. As the network grew, the maintenance of the nodelist became prohibitive, and errors were common. In these cases people would start receiving phone calls at 4 AM, from a caller that would say nothing and then hang up. In other cases the system would be listed before it was up and running, resulting in long distance calls that accomplished nothing.
In August 1984 Jennings handed off control of the nodelist to the group in St. Louis, mostly Ken Kaplan and Ben Baker. Kaplan had come across Fido as part of finding a BBS solution for his company, which worked with DEC computers and had been given a Rainbow computer and a USRobotics 1200bit/s modem. From then on, joining FidoNet required one to set up their system and use it to deliver a netmail message to a special system, Node 51. The message contained various required contact information. If this message was transmitted successfully, it ensured that at least some of the system was working properly. The nodelist team would then reply with another netmail message back to the system in question, containing the assigned node number. If delivery succeeded, the system was considered to be working properly, and it was added to the nodelist. The first new nodelist was published on 21 September 1984.
Growth continued to accelerate, and by the spring of 1985 the system was already reaching its limit of 250 nodes. In addition to the limits on growth of what was clearly a popular system, nodelist maintenance continued to grow more and more time consuming.
It was also realized that Fido systems were generally clustered – of the 15 systems running by the start of June 1984, 5 of them were in St. Louis. A user on Jennings's system in San Francisco that addressed emails to different systems in St. Louis would cause calls to be made to each of those BBSes in turn. Local calls were normally free or charged at a low rate. Additionally, the initial call setup, generally the first minute of the call, was normally billed at a higher rate than continuing an existing connection. Therefore, it would make sense to deliver all the messages from all the users in San Francisco to all of the users in St. Louis in a single call. Packets were generally small enough to be delivered within a minute or two, so delivering all the messages in a single call could greatly reduce costs by avoiding multiple first-minute charges. Once delivered, the packet would be broken out into separate packets for local systems, and delivered using multiple local free calls.
The team settled on the concept of adding a new network number patterned on the idea of area codes.[N 1] A complete network address would now consist of the network and node number pair, which would be written with a slash between them. All mail travelling between networks would first be sent to their local network host, someone who volunteered to pay for any long distance charges. That single site would collect up all the netmail from all of the systems in their network, then re-package it into single packets destined to each network. They would then call any required network admin sites and deliver the packet to them. That site would then process the mail as normal, although all of the messages in the packet would be guaranteed to be local calls.
The network address was placed in an unused field in the Fido message database, which formerly always held a zero. Systems running existing versions of the software already ignored the fields containing the new addressing, so they would continue to work as before; when noticing a message addressed to another node they would look it up and call that system. Newer systems would recognize the network number and instead deliver that message to the network host. To ensure backward compatibility, existing systems retained their original node numbers through this period.
A huge advantage of the new scheme was that node numbers were now unique only within their network, not globally. This meant the previous 250 node limit was gone, but for a variety of reasons this was initially limited to about 1,200. This change also devolved the maintenance of the nodelists down to the network hosts, who then sent updated lists back to Node 51 to be collected into the master list. The St. Louis group now had to only maintain their own local network, and do basic work to compile the global list.
At a meeting held in Kaplan's living room in St. Louis on 11 April 1985[N 2] the various parties hammered out all of the details of the new concept. As part of this meeting, they also added the concept of a region, a purely administrative level that was not part of the addressing scheme. Regional hosts would handle any stragglers in the network maps, remote systems that had no local network hosts. They then divided up the US into ten regions that they felt would have roughly equal populations.
By May, Jennings had early versions of the new software running. These early versions specified the routing manually through a new ROUTE.BBS file that listed network hosts for each node. For instance, an operator might want to forward all mail to St. Louis through a single node, node 10. ROUTE.BBS would then include a list of all the known systems in that area, with instructions to forward mail to each of those nodes through node 10. This process was later semi-automated by John Warren's NODELIST program. Over time, this information was folded into updated versions of the nodelist format, and the ROUTES file is no longer used.
A new version of FIDO and FIDONET, 10C, was released containing all of these features. On 12 June 1985 the core group brought up 10C, and most Fido systems had upgraded within a few months. The process went much smoother than anyone imagined, and very few nodes had any problems.
Some time during the evolution of Fido, file attachments were added to the system, allowing a file to be referenced from an email message. During the normal exchange between two instances of FIDONET, any files attached to the messages in the packets were delivered after the packet itself had been up or downloaded. It is not clear when this was added, but it was already a feature of the basic system when the 8 February 1985 version of the FidoNet standards document was released, so this was added very early in Fido's history.
At a sysop meeting in Dallas, the idea was raised that it would be nice if there was some way for the sysops to post messages that would be shared among the systems. In February 1986 Jeff Rush, one of the group members, introduced a new mailer that extracted messages from public forums that the sysop selected, in a manner similar to the way the original mailer handled private messages. The new program was known as a tosser/scanner. The tosser produced a file that was similar (or identical) to the output from the normal netmail scan, however, these files were then compressed and attached to a normal netmail message as an attachment. This message was then sent to a special address on the remote system. After receiving netmail as normal, the scanner on the remote system looked for these messages, unpacked them, and put them into the same public forum on the original system.
In this fashion, Rush's system implemented a store and forward public message system similar to Usenet, but based on, and hosted by, the FidoNet system. The first such echomail forum was one created by the Dallas area sysops to discuss business, known as SYSOP. Another called TECH soon followed. Several public echos soon followed, including GAYNET and CLANG. These spawned hundreds of new echos, and led to the creation of the Echomail Conference List (Echolist) by Thomas Kenny in January 1987. Echomail produced world-spanning shared forums, and its traffic volume quickly surpassed the original netmail system. By the early 1990s, echo mail was carrying over 8 MB of compressed message traffic a day, many times that when uncompressed.
Echomail did not necessarily use the same distribution pathways as normal netmail, and the distribution routing was stored in a separate setup file not unlike the original ROUTES.BBS. At the originating site a header line was added to the message indicating the origin system's name and address. After that, each system that the message traveled through added itself to a growing PATH header, as well as a SEENBY header. SEENBY prevented the message from looping around the network in the case of mis-configured routing information.
Echomail was not the only system to use the file attachment feature of netmail to implement store-and-forward capabilities. Similar concepts were used by online games and other systems as well.
The evolution towards the net/node addressing scheme was also useful for reducing communications costs between continents, where timezone differences on either end of the connection might also come into play. For instance, the best time to forward mail in the US was at night, but that might not be the best time for European hosts to exchange. Efforts towards introducing a continental level to the addressing system started in 1986.
At the same time, it was noted that some power users were interested in using FidoNet protocols as a way of delivering the large quantities of echomail to their local machines where it could be read offline. These users did not want their systems to appear in the nodelist - they did not (necessarily) run a bulletin board system and were not publicly accessible. A mechanism allowing netmail delivery to these systems without the overhead of nodelist maintenance was desirable.
In October 1986 the last major change to the FidoNet network was released, adding zones and points. Zones represented major geographical areas roughly corresponding to continents. There were six zones in total, North America, South America, Europe, Oceania, Asia, and Africa. Points represented non-public nodes, which were created privately on a BBS system. Point mail was delivered to a selected host BBS as normal, but then re-packaged into a packet for the point to pick up on-demand. The complete addressing format was now
zone:net/node.point, so a real example might be
Bob Smith@1:250/250.10. Points were widely used only for a short time, the introduction of offline reader systems filled this role with systems that were much easier to use. Points remain in use to this day, but are less popular than when they were introduced.
Although FidoNet supported file attachments from even the earliest standards, this feature tended to be rarely used and was often turned off. File attachments followed the normal mail routing through multiple systems, and could back up transfers all along the line as the files were copied. A solution was offered in the form of file requests, which made file transfers driven by the calling system and used one-time point-to-point connections instead of the traditional routing. Two such standards became common, "WaZOO" and "Bark", which saw varying support among different mailers. Both worked in a similar fashion, with the mailer calling the remote system and sending a new handshake packet to request the files.
Although FidoNet was, by far, the best known BBS-based network, it was by no means the only one. From 1988 on, PCBoard systems were able to host similar functionality known as RelayNet, while other popular networks included RBBSNet from the Commodore 64 world, and AlterNet. Late in the evolution of the FidoNet system, there was a proposal to allow mail (but not forum messages) from these systems to switch into the FidoNet structure. This was not adopted, and the rapid rise of the internet made this superfluous as these networks rapidly added internet exchange, which acted as a lingua franca.
FidoNet started in 1984 and listed 100 nodes by the end of that year. Steady growth continued through the 1980s, but a combination of factors led to rapid growth after 1988. These included faster and less expensive modems, and rapidly declining costs of hard drives and computer systems in general. By April 1993 the FidoNet nodelist contained over 20,000 systems. At that time it was estimated that each node had, on average, about 200 active users. Of these 4 million users in total, 2 million users commonly used echomail, the shared public forums, while about 200,000 used the private netmail system. At its peak, FidoNet listed approximately 39,000 systems.[N 3]
Throughout its lifetime, FidoNet was beset with management problems and infighting. Much of this can be traced to the fact that the inter-net delivery cost real money, and the traffic grew more rapidly than decreases caused by improving modem speeds and downward trending long distance rates. As they increased, various methods of recouping the costs were attempted, all of which caused friction in the groups. The problems were so bad that Jennings came to refer to the system as the "fight-o-net".
As modems reached speeds of 28.8 kbit/s, the overhead of the TCP/IP protocols were no longer so egregious and dial-up Internet became increasingly common. By 1995 the bulletin board market was reeling as users abandoned local BBS systems in favour of larger sites and web pages, which could be accessed worldwide for the same cost as accessing a local BBS system. This also made FidoNet less expensive to implement, because inter-net transfers could be delivered over the Internet as well, at little or no marginal cost. But this seriously diluted the entire purpose of the store-and-forward model, which had been built up specifically to address a long-distance problem that no longer existed.
The FidoNet nodelist started shrinking, especially in areas with widespread availability of internet connections. This downward trend continues, but has levelled out at approximately 2,500 nodes.[N 4] FidoNet remains popular in areas where Internet access is difficult to come by, or expensive.
There is now (~2014) a retro movement which is resulting in a slow increase in internet connected BBS and nodes. Telnet, Rlogin, and SSH are being used between systems. This means you can telnet to many BBS worldwide as cheaply as ones next door. Also Usenet and internet mail has been added, along with long file names to many newer versions of BBS software, some being free-ware, resulting in increasing use. The deaf and blind are also able to access this better than the internet as a whole as interfaces for them deal mostly with ASCII text which exists in most BBS. They find it helps them communicate without the complications of pictures and audio in their internet mail and communication in general. Nodelists are no longer declining in all cases.
FidoNet is governed in a hierarchical structure according to FidoNet policy, with designated coordinators at each level to manage the administration of FidoNet nodes and resolve disputes between members. Network coordinators are responsible for managing the individual nodes within their area, usually a city or similar sized area. Regional coordinators are responsible for managing the administration of the network coordinators within their region, typically the size of a state, or small country. Zone coordinators are responsible for managing the administration of all of the regions within their zone. The world is divided into six zones, the coordinators of which elect one of themselves to be the International Coordinator of FidoNet.
The FidoNet system officially referred only to transfer of Netmail—the individual private messages between people using bulletin boards—including the protocols and standards with which to support it. A netmail message would contain the name of the person sending, the name of the intended recipient, and the respective FidoNet addresses of each. The FidoNet system was responsible for routing the message from one system to the other (details below), with the bulletin board software on each end being responsible for ensuring that only the intended recipient could read it. Due to the hobbyist nature of the network, any privacy between sender and recipient was only the result of politeness from the owners of the FidoNet systems involved in the mail's transfer. It was common, however, for system operators to reserve the right to review the content of mail that passed through their system.
Netmail allowed for the attachment of a single file to every message. This led to a series of piggyback protocols that built additional features onto FidoNet by passing information back and forth as file attachments. These included the automated distribution of files, and transmission of data for inter-BBS games.
By far the most commonly used of these piggyback protocols was Echomail, public discussions similar to Usenet newsgroups in nature. Echomail was supported by a variety of software that collected up new messages from the local BBSes' public forums (the scanner), compressed it using ARC or ZIP, attached the resulting archive to a Netmail message, and sent that message to a selected system. On receiving such a message, identified because it was addressed to a particular user, the reverse process was used to extract the messages, and a tosser put them back into the new system's forums.
Echomail was so popular that for many users, Echomail was the FidoNet. Private person-to-person Netmail was relatively rare.
FidoNet is politically organized into a tree structure, with different parts of the tree electing their respective coordinators. The FidoNet hierarchy consists of zones, regions, networks, nodes and points broken down more-or-less geographically.
The highest level is the zone, which is largely continent-based:
Each zone is broken down into regions, which are broken down into nets, which consist of individual nodes. Zones 7-4095 are used for othernets; groupings of nodes which use Fido-compatible software to carry their own independent message areas without being in any way controlled by FidoNet's political structure. Using un-used zone numbers would ensure that each network would have a unique set of addresses, avoiding potential routing conflicts and ambiguities for systems that belonged to more than one network.
FidoNet addresses explicitly consist of a zone number, a network number (or region number), and a node number. They are written in the form Zone:Network/Node. The FidoNet structure also allows for semantic designation of region, host, and hub status for particular nodes, but this status is not directly indicated by the main address.
For example, consider a node located in Tulsa, Oklahoma, United States with an assigned node number is 918, located in Zone 1 (North America), Region 19, and Network 170. The full FidoNet address for this system would be 1:170/918. The region was used for administrative purposes, and was only part of the address if the node was listed directly underneath the Regional Coordinator, rather than one of the networks that were used to divide the region further.
FidoNet policy requires that each FidoNet system maintain a nodelist of every other member system. Information on each node includes the name of the system or BBS, the name of the node operator, the geographic location, the telephone number, and software capabilities. The nodelist is updated weekly, to avoid unwanted calls to nodes that had shut down, with their phone numbers possibly having been reassigned for voice use by the respective telephone company.
To accomplish regular updates, coordinators of each network maintain the list of systems in their local areas. The lists are forwarded back to the International Coordinator via automated systems on a regular basis. The International Coordinator would then compile a new nodelist, and generate the list of changes (nodediff) to be distributed for node operators to apply to their existing nodelist.
In a theoretical situation, a node would normally forward messages to a hub. The hub, acting as a distribution point for mail, might then send the message to the Net Coordinator. From there it may be sent through a Regional Coordinator, or to some other system specifically set up for the function. Mail to other zones might be sent through a Zone Gate.
For example, a FidoNet message might follow the path:
Originally there was no specific relationship between network numbers and the regions they reside in. In some areas of FidoNet, most notably in Zone 2, the relationship between region number and network number are entwined. For example, 2:201/329 is in Net 201 which is in Region 20 while 2:2410/330 is in Net 2410 which is in Region 24. Zone 2 also relates the node number to the hub number if the network is large enough to contain any hubs. This effect may be seen in the nodelist by looking at the structure of Net 2410 where node 2:2410/330 is listed under Hub 300. This is not the case in other zones.
In Zone 1, things are much different. Zone 1 was the starting point and when Zones and Regions were formed, the existing nets were divided up regionally with no set formula. The only consideration taken was where they were located geographically in respect to the region's mapped outline. As net numbers got added, the following formula was used.
Region number × 20
Then when some regions started running out of network numbers, the following was also used.
Region number × 200
Region 19, for instance, contains nets 380-399 and 3800-3999 in addition to those that were in Region 19 when it was formed.
Part of the objective behind the formation of local nets was to implement cost reduction plans by which all messages would be sent to one or more hubs or hosts in compressed form (ARC was nominally standard, but PKZIP is universally supported); one toll call could then be made during off-peak hours to exchange entire message-filled archives with an out-of-town uplink for further redistribution.
In practice, the FidoNet structure allows for any node to connect directly to any other, and node operators would sometimes form their own toll-calling arrangements on an ad-hoc basis, allowing for a balance between collective cost saving and timely delivery. For instance, if one node operator in a network offered to make regular toll calls to a particular system elsewhere, other operators might arrange to forward all of their mail destined for the remote system, and those near it, to the local volunteer. Operators within individual networks would sometimes have cost-sharing arrangements, but it was also common for people to volunteer to pay for regular toll calls either out of generosity, or to build their status in the community.
This ad-hoc system was particularly popular with networks that were built on top of FidoNet. Echomail, for instance, often involved relatively large file transfers due to its popularity. If official FidoNet distributors refused to transfer Echomail due to additional toll charges, other node operators would sometimes volunteer. In such cases, Echomail messages would be routed to the volunteers' systems instead.
The FidoNet system was best adapted to an environment in which local telephone service was inexpensive and long-distance calls (or intercity data transfer via packet-switched networks) costly. Therefore, it fared somewhat poorly in Japan, where even local lines are expensive, or in France, where tolls on local calls and competition with Minitel or other data networks limited its growth.
As the number of messages in Echomail grew over time, it became very difficult for users to keep up with the volume while logged into their local BBS. Points were introduced to address this, allowing technically savvy users to receive the already compressed and batched Echomail (and Netmail) and read it locally on their own machines.
To do this, the FidoNet addressing scheme was extended with the addition of a final address segment, the point number. For instance, a user on the example system above might be given point number 10, and thus could be sent mail at the address 1:170/918.10.
In real-world use, points are fairly difficult to set up. The FidoNet software typically consisted of a number of small utility programs run by manually edited scripts that required some level of technical ability. Reading and editing the mail required either a "sysop editor" program, or a BBS program to be run locally.
In North America (Zone 1), where local calls are generally free, the benefits of the system were offset by its complexity. Points were used only briefly, and even then only to a limited degree. Dedicated offline mail reader programs such as Blue Wave, Squiggy and Silver Xpress (OPX) were introduced in the mid-1990s, and quickly rendered the point system obsolete. Many of these packages supported the QWK offline mail standard.
In other parts of the world, especially Europe, this was different. In Europe, even local calls are generally metered, so there was a strong incentive to keep the duration of the calls as short as possible. Point software employs standard compression (ZIP, ARJ, etc.) and so keeps the calls down to a few minutes a day at most. In contrast to North America, pointing saw rapid and fairly widespread uptake in Europe.
Many regions distribute a pointlist in parallel with the nodelist. The pointlist segments are maintained by Net- and Region Pointlist Keepers and the Zone Point List Keeper assembles them into the Zone pointlist. At the peak of FidoNet there were over 120,000 points listed in the Zone 2 pointlist. Listing points is on a voluntary basis and not every point is listed, so how many points there really were is anybody's guess. As of June 2006, there are still some 50,000 listed points. Most of them are in Russia and Ukraine.
FidoNet contained several technical specifications for compatibility between systems. The most basic of all is FTS-0001, with which all FidoNet systems are required to comply as a minimal requirement. FTS-0001 defined:
Other specifications that were commonly used provided for echomail, different transfer protocols and handshake methods (e.g.: Yoohoo/Yoohoo2u2, EMSI), file compression, nodelist format, transfer over reliable connections such as the Internet (Binkp), and other aspects.
Since computer bulletin boards historically used the same telephone lines for transferring mail as were used for dial-in human users of the BBS, FidoNet policy dictates that at least one designated line of each FidoNet node must be available for accepting mail from other FidoNet nodes during a particular hour of each day.
Zone Mail Hour, as it was named, varies depending on the geographic location of the node, and was designated to occur during the early morning. The exact hour varies depending on the time zone, and any node with only one telephone line is required to reject human callers. In practice, particularly in later times, most FidoNet systems tend to accept mail at any time of day when the phone line is not busy, usually during night.
Most FidoNet deployments were designed in a modular fashion. A typical deployment would involve several applications that would communicate through shared files and directories, and switch between each other through carefully designed scripts or batch files. However, monolithic software that encompassed all required functions in one package is available, such as D'Bridge. Such software eliminated the need for custom batch files and is tightly integrated in operation. The preference of deployment was that of the operator and there were both pros and cons of running in either fashion.
Arguably the most important piece of software on a DOS-based Fido system was the FOSSIL driver, which was a small device driver which provided a standard way for the Fido software to talk to the modem. This driver needed to be loaded before any Fido software would work. An efficient FOSSIL driver meant faster, more reliable connections.
Mailer software was responsible for transferring files and messages between systems, as well as passing control to other applications, such as the BBS software, at appropriate times. The mailer would initially answer the phone and, if necessary, deal with incoming mail via FidoNet transfer protocols. If the mailer answered the phone and a human caller was detected rather than other mailer software, the mailer would exit, and pass control to the BBS software, which would then initialise for interaction with the user. When outgoing mail was waiting on the local system, the mailer software would attempt to send it from time to time by dialing and connecting to other systems who would accept and route the mail further. Due to the costs of toll calls which often varied between peak and off-peak times, mailer software would usually allow its operator to configure the optimal times in which to attempt to send mail to other systems.
BBS software was used to interact with human callers to the system. BBS software would allow dial-in users to use the system's message bases and write mail to others, locally or on other BBSes. Mail directed to other BBSes would later be routed and sent by the mailer, usually after the user had finished using the system. Many BBSes also allowed users to exchange files, play games, and interact with other users in a variety of ways (i.e.: node to node chat).
A scanner/tosser application, such as FastEcho, FMail, TosScan and Squish, would normally be invoked when a BBS user had entered a new FidoNet message that needed to be sent, or when a mailer had received new mail to be imported into the local messages bases. This application would be responsible for handling the packaging of incoming and outgoing mail, moving it between the local system's message bases and the mailer's inbound and outbound directories. The scanner/tosser application would generally be responsible for basic routing information, determining which systems to forward mail to.
In later times, message readers or editors that were independent of BBS software were also developed. Often the System Operator of a particular BBS would use a devoted message reader, rather than the BBS software itself, to read and write FidoNet and related messages. One of the most popular editors in 2008 was GoldED+. In some cases FidoNet nodes, or more often FidoNet points, had no public bulletin board attached, and existed only for the transfer of mail for the benefit of the node's operator. Most nodes in 2009 had no BBS access, but only points, if anything.
The original Fido BBS software, and some other FidoNet-supporting software from the 1980s, is no longer functional on modern systems. This is for several reasons, including problems related to the Y2K bug. In some cases, the original authors have left the BBS or shareware community, and the software, much of which was closed source, has been rendered abandonware.
Several DOS based legacy FidoNet Mailers such as FrontDoor, Intermail, MainDoor and D'Bridge from the early 1990s can still be run today under Windows without a modem, by using the freeware NetFoss Telnet FOSSIL driver, and by using a Virtual Modem such as NetSerial. This allows the mailer to dial an IP address or hostname via Telnet, rather than dialing a real POTS phone number. There are similar solutions for Linux such as MODEMU (modem emulator) which has limited success when combined with DOSEMU (DOS emulator). Mail Tossers such as FastEcho and FMail are still used today under both Windows and Linux/DOSEMU.
There are several modern Windows based FidoNet Mailers available today with source code, including Argus, Radius, and Taurus. MainDoor is another Windows based Fidonet mailer, which also can be run using either a modem or directly over TCP/IP. Two popular free and open source software FidoNet mailers for Unix-like systems are the binkd (cross-platform, IP-only, uses the binkp protocol) and qico (supports modem communication as well as the IP protocol of ifcico and binkp).
On the hardware side, Fido systems were usually well-equipped machines, for their day, with quick CPUs, high-speed modems and 16550 UARTs, which were at the time an upgrade. As a Fidonet system was usually a BBS, it needed to quickly process any new mail events before returning to its 'waiting for call' state. In addition, the BBS itself usually necessitated lots of storage space. Finally, a FidoNet system usually had at least one dedicated phoneline. Consequently, operating a Fidonet system often required significant financial investment, a cost usually met by the owner of the system.
While the use of FidoNet has dropped dramatically compared with its use up to the mid-1990s, it is still used in many countries and especially Russia and former republics of the USSR. Some BBSes, including those that are now available for users with Internet connections via telnet, also retain their FidoNet netmail and echomail feeds.
Some of FidoNet's echomail conferences are available via gateways with the Usenet news hierarchy using software like UFGate. There are also mail gates for exchanging messages between Internet and FidoNet. Widespread net abuse and e-mail spam on the Internet side has caused some gateways (such as the former 1:1/31 IEEE fidonet.org gateway) to become unusable or cease operation entirely.
FidoNews is the newsletter of the FidoNet community. Affectionately nicknamed The Snooze, it is published weekly. It was first published in 1984. Throughout its history, it has been published by various people and entities, including the short-lived International FidoNet Association.
With sadness I have removed the last entry for Zone6 as of this writing. All remaining members have been transitioned to Zone3 as previously determined by Z6 members at large.
The Advanced Video Attribute Terminal Assembler and Recreator (AVATAR) protocol is a system of escape sequences occasionally used on bulletin board systems (BBSes). Its basic level was designed explicitly as a compression of the much longer ANSI escape codes, and can thus render colored text and artwork faster over slow connections. Even when the terminal didn't understand it, the data on disk could use the AVATAR format and so take up less space. Note: A much more comprehensive protocol was proposed, but never gained much support.
The basic protocol is defined by FidoNet technical standard proposal FSC-0025.Avatar was later extended in late 1989 to AVT/0 (sometimes referred to as AVT/0+) which included facilities to scroll areas of the screen (useful for split screen chat, or full screen mail writing programs), as well as more advanced pattern compression. These extensions were not convertible directly into sequences understood by existing ANSI terminals but instead mirrored extra facilities available in the IBM PC BIOS.
Avatar was originally implemented in the Opus BBS, but later popularised by RemoteAccess. RemoteAccess came with a utility, AVTCONV that allowed for easy translation of ANSI documents into Avatar helping its adoption.Binkp
binkp is a protocol for transferring FidoNet or WWIVNet mail over reliable connections. It is typically used to deliver mail over the internet, instead of point-to-point connections between modems.Bulletin board system
A Bulletin Board System or BBS (once called Computer Bulletin Board Service, CBBS) is a computer server running software that allows users to connect to the system using a terminal program. Once logged in, the user can perform functions such as uploading and downloading software and data, reading news and bulletins, and exchanging messages with other users through public message boards and sometimes via direct chatting. In the early 1980s, message networks such as FidoNet sprung up to provide services such as NetMail, which is similar to email.
Many BBSes also offer online games in which users can compete with each other. BBSes with multiple phone lines often provide chat rooms, allowing users to interact with each other. Bulletin board systems were in many ways a precursor to the modern form of the World Wide Web, social networks, and other aspects of the Internet. Low-cost, high-performance modems drove the use of online services and BBSes through the early 1990s. Infoworld estimated that there were 60,000 BBSes serving 17 million users in the United States alone in 1994, a collective market much larger than major online services such as CompuServe.
The introduction of inexpensive dial-up internet service and the Mosaic web browser offered ease of use and global access that BBS and online systems did not provide, and led to a rapid crash in the market starting in 1994. Over the next year, many of the leading BBS software providers went bankrupt and tens of thousands of BBSes disappeared. Today, BBSing survives largely as a nostalgic hobby in most parts of the world, but it is still an extremely popular form of communication for Taiwanese youth (see PTT Bulletin Board System). Most surviving BBSes are accessible over Telnet and typically offer free email accounts, FTP services, IRC and all the protocols commonly used on the Internet. Some offer access through packet switched networks or packet radio connections.Disk Masher System
The Disk Masher System (.dms) is an often used method on the Amiga, to create a compressed image of a disk (usually floppy). The disk is read block-by-block, and thus its data structure is maintained. DMS won approval particularly in the demo scene and the Warez scene, since with this tool, disk images could generally be transferred easily with telecommunication modems to mailbox networks like FidoNet for efficient distribution.The DiskMasher format is copyright-protected and has problems storing particular bit sequences due to bugs in the compression algorithm, but was widely used in the pirate and demo scenes. To avoid these issues, a number of other disk compressors were developed that used alternative disk reading and compression methods, for instance, xDM or XAD (software).FOSSIL
FOSSIL is a standard protocol for allowing serial communication for telecommunications programs under the DOS operating system. FOSSIL is an acronym for Fido Opus SEAdog Standard Interface Layer. Fido refers to FidoBBS, Opus refers to Opus-CBCS BBS, and SEAdog refers to a Fidonet compatible mailer. The standards document that defines the FOSSIL protocol is maintained by the Fidonet Technical Standards Committee.FastEcho
FastEcho is a message processing package for FTN (FidoNet Technology Network) mail systems. It was written and released as shareware by Tobias Burchhardt in 1991. The final version was 1.46.1 which was released in 1997. FastEcho was one of the fastest FTN mail processing packages available for FTN style messages. Running on MS-DOS, DPMI and native OS/2 32bit, it offered numerous features that were desirable for leafnode systems as well as highend FTN mail distribution hubs.FrontDoor
FrontDoor was one of the most popular mailers in the FidoNet-compatible networks in the 1990s acting as the physical representation of the written network node connection and mail handling standards. It was an MS-DOS-based product (also available as shareware) written by Joaquim Homrighausen (alias JoHo). The FrontDoor system contained a Mailer, an Editor, a Terminal, a serial port device driver and configuration utilities. FrontDoor was first released in 1986. The task of mailers, the main task of the first FrontDoor release, was to accept a phone call for a BBS / FidoNet node system; differentiating between human and machine calls (sending the humans to the BBS while handling all other cases) and if the other end supported the same protocol started a conversation about handling whatever packets had to be exchanged, and calling external programs to handle the traffic.
Originally FrontDoor was a small utility to handle incoming calls, written in 1986. Peter Adenauer of AMS Applied Micro Systems, Inc. of Miami, Florida asked Homrighausen in 1987 to leave his job at Ericsson and come to the USA and start developing a commercial product based on FrontDoor with Peter Stewart. After several adventurous clashes between the programmers and the company and realising that there wasn't a useful product even after a long development the people parted: Homrighausen went to Australia with the version 1.99c source code while Stewart got the same code which has been used as the basis of InterMail software.FrontDoor continued its life as shareware as well as a commercial product; the current versions are 2.26 (DOS+OS/2 shareware) and 2.32.mL (DOS+OS/2 multiline commercial). Joaquim Homrighausen attempted a "revival" of sorts of the project in 2014, but was prevented from continuing due to rehab from an injury. In August 2017, he once again began reviving the product, some 30+ years after the first release. As of September 2017, it is still unclear as to which platforms the re-booted FrontDoor project will run on.GoldED
GoldED was a popular message editor for FidoNet-compatible computer networks.
In 1998, Odinn Sørensen released the source code of GoldED and Goldware Utilities 3.x under GNU General Public License version 2, and the Goldware Library under GNU Library General Public License version 2. A permission has also been given to link that all with software conforming with the Open Source Definition.
The code of one of the libraries used by GoldED and GoldED+, CXL, has been licensed by Sørensen from its author, Mike Smedley. Since then the copyright has been taken over by “Innovative Data Concepts”, which, as Sørensen suspected in 1998, has disappeared. This was one of the reasons for removing the goldedplus package from Debian repositories in 2006.By 1999, all the developers of GoldED left FidoNet.JAM Message Base Format
The JAM Message Base Format was one of the most popular file formats of message bases on DOS-based BBSes in the 1990s. JAM stands for "Joaquim-Andrew-Mats" after the original authors of the API, Joaquim Homrighausen, Andrew Milner, Mats Birch, and Mats Wallin. Joaquim was the author of FrontDoor, a DOS-based FidoNet-compatible mailer. Andrew was the author of RemoteAccess, a popular DOS-based Bulletin Board System. JAM was originally released in 1993 in C, however the most popular implementation was Mark May's "MK Source for Msg Access" written in Pascal which also saw its initial release in 1993.Kashchenism
Kashchenism (Russian: Кащенизм) is a specific style of conversation in forums and blogs used on Russian FidoNet and Internet. Its main feature is provocativeness and mockery while being formally polite. Historically, Kashchenist style uses many words and idioms of Jewish origin; in conversations, Kashchenists often pretend to be Jews, in order to troll antisemites while also causing others to make excuses to prove that they are not antisemites. Kashchenist style also typically uses medical terms, especially from psychiatry; this is because Kashchenists consider themselves jocularly as "network psychiatrists", and imitate either medical staff or, conversely, patients in a mental hospital. The word "Kashchenism" also denotes a philosophy of people who use Kashchenist style in electronic conversations.Neighbornode
Neighbornode is a captive portal on a residential Wi-Fi hotspot, containing a message board. It is designed to help neighbors who share an internet connection know each other better.The message board can only be accessed within range of the hotspot. Individual Neighbornodes can be linked together to create a supernode, vaguely like Fidonet. It is implemented as an alternative firmware for the Linksys WRT54G router.
The project was created by John Geraci of Interactive Telecommunications Program, who also created Grafedia.Pablo Kleinman
Pablo Kleinman (born 1971) is an Argentine-born American entrepreneur and journalist, pioneer of the development of online services in Latin America. He graduated from the University of Southern California School of International Relations (USC, Los Angeles) and went on to study at the London Business School and at the HEC School of Management in Paris, where he obtained an MBA.RelayNet
RelayNet was an e-mail exchange network used by PCBoard bulletin board systems (BBS's). By 1990, RelayNet comprised more than 200 bulletin board systems.BBS's on RelayNet communicated via a communications protocol called RIME (RelayNet International Mail Exchange).
RelayNet was similar to FidoNet in purpose and technology, although it used names for its nodes instead of Fido's numeric address pairs. Due to it being limited to PCBoard, it carried a much smaller amount of traffic than Fido. RIME was built up, starting in 1988, from a master hub owned by Bonnie Anthony, a local Psychiatrist, in Bethesda, Maryland and a subordinate hub owned by her brother, Howard Belasco, in The Bronx, New York. Kip Compton, in high-school at the time, played an important role in the software's development and evolution.
PCBoard, created by Clark Development Corporation (CDC) in Salt Lake City, Utah, was always a "premium" BBS system and fairly expensive. For this reason it was limited mostly to larger multi-line BBS systems, where it was particularly well liked due to its "nice" behaviour on the network when running off a common file server. However this also meant that the PCBoard market generally consisted of a small number of large systems, as opposed to a large number of small ones, hence RIME had usually only a few hundred member boards.
Thus RelayNet, which originally ran only on PCBoard, did not have the same level of infrastructure as FidoNet, and didn't build the sort of global organizational structure that FidoNet needed. Instead, RelayNet evolved as a series of smaller regional networks, including the NANET hosted by Canada Remote Systems, RoseNet hosted by their competitors Rose Media, QuebecNet, FINET, Smartnet, Intelec, Ilink, U'NI-net, Friendsnet and others.
RelayNet software later appeared for a variety of other BBS systems, including RBBS, GAP, EIS, QBBS and Wildcat! BBS, but these systems also provided excellent FidoNet support and RelayNet was never popular on anything other than PCBoard and its close competitor, RBBS-PC.
On August 1, 2007, Don Barba, owner since the late 1990s of the RIME network, its software, and since the late 1980s of Moondog, its central BBS in Brooklyn, New York, announced that all would close on August 15.RemoteAccess
RemoteAccess is a DOS Bulletin Board System (BBS) software package written by Andrew Milner and published by his company Wantree Development in Australia. RemoteAccess was written in Turbo Pascal with some Assembly Language routines. RemoteAccess (commonly called RA) began in 1989 as a clone of QuickBBS by Adam Hudson. RemoteAccess was released under the shareware concept in 1990 and became popular in North America, Europe, UK, South Africa, and the South Pacific. Initially the main advantage over QuickBBS was its ability to run multiple nodes under Microsoft Windows, Quarterdeck's DESQview and OS/2. RA could also operate over a network or even a combination of network and multitasking operating systems to provide multiple "nodes per station" capabilities.
RA's features quickly grew to become considerably more advanced than the QuickBBS software it was cloned after. A number of other QuickBBS clones appeared shortly afterwards including ProBoard, SuperBBS and EzyCom, though they never gained as much support or popularity. RA was the first BBS software to support the popular JAM Message Base Format, which was partly conceived by RA's author, Andrew Milner. RA was also the first shareware BBS software to support a FDB (file database), rather than using files.bbs text files to describe files in each directory. RA interfaced with message relaying systems such as FidoNet through 3rd party utilities such as FrontDoor (Joaquim Homrighausen) and FastEcho (Tobias Burchhardt), which were developed by people who eventually became members of the RA beta team.
With over 1500 titles, there were more third party utilities written for RA than for any other shareware BBS software. While RA was initially shareware, Andrew also released a commercial edition - "RemoteAccess Professional" - that was bundled with utilities to allow remote control of nodes over a network (RANETMGR, and RATSR).
Andrew Milner released his final version of RA (2.50) in May 1996. By that time, many System Operators switched over from running Bulletin Boards to becoming Internet Service Providers. Milner was one such System Operator, and after version 2.50 he stopped development. In April 1997, Milner put the rights and source code up for sale to the highest bidder and it was sold in December 1997 to Bruce Morse in the USA. Morse released some minor updates including a Y2K fix, but did not add any new features to the code. Morse's final version (2.62) was released in August 2000. Bruce Morse continues to own the code today and RA is still available as shareware, as well as a commercial version known as RemoteAccess-Professional.
RemoteAccess was never ported to a 32-bit version, but there were two clones of RA in the later years which did include 32-bit versions: EleBBS in the late 1990s which included DOS, Windows, OS/2 and Linux flavors, and MBSE, a few years later, which focused mainly on the Linux operating system.
There were numerous conversations about creating Windows and OS/2 32-bit versions of RA around 1995. Joel Ricketts of Interscape Development, who was the lead programmer, answered questions in the RA echomail forum about the potential development of RA for Windows during this time. However, due to RA being put up for sale, as well as lack of funding, the project was scrapped in 1996.
Around the same time, Niels Schoot from the Netherlands began writing a Visual Basic version of RA called tcRA32, which was to be fully RA compatible. The project was never finished, and within a couple of years, it was abandoned.
While RemoteAccess never included internal telnet support, it can be run as a telnet BBS by using a telnet-FOSSIL driver such as NetFoss, or a Virtual COM port engine such as NetSerial under Windows, or using SIO/VMODEM under OS/2.Signature block
A signature block (often abbreviated as signature, sig block, sig file, .sig, dot sig, siggy, or just sig) is a block of text automatically appended at the bottom of an email message, Usenet article, or forum post.Store and forward
Store and forward is a telecommunications technique in which information is sent to an intermediate station where it is kept and sent at a later time to the final destination or to another intermediate station. The intermediate station, or node in a networking context, verifies the integrity of the message before forwarding it. In general, this technique is used in networks with intermittent connectivity, especially in the wilderness or environments requiring high mobility. It may also be preferable in situations when there are long delays in transmission and variable and high error rates, or if a direct, end-to-end connection is not available.Tom Jennings
Tom Jennings (born 1955 as Thomas Daniel Jennings in Boston, Massachusetts) is a Los Angeles-based artist and technician. He is the creator of FidoNet, the first message and file networking system for BBSes. Originally, the FidoNet protocols were implemented in a program named Fido, authored by Jennings, but they were ultimately implemented by other authors in other software to create a network using a multiplicity of platforms.
Aside from creating the most influential protocol for networking computer bulletin boards, Jennings built Wired magazine's first internet presence, wrote the portable BIOS that led to Phoenix Technologies BIOS, ran an early regional internet service provider, The Little Garden (later incorporated as TLGnet, Inc), and maintains an informal archive of Cold War science and technology.
While he lived in San Francisco, from 1988 until 1991 Jennings was the publisher and co-editor, with Deke Nihilson, of Homocore, one of the earliest Queercore zines. The name came from the pages of J.D.s zine, and featured musicians and writers such as The Apostles, Steve Abbott, Donna Dresch, Larry Livermore, Daniel Nicoletta and G.B. Jones. The editors' other activities, such as organizing Homocore shows where bands such as Fugazi and Beat Happening appeared, and writing for and creating other publications, were instrumental in popularizing the Queercore movement, particularly on the west coast. (Deke also performed in films, such as The Yo-Yo Gang, and had his own Queercore band Comrade in Arms.) Internationally, Homocore zine, throughout its eight (including the rarely seen issue #5-1/2) issues, along with J.D.s, was influential in the rise of Queercore as the zines found their way into the hands of queer punk kids across North America, South America and Europe.
Jennings currently resides in Los Angeles, California, with his partner Josh Stehlik. He is faculty at Calarts Art+Technology program, and also works as a technician at the University of California, Irvine's Arts Computation Engineering graduate program.WWIVnet
WWIVnet was a Bulletin board system (BBS) network for WWIV-based BBSes. It was created by Wayne Bell on December 1, 1987. The system was similar to FidoNet in purpose, but used a very different routing mechanism that was more automated and distributed.Wazoo
Wazoo may refer to:
The Grand Wazoo, 1972 album by Frank Zappa
Wazoo (album), 2007 live album by Frank Zappa
Wazoo (candy), candy bar made by Topps incorporated
WaZOO (Warp Zillion Opus-to-Opus), the session layer protocol for FidoNet
Wazoo Sports Network, a local sports channel serving Kentucky and southern Indiana