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;
I have evaluated a wide range of software and technology that is currently available and have come to some conclusions
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.
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;
And I'd like to add
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.
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.
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.
It's also become clear that there is reason to be concerned about the platforms that provide the major communications at the moment. We've seen these platforms being used in places and at tokes where they've made an incredible difference, such as during the Arab Spring, the Hong Kong protests and then during various natural disasters etc. We've also seen them be cut off completely by governments or by the providers to whole communities or to individuals.
The anarchic nature of FidoNet was designed to prevent that. I'm also pretty convinced that when it was designed the initial intention of the Internet/DARPAnet played a part that is to survive a nuclear attack.
We need to return to that.
One of the largest concerns people have expressed is worry over "encryption". What they truly mean is not encryption per se, but privacy. That, in my opinion, shouldn't be part of the network but a software layer on top. PGP comes to mind as a good model. Building that in to clients should be a best practice and part of the standard.
It seems that most people establish a BBS primarily for their own use. That is that they are the primary user, and additional users are pretty sparse. It's for this reason (and others) that I'd suggest that the focus should be catering for this. There is of course a reason to have "community activities", but no reason why they need to be hosted by a central server. They could be collaborative efforts arranged on the fly.
I do believe that there will be some central nodes. There is a certain pleasure is running a BBBs and facilitating the various services, and that should be as easy to accomplish as possible of course.
The whole concept of the nodelist is archaic. Once a user or system has Registerd themselves on the app, there should be an automated process where it announces them to the network at large and where the information gets collated via a distributed database of some sort. The SBBS BBS list is an example of one way of doing this. A UDP packet once a day to announce the node and one every "tick" minutes with the nodes status might work. With auto discovery of "backbone nodes" that will collate and redistribute that information.
The various message formats are archaic and ridiculous in a lot of ways. There should be a standard implementation that is accessible on all devices. My personal preference would be for SQLite due to it's ease of use and ubiquitous distribution (how many billions of android and iOS devices have it Pre-installed?)
The display format! ANSI for crying out loud! Surely we can do better than that? Why about send SVG commands which are rendered on the device? Maybe using the Cairo graphics libraries or their equivalent? I know RIPTerm was an early. Semi-proprietary version of this. Maybe it's time to develop a new standard which is simple and easy to implement? It beggars belief that we are using software that is actually designed with VT100 terminals in mind.
Having said this, nothing prevents us from separating the display layer from the transmission layer. If we design the protocol sufficiently well, then that could also be relatively agnostic, or at least provide fallback options. For example, negotiation with the client with "new RIP" preferred, falling back to in descending order, Rendered SVG, PNG, HTML, ANSI and ASCII.
Telnet. Ask anyone under thirty who is not in IT to use telnet and you may as well have spoken in a foreign language.
Composing messages. Make it something like Markdown so it's also agnostic and the formatting is deferred to the client.
Images. There aren't any. This is probably the biggest reason for the poor uptake after the lack of clients for devices. I'd suggest though that rather than duplicate http for this, and find ourselves with a poor man's version of the web, we think very carefully about how to implement the display of images, possibly making them "out of band". Something like "progressive jpgs" which render independently of the message and maybe even a send them using UDP so that they aren't dependent on the message. Images and video etc are, of course, big attractions to users (just look at the growth of Instagram and TikTok) but they can kill everything else. They're also bandwidth hogs. I think this is where the "control by the user" needs to be rigorously built in, there is a simple and enforceable way to select where and how images are accepted.
Spam. Spam kills message board and conferences if not killed instantly. That's why there must be some mechanism to deal with it. Maybe ...
Reputation. While I believe that at least in some areas it's important to have anonymity, at the same time there are some things that need to be controlled/ prevented. These include things like adult content, spam etc. I think that it should be possible to generate some way of figuring this out. One possibility could be a sort of "reputation" setting. This could have many variations but for example, if you're reputation is low (or your rank is 'Noob'), there are only certain things you can do, or certain conferences you can join. The longer you are part of the system, the more you participate in certain activities etc, the more tour reputation/rank can change. If, for example, no messages are accepted from noobs, then the hit-and-run spammers who use images won't be able to generate new user IDs to post them. If there is an algorithm that sees a user posting the same content hundreds of times, or hundreds of messages from the same address, or other variations on the theme, then they can be flagged as potentially spammers and handled programmatically. I believe this is vital however, that it be programmed in and that the rules are enforced programmatically and not by people, as it's less prone to all sorts of nonsense we see on existing platforms. What's important is that if someone wants all those adverts for penis enlargement by that "doctor" from Nigeria, then there's nothing to stop him ignoring the flags and accepting those messages, but also nothing stopping all the other nodes from both refusing to accept them as well as refusing to forward them on.
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 ;-)