I have asked for guest columns from those in the BBS Scene. Naveen Albert (author of a new software package called Lightweight BBS) has volunteered to write an article for BBS Corner.
Lightweight BBS (LBBS) is a new BBS software package written in C, entirely from the ground up. It’s designed to be modular, flexible, and lightweight – extremely fast to compile, install, and run. LBBS is easy to configure – there’s an INI-style configuration file for each piece of functionality, and you can configure and load the modules you want. LBBS is designed with the busy sysop in mind – it can automatically generate your menus for you dynamically, based on the user’s terminal properties: all you need to do is specify what commands should be available and to whom. LBBS also has a few esoteric features, such as emulated baud rate support (throttle connections to a specified bps), skip menu navigation (jump around the BBS quickly using shortcut commands), and TTY/TDD support (use your teletype with the BBS). New features and improvements are constantly being added to LBBS, so feel free to give it a spin and share how it works for you.
Q: Why you wrote it?
Partly because I wanted to, and partly because (I felt) I had to. Around 2018 or so, I started my own BBS and, in a classic case of “Not Invented Here”, cobbled together my own “BBS” using several shell scripts linked together, rather than using a “proper” BBS package as most people do. But for me, the journey really was the destination and I wanted to be intimately familiar with how my system worked so that I could do what I wanted. One door my BBS (the PhreakNet BBS, also formerly the InterLinked Public UNIX Access System) has become somewhat renowned for is its recreation of the WOPR computer systems, which allow you to interact with the WOPR just like David Lightman in the movie “WarGames” (somewhat dated video from 2019: https://www.youtube.com/watch?v=THncaADPX-k, but with 7K views and 137 likes, so I think it was well received).
Needless to say, a bunch of shell scripts is not really a proper BBS. There was no multi-user interactivity in this system at all, since each incoming session would fork a separate session that ran independently of all the others. It was very unique, but the architecture didn’t really lend itself to scaling into a more compelling BBS experience for users. At the time I wrote that iteration of my BBS, almost five years ago now, I wasn’t a very rigorous C programmer, either. Another BBS developer (que from R-Dial) actually encouraged me to write my own BBS software in the C, but at the time, I didn’t think that was something I wanted to take on. Fast forward four to five years, and I’ve now spent a significant portion of those intervening years programming in C, such as doing Asterisk development and other telephony projects. These days, I’m very comfortable with C programming, since I spend an inordinate number of hours each work doing C programming, and I rarely even use other programming or scripting languages anymore (you can tell the language has grown on me a lot). In doing so, I became very comfortable with all the basic concepts that one would need to write a full BBS software from the ground up. So, this past winter, I finally sat down for a week and did it, and that’s what became LBBS. Although I’ve continued adding functionality since then, the core of the BBS was mainly written in about a week, though of course it was easy to do simply because I’d had some architecture ideas floating around in my head for a while from programming that I’d done the past couple years.
I guess this answers the question of why I “had” to write: I desperately needed to replace my kludge of shell scripts with something that was truly interactive and on par with existing BBS packages. Secondly, I tend to understand things a lot better when I’ve been deep in the weeds implementing them, and in the case of LBBS, it was easier to write a BBS from the ground up than it was to understand a pre-existing system, like Synchronet. I’ll use Synchronet as an example, because it’s very popular, and it’s also pretty good. To me, Synchronet is complicated in a few ways, and part of that is because I haven’t taken the time to understand it adequately, but also, it’s huge. The source code is hundreds of thousands of lines. The codebase (to me, at least) is kind of a mess, it’s messy and hard to follow. Additionally, there are all these utilities required for configuration, and compiling takes minutes. In contrast, LBBS is currently just under 50,000 SLOC, is written in a modular, extensible, and easy to understand style of C, and compiles and runs very quickly. The “L” in LBBS actually stands for Lightweight, and this is where that comes from. The simplicity was part of the elegance to me, and I know I’ll be able to do a better job adding to my own software than trying to add bits and pieces to something else I’d never understand as well. So that answers why I wanted to write my own package, rather than using somebody else’s: if I want to do something weird (which I have done), there’s a good chance I’ll understand how I’d need to do it. Adding support for all the common protocols has also allowed me to develop a very intimate understanding of many of today’s common Internet protocols (e.g. IMAP) that I definitely would not have forced myself to develop otherwise, and I think that’s been very beneficial as well.
Q: What’s different about it?
There are a few things that I think are unique about LBBS. First of all, I’ll freely admit I’ve not extensively used any existing BBS software to run a bulletin board – I’ve fiddled with Synchronet a little bit, mainly to try to understand certain things, but that’s about it. Consequently, you might say that LBBS is a bit eccentric in a few different ways, since I haven’t been “biased” by how other BBS software does certain things. One example is that it’s configured purely through static INI-style configuration files. There are no GUIs or programs used for configuration, no proprietary binary formats used. Part of this philosophy stems from my experience working in the Asterisk codebase over the past couple years; users of both, in fact, may notice several
parallels, such as menus.conf being comparable to extensions.conf in Asterisk. Personally, I was very familiar with a config-driven configuration as opposed to using program-driven configuration, so that’s how I designed LBBS. I also designed it to be very modular, trying to keep as much functionality in pluggable and reloable modules as opposed to being built into the BBS binary itself. This makes development easier due to the modularity, but it also means that you can dynamically update more functionality without restarting the BBS entirely, which can lead to improved uptimes.
Another interesting “feature” is that LBBS is designed to support a rich variety of clients, including TDDs/TTYs connecting at 45.45/50bps (my telephony and phreaking background is visible in a few different places, and this is one of them). Another phreak and I had been thinking for a while that it’d be cool if you could use a TDD to dial into a BBS and join a chat room, or something like that, and a couple months ago, I was able to extend the Asterisk soft modem to support Baudot code, and so this very naturally fell into place at that point, since I could make my software support TDDs pretty well with a few changes. You can connect from a 50bps teletype, effectively, and still have a decent usable experience on LBBS, because I designed it so that it could work. I’m not sure if there are any other systems that are quite like that. This relies on the way I set up my pseudoterminal layer, by the way, for programmers familiar with the concept of a PTY. Another feature that LBBS provides is that you can also emulate different baud rates: if you want an entire “door” to effectively run at “300 bps”, just for the retro effects, you can do that easily without modifying the door itself. So LBBS allows you to do various weird things I’ve wanted to do over the years.
I’d be remiss not to mention the menu system, since I think that’s also a little different. For one, it’s driven by config files, as mentioned previously. The menus themselves, however, can also be generated automatically, directly from the configs, based on the connecting terminal. For example, in menus.conf, you can say you want option A to execute this door, option C to enter an IRC channel, etc., and you can specify that very tersely in a couple lines of config directives. The menu system in the BBS core can then automatically draw a decently nice looking menu based on the dimensions of the connecting terminal, etc. – the sysop doesn’t need to deal with any of that. I rely on this automatic generation, in fact, for my own BBS, because I’m lazy, and I wanted the BBS to require the minimal amount of effort required from the sysop to get the system functional.
Q: What are the features?
Apart from what I mentioned in “what’s different”, LBBS supports most of the standard protocols that are (or were) commonly in use. At the moment, this includes Telnet, RLogin, SSH, SFTP, FTP, HTTP, Gopher, SMTP, POP3, IMAP, NNTP, IRC, and Finger. It doesn’t currently support
FidoNet or some of the more “traditional” BBS protocols; that’s not to say it never will, it just doesn’t as of yet, as I’ve mostly been focusing on common protocols with RFC specifications that are widely compatible with different clients and systems. Feature requests are driven mainly by own needs and user requests, so if there’s something missing, please feel free to express that on GitHub.
Some of the BBS modules themselves have taken on a life of their own, as well; in some ways, I like to think of my BBS as sort of a “personal server” – you can set up your own email accounts, have your own newsgroups, etc. all in one package, all in one process. The SMTP module isn’t Postfix, obviously, but it can do quite a few things that might be difficult to do with larger, established mail software packages, and similar to how I can add interesting new features to the BBS core, I can add new features to individual modules as well. For example, recently I added an SMTP filtering engine that I (somewhat uncreatively) called “MailScript”, which is sort of like sieve, although it allows you to do some things that sieve doesn’t, like executing programs in response to messages, which can be handy for some of the use cases I had in mind at the time. LBBS tends to be provide a good playground for building other useful things as well.
LBBS also allows you to execute doors in a container, a sort of “sandbox” environment. One use case for this, for example, is to provide BBS users with shell access to the system, without actually granting them access to your real filesystem. There are some limitations to this, but this can also be handy for running programs in the BBS that you don’t want to interact with your real system, but restrict to the sandbox. This can enhance security.
The LBBS mail servers also support a rich suite of functionality, including shared mailboxes, ACLs, and filtering rules.
Q: What OSes does it run on?
At this time, it runs only on Linux distros. I personally use Debian, so Debian and Ubuntu are what I use for testing, the CI tests, and my own BBS, but it should work fine on most other distros; though I don’t test them, anyone is free to open an issue if something is broken on another Linux distro. This may work on other Unix platforms, like BSD, but I definitely don’t test those and don’t intend to, so I’m not going to claim it works on anything other than Linux at this point. Additionally, LBBS does use some Linux syscalls that probably aren’t available on Unix, such as copy_file_range, for example, so it almost certainly won’t compile without extensions to make it more portable. That could be done if there are devout Unix users out there that would benefit from it, but this started as a small project, so investing the effort in 100% portability up front wasn’t a high priority for me; there are some projects out there that even aim to support Mac OS and Windows, and I’m definitely not aiming to do that. This helps clean the code base cleaner and easier to work on as well.
