ActivityPub is the new FidoNet

The New “FidoNet”

It occurred to me today that ActivityPub is the new, modern FidoNet(-style) networking. Sure you have W3C publishing official specifications, but what you mostly have is every day “hackers” putting the protocol to work building decentralized communications. Anyway, the specifications are quote vague at best, which in this case, I’m going to consider a feature. In other words, a lot like FidoNet.

A Brief FidoNet History

Since the point of this article isn’t really FidoNet’s history itself, but rather, it’s parallels with the modern ActivityPub, I’ll skip most of the details and just break things down into some evolutionary steps:

After this point, while there is an “official” FidoNet standards body, creating and approving modifications and additions to the protocol, there are some things to note:

  1. This is an organic and public process; The standards are discussed on FidoNet itself, and adjusted in a near democratic process
  2. Standards? Who needs standards?! As BBS’s were naturally fragmented, information was much slower to spread (though it was a huge improvement at the time!) than it is now. Additionally, like all things extendable, authors extended!

Extending FidoNet

The system for “extending” FidoNet that essentially appeared organically is called “kludges”. Essentially what constitutes a kludge is a line in a message that looks something like this:

1
"\x01IDENTIFIER: Value\r\n"

[!] A few kludge-like standards appeared as well, but most of what followed used this new kludge format. A standard within a standard!

Yo Dawg

A lot of the common kludges can be found digging around the FidoNet Technical Standards Committee website. Then again, a lot of what is in the wild falls into various categories of “not an official standard at all” to “we sort of followed the standard”. Things also get complicated with FidoNet proposals that some developers started using while others did not.

Let’s look at an example regarding what we would now call “character encoding”. But remember this is in the 80’s and early 90’s! We certainly didn’t have UTF-8 yet, and many just assumed US-ASCII was the only way to go. But what about those that didn’t speak English and/or otherwise needed different encodings? Along comes the CHARSET and later FSC-0054.004 describing the CHRS kludge. Of course, these standards are attempting to deal with other moving target standards (or lack thereof) such as character encoding names themselves. Take a look at some examples:

1
2
3
4
5
6
# Means text contains German characters, but still uses 7 bit character representation.
CHRS: GERMAN 1

# Means the text contains IBM PC graphic or extended characters.
# This would normally only appear in locally held messages.
CHRS: IBMPC 2

Huh?

Once UTF-8 became widely available (BBSes were effectively dead at this point), it became common to just encode using that:

1
CHRS: UTF-8

Ah, that’s better.

Back to ActivityPub

OK, let’s jump back to ActivityPub and take a look around. The basic idea is that many implementations and ideas can co-exist as long as they adhere to the basic protocol (of course, there are oddities here as well…). One can then extend the JSON-LD namespace, and provide additional properties with objects.

Just a few out of many examples of implementations and what they support:

Are you starting to see the parallels here? From freedom comes diversity. Extra complexity? Sure, but to me, it’s worth it.

Conclusion

I hope this quick and dirty article helps show “What’s old is new again”. Regular users fed up with corporate control have once again found ways to communicate. And as such, it’s very organic and fascinating.

As for myself, I’m thinking about extensions that can be applied to BBSing