Future Messaging Proposal

John Dovey (BoonDock 4:92/1, 4:920/1) dovey.john@gmail.com

16 May 2021


I've loved online messaging and files for as long as it's been possible to do so, starting in the mid 1980s with dial-up bulletin board systems, moving to FidoNet shortly afterwards as first a point and then establishing my own board. I made the shift along with the rest of the world to Usenet and then Email. I established and started running an email list in the early 90s (still running in 2021) which iterated through all the various changes in that technology. And then cell phones arrived and at first SMS messages (which were free) then the various messaging apps, in fact writing one of the very first (called Sticky Notes) whose source was the inspiration and basis (from what I could determine) for ICQ. I dabbled with ISeeU (the first video conferencing app) and with Mixit, ICQ, QQ and a plethora of others. Currently on my phone I have WhatsApp, Signal, Telegram and a few more obscure ones.

I used Napster, MySpace and various Torrent clients.

I've used the online forums epitomized by phpBBS and all its variations. Not to mention Twitter, Facebook, Instagram and TikTok. This just to establish that I'm besotted with online communication and file sharing. I've investigated (and implemented to various degrees of success) different networks types, including "SneakerNet" and Mesh Networks.


A short while ago, I decided to start a BBS again as part of investigation into a distributed messaging and resource sharing project that I'm exploring together with a colleague living in the UK who works across rural Africa, in some of the most disconnected communities it's possible to imagine. My focus is on local communities in Panama who are almost as isolated.

I turned to BBS technology, together with FidoNet (FTN) and QWKnet primarily because it's got a few key features. The important ones for us are primarily;

  1. Availability of free software
  2. Software for almost any platform, including some of the oldest and simplest (DOS), as well as some of the most modern (RasberryPI).
  3. Ease and simplicity of setup and operation
  4. Simplicity of networking messages
  5. Anarchic by design ie not controlled by anyone
  6. Store and Forward operation.


I have evaluated a wide range of software and technology that is currently available and have come to some conclusions

  1. There are a few stand-out pieces of software and some incredible people involved in this world. They do this as a passion and contribute their expertise and tone without any more recompense then the acknowledgment that they receive. My thanks for out to them, because as always, we stand on the shoulder of giants.

The current iteration of BBS systems is pretty much dominated by Synchronet and Mystic. There are a variety of others, lots of older ones which have been resurrected and some brand new ones (Talisman for example) which are newly written.

The vast majority of the Internet aware BBS software and traffic though is based on Rob Swindell's work, with even Talisman using parts of it to fill in the gaps. There are also numerous older programs and utilities which are either still going strong or being used in the original form, such as BinkD, MultiMail, various versions of Fossil drivers, the SEXYZ communications app, various tossers and mailers and bridges and front doors and nodelist compilers and a variety of each as well as others.

What underlies all these disparate pieces of software is a series of old ideas. Some really good principles and realization of those principles and some things which just aren't in tune with the modern way of doing things.

The most glaring omission is a simple app for Android or IOS. There are "point" systems (such as GoldEd+) and the configurations that they require, but they are at best clunky and difficult.


First Principles

I believe that the requirements and usage for the majority of people has shifted. This is why we see a fairly large number of BBS systems with a potentially almost infinite number of "nodes" to handle traffic, and yet the majority of the traffic on the discussion lists (Exho Boards) is test traffic to the test echo, political wrangling and cooking recipes. The other echos that gain traffic are the adverts for boards and the automatic announcements of new files, primarily files related to running BBSes such as Nodelists and statistics. There are very few actual users.

We've seen a proliferation of messaging applications or groups over the past few years, but BBS and Fido can't seem to attract more than a few thousand people. That should tell us something needs to be different.

If you delve into the history of FidoNet there are two things I'd like to highlight about why and how it arose in the way it did and relate that to some of the important factors that we are seeing at play right now.

The first one was that Rob Jennings, who invented FidoNet practically single-handedly, designed it intentionally to be anarchistic. As is normal, when it Gee it developed what looks at first glance very much like a hierarchical structure and a central controlling body. This is because of old limitations, the benefit of consolidating messages to save on long-distance phone calls, and simple human nature. The first condition is simply jot there any more. Out of the entire list of nodes on the latest nodelists, there is a bare handful which advertise an actual phone number. The second will always be with us, and has to also be taken into account.

The second factor is that if the monolithic centralized services which provide the various messaging systems in use today; from Twitter to WhatsApp and everything else in between. They have arisen as commercial purveyors of other peoples information and treat their customers as the product. From my reading and experience I suspect that it was an almost prescient vision which formulated the concept of FidoNet; one truly before it's time.


In my opinion, FidoNet at its core is a store-and-forward system which was meant to resilient and flexible enough to route around outages and breakdowns and unreliable links. The first nodelist could apparently jot handle more than 250 nodes, and the zone/net/hub/node system arose almost as a kludge to handle the growth to over 19000 entries in the nodelist at its peak.

When I established my newest board, I was invited to join my local zone and facilitate the local region, with the assumption that all my traffic would, as is traditional, route through the region to the Zone hub and then onto the "backbone". As I proceeded to set this up, I found it completely trivial to add feeds to and from Europe, Russia and New Zealand for conferences carried there and not within my Zone. I could also have picked up all my conferences from one of those and simply ignore everyone else in my Zone. I thought that was a little ride though. It is only tradition that restricted me to using the normal routing.

So to summarize;

  1. Anarchic (no central authority)
  2. Store and forward (handle unreliable or sporadic connections)
  3. Robust and flexible routing (based on available links, not on arbitrarily decided hierarchical structures)

And I'd like to add

  1. Total user selection of what they want to see, and technical decisions where and how it is routed.

Some tentative suggestions

I'm not truly an expert in all of this stuff, more a generalist and an enthusiastic amateur, so please take that into consideration.

What I believe is imperative is that the barrier to entry needs to be lowered drastically. It should be as simple as clicking on a download button and filling in a few fields.

We need to think in terms of Mesh networking, not some sort of star topology mindset. I'm not necessarily talking about the transport layer, but the arrangement of the network. By this I mean that someone should choose to join the network and connect automatically to peers. These could be geographically distant but close in network terms or vice versa. To illustrate what I mean, my next point is that we need to be agnostic about the transfer layer. It is trite to say that the ubiquitous nature of TCP/IP will most probably dominate for a long time, but consider this scenario.

Scenario 1

There is a remote village, physically distant from any network connection whatsoever. There are no phone lines, no satellite links, no cell towers not for fifty miles in any direction.

One person in that village has an android device of some sort (phone tablet or whatever). That person gets to go into the local town once a week. When they get there, they connect their device to the network. The software on their device then sends and receives all the packets waiting on the queue. Something like Bink does now.

When this person gets back to the village, his next door neighbor connects to his android device from his phone using Bluetooth, and swaps Mail. He will have a week to read and reply before connecting again before the next trip. Another person from the village in the next valley visits the next day. He does the same before returning to his village to continue the process.

Maybe at the third village in the chain, there is someone else who takes a trip to get connected and passed on the nail that's accumulated. (That's a routing complication of course but not insurmountable).

The point of this scenario is to illustrate that the current concept of dialup BBS (now shifted to Telnet et al) is in some ways a shift away from the roots of FidoNet. This disconnected store and forward model is what the network was designed for.

More Proposals and thoughts

My proposal is that we need to look for a different network authentication and routing model. One that handles the instant connectivity just well as it does the completely irregular and unreliable links.

We need to return to that.

I have numerous other thoughts, but I hope this is enough to generate some debate.

All the best BoonDock

PS: written in Markdown so you can choose to view a prettified version of you wish ;-)