| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| wiki:user:digital_man [2019/10/31 20:03] – Things I learned while interviewing for programming jobs in 2019 digital man | wiki:user:digital_man [2023/04/11 18:23] (current) – [Is Synchronet PD or l33t?] digital man |
|---|
| ====== Digital Man's blog ====== | ====== Digital Man's Web Log ====== |
| | |
| | ===== Is Synchronet PD or l33t? ===== |
| | |
| | I feel weird answering this rhetorical question because Synchronet has been (or wanted to be) **both** PD and l33t at different times during its history and perhaps now it's just a totally moot and silly question to be asking at all. What am I even talking about, you might ask? |
| | * **PD** stands for "Public Domain", which, //back in the day//, meant a BBS was legitimate and contained/encouraged/allowed only legal content (e.g. public domain or shareware files) |
| | * **l33t** is r0dent-speak for "elite", which is how BBSes referred to themselves //back in the day// when they housed archives of illegally copied software (aka "pirate warez") or other illicit information (e.g. phreaking docs, malware, LD codes, CC numbers) |
| | |
| | I started Synchronet when I was 20 years old, as a project to replace WWIV BBS Software with a //stable// multi-node BBS software for my file-transfer oriented //elite// BBS, [[bbs:Vertrauen]]! New users of my BBS had to know the current New User Password (NUP), were given a lengthy technical proficiency exam, and required to submit a written request for access (including references): all the hallmarks of an "Elite BBS". [[person:ille_homine_albe|My co-sysop]] and I had fun actively harassing and hazing users of the BBS that we felt were less than deserving of our respect. We had a good time at the expense of many r0dentia. |
| | |
| | After the reach of Synchronet extended beyond my local circle of (now ex-)WWIV Sysop friends, I started to add features inspired by commercially-successful multiuser BBS packages (e.g. MajorBBS) and listen to needs of their users and sysops and add more "mainstream" features (e.g. FidoNet) that were being requested by the sysops of more "legit" systems. |
| | |
| | When I decided (at my brother's urging) to move Synchronet completely into the commercial realm, I started to look more closely at the "competition" in the PD/mainstream BBS software market (e.g. Wildcat!, PCBoard, etc.) and implement the features that were most in demand (e.g. QWK support, enhanced door support) while moving my own BBS into the role of a mainstream "support BBS" and removing all questionable content and user unfriendly (hostile?) features. I continued to follow the development of WWIV and its derivatives (TAG, Telegard, Renegade) from a distance and while I always thought these "scene" BBS packages had a more appealing aesthetic than the mainstream packages, I was really trying to appeal to the commercial BBS sysops, since they were more likely to be willing and able to pay for their software of choice. |
| | |
| | When I started advertising Synchronet (and my BBS numbers) in BBS-related magazines, I would prompt "Guest" logins to Vertrauen for their voice phone number, so I could call them some time after they'd logged-off to ask if they had any questions (in attempt to drum up sales of Synchronet, which was pretty effective actually). I recall one particular guest sysop that didn't spend much time online before hanging up. When I called him back (I could tell by his voice that he was much more "mature" than I), he did not hesitate to tell me how put off he was by the "look" of Synchronet (the colors, maybe the terminology or the menu/command keys) and he said, verbatim: "I know what kind of BBS this is and I'll have no part of that!" before he abruptly hung-up his handset. Click! Duhhhhhh..... |
| | |
| | So while I always tried to make Synchronet more visually appealing than the purely-functional BBS programs of the era (think Maximus, Opus, Fido, MajorBBS), I never went to the extremes of some others (e.g. Searchlight, Forum hacks, Robo/FX) - my focus really was on file transfers, multi-node chat, door games, and messages. And while I did kind of abandon the "elite" scene pretty early on during the commercialization of Synchronet, I don't think Synchronet ever fully belonged in the commercial/PD BBS software group either. |
| | |
| | Someone recently described Synchronet as the "professional" option for BBS software in 2023, but not what the "cool kids" usually run (that preference being Mystic BBS software). I take that both as a compliment and a challenge! |
| | |
| | ===== What's Wrong With FidoNet? ===== |
| | |
| | And by "FidoNet", I'm not referring to the message network itself but rather the underlying technology (aka FTN). |
| | |
| | Before you can "fix" something or just replace it with something better, you really should have a comprehensive, enumerated list of what's wrong with the existing "solution". |
| | |
| | This list is of course, just //my// opinion, but it is an informed one with about 30 years of experience with FTN from both a user/sysop's perspective and a developer. |
| | |
| | ==== Backward Compatibility ===== |
| | |
| | Likely the biggest problem with FTN is that much of the software that is used to run the network is abandonware with no hope of being upgraded to support any substantial improvements in the underlying network technology. Most substantial improvements to the network technology would leave a lot of existing nodes behind and hamper the possibility of retro-systems being able to join and participate in FidoNet. The requirement of strict backward compatibility with software written in the 1980s and 1990s is the pervasive rationale of the FidoNet network members for not accepting proposed solutions to the network technology's shortcomings. |
| | |
| | The one saving grace has been extensibility via the message "control paragraph" (aka "kludge line"). Since it was specified early on that message lines beginning with a Ctrl-A (ASCII 1) character must not be displayed, as they contain "control information", this has been the scheme by which additional or improved message header fields have been added over the years. Unrecognized control lines are ignored by receiving software and thus backward compatibility can be maintained while still defining and using new control lines in messages created and consumed by newer FTN software. |
| | |
| | ==== Location-based Addressing ==== |
| | |
| | The geographic location of the FidoNet node (continent, region) is encoded in the node address. While this is true of IP addresses as well, the Internet has a handy solution called the DNS. While I do like that it's obvious to an experienced BBSer that it's a FidoNet address when you see one (e.g. "1:103/705.1"), it's certainly non-intuitive what all the symbols and numbers mean and is not easy to remember. An addressing system that uses human-readable (and memorizable) "words" for the addresses of the network nodes would be much preferred. |
| | |
| | ==== Packet Format ==== |
| | |
| | The so-called "type-2" or "stone age" [[ref:FidoNet Packets|FidoNet Packet format]] was originally specified and accepted as the FidoNet standard method of message exchange in 1987 and hasn't really progressed much since then. Although there were a few proposed packet format replacements twenty-plus years ago, none of them were accepted as a standard. There have been some incremental improvements to the type-2 packet definition (FSCs 39, 45, and 48) and while FSC-48 ("Type-2+") has long been the majority-preferred packet format, none of these improvements has been ratified as a formal standard. |
| | |
| | The problems with the Type-2 packet format and its derivatives (and their "packed message" format) are: |
| | - Lack of extensibility (no real way to substantially add more header fields or extend the length/range of any already-defined header fields) |
| | - US-ASCII only text field with no support for using Unicode or other character sets |
| | - DateTime header field that is plain text, represents local time, with a 2-digit year |
| | - Artificially limited string lengths (i.e. 35 characters names, 71 character subjects, 8 character passwords) |
| | - Relying on NUL-terminated (ASCIIZ) strings (most of the time) |
| | - Little-endian integers (x86 architecture assumed at the time) |
| | - Reliance on echomail "origin line" for the originating address |
| | |
| | ==== Siloed Development ==== |
| | |
| | Prior to and during the time that FidoNet technology was being originally defined and implemented, there were parallel peer-reviewed developments with similar Internet technologies (e.g. SMTP, NNTP), and yet, FidoNet standards don't reflect any of the learnings or best practices from these open Internet standards or RFCs. This blindness to more robust existing open solutions to the same or similar problems is pervasive throughout the history of FTN, but is particularly and painfully obvious in [[faq:misc#ftn_msgid|FTN Message-IDs]]. |
| | |
| | ==== Character Sets ==== |
| | |
| | While there have been enhancements to support non-US/English character sets (code pages) and even UTF-8, they're awkward (e.g. you have to parse a message's text to find a CHRS control paragraph before parsing/displaying the header fields correctly?) and not universally supported. Anything other than US-ASCII in message headers or text is clearly an afterthought and mostly does not work as a user would hope. |
| | |
| | ==== Node List ==== |
| | |
| | Any system that requires extensive manual maintenance is bound to be wrong more than it is right and I think the FidoNet node list is an exemplary case. I have not used a node list on my FidoNet-connected BBS in more than 25 years and I don't miss it. The format, purpose, and use of the node list is all highly suspect and begs to be replaced by something more distributed and automated. |
| |
| ===== Why BBS? ===== | ===== Why BBS? ===== |
