Fist-Protocol

by Charles Iliya Krempeaux

Name

The name of the fist-protocol is a play on the name for the finger-protocol. This was done because the fist-protocol was directly inspired by the finger-protocol, and — although the fist-protocol does not explicitly continue as a newer version of the finger-protocol, it is a successor "in spirit" — i.e., a "spiritual successor".

Design

There are many things that went into the design of the fist-protocol.

Finger-Protocol Inspiration

The fist-protocol is inspired by the finger-protocol and the ways which finger was used people.

finger is said to have be created back in 1971.

I was using finger in the 1990s — and maintained my own finger (.plan and .project) files. Back then, my finger (.plan) file contained:

• contact information,
• URLs to my presence on other parts of the Internet,
• a short biography,
• a journal,
• articles,
• jokes,
• a bunch of ASCII art.

I stored all that information in separate files, which were compiled into a finger .plan file.

Back then I (and I suspect most people) accessed finger from a terminal or terminal emulator, connected to a Unix system, by invoking command similar to:

finger username

(Here username would be replaced by the person's username on that Unix system.

So, for example:

finger joeblow

Or:

finger dariush

Example output from the finger command might look something like this:

Login: reiver                           Name: Charles Iliya Krempeaux
Directory: /home/reiver                Shell: /bin/bash
Last login Thu Dec 01 02:05:59 2022 UTC
No Mail.
Plan:


          _
         ( )
          H
          H
         _H_
      .-'-.-'-.
     /         \
    |           |
    |   .-------'._
    |  / /  '.' '. \
    |  \ \ @   @ / /
    |   '---------'
    |    _______|
    |  .'-+-+-+|
    |  '.-+-+-+|         Hello world!
    |    """""" |
    '-.__   __.-'
         """

Some finger-protocol clients would include the host-name in the output, too. For example:

[example.com]

Login: reiver                           Name: Charles Iliya Krempeaux
Directory: /home/reiver                Shell: /bin/bash
Last login Thu Dec 01 02:05:59 2022 UTC
No Mail.
Plan:


          _
         ( )
          H
          H
         _H_
      .-'-.-'-.
     /         \
    |           |
    |   .-------'._
    |  / /  '.' '. \
    |  \ \ @   @ / /
    |   '---------'
    |    _______|
    |  .'-+-+-+|
    |  '.-+-+-+|         Hello world!
    |    """""" |
    '-.__   __.-'
         """

Finger-Protocol Advantages

Some desirable qualities of the 1970s era finger-protocol are:

• ✅ the finger-protocol is a human-legible protocol
  • rather than just a programmer-legible or machine-legible protocol
• ✅ the finger-protocol protocol is simple enough for even a more junior software developer to be able to understand it
• ✅ the finger-protocol protocol and its default data-formats are simple enough for a competent software developer to be able to create a (simple) working client as a weekend project
  • ✅ if the default data-format is dumped to a terminal or terminal emulator it is human-legible
• ✅ the finger-protocol protocol is simple enough for a competent software developer to be able to create a (simple) working server as a weekend project
• ✅ all of a (single) user's content is provided as a single download
  • this is true even if the user has both a .plan file and a .project file; they are combined into a single download.
• ✅ a client could make a request from a server for a user who is not (necessarily) local to that server
  • for example: finger joeblow@example.com@host.example
• ✅ the finger-protocol implicitly has a key-value pair format that is human-legible, programmer-legible, and machine-legible.
  • for the format resembles the INI-format including the (square) bracket section headers, but it uses a colon (":") for the key-value separator rather than an equal-sign ("="), and there is a way of writing multi-line values.

Finger-Protocol Disadvantages

Some undesirable qualities of the 1970s era finger-protocol are:

• ❌ when a client receives a response from a server, it does not know whether it received all the data or not, as, for example, the network connection could have been disconnected prematurely, but there is no way to detect this,
• ❌ there is no tamper detection,
• ❌ there is no way to determine whether the finger (.plan) file was actually from the user whose content was requested,
• ❌ there is no privacy,
• ❌ the entire finger (.plan) file must be download each time, even if the exact same finger (.plan) file was previously downloaded,
• ❌ identity is strictly tied to an Internet domain,
• ❌ there is no official way of segmenting the download (into sub-pages).

HTTP

In some ways, the HTTP-protocol has become a de facto (layer-4) transport-layer-protocol (rather than a (layer-2) application-layer-protocol).

This seems to have initially been due to firewalls at many corporations.

IPv4 address exhaustion probably also played a role in this, by pressuring corporations to use private networks. But, their use of private networks was often done through firewalls.

At many corporations, TCP-port 80 (for the HTTP-protocol) and later TCP-port 443 (for the (encrypted) HTTPS-protocol) were allowed through corporate firewalls, but little if any other TCP port was. With all UDP-ports often being entirely banned.

That meant that, if you wanted to create a new application, and you wanted people to be able to use it while at corporate offices, then your application had to use TCP-port 80 and later TCP-port 443. I.e., it meant that your application had to use HTTP or HTTPS. I.e., it meant that your application had to be a Web-application.

That seems to have been the initial cause — that turned the HTTP-protocol into a de facto (layer-4) transport-layer-protocol (rather than a (layer-2) application-layer-protocol). But this isn't what kept it going.

Years later, new developers never learned how to create network software (other than HTTP-protocol based software), and in some sense, the industry "forgot" how to create (non-HTTP) network software. Or, at least, by comparison, there weren't many of us who not only knew how to create network software, but had extensive experience doing it.

At first, both the front-end and back-end were built out of Web-technologies. But, with the rise of the (so called) mobile-phone as the main computing-platform, and with it (due to "pressure" from Google and Apple Computers) and due to the popularity of creating "native" front-ends rather than Web front-ends — it is now usually just the back-end that could be considered on the Web (with the front-end for the mobile-phone being something else).

It is somewhat interesting that — back the in 1990s, one of the things that drove the adoption of the Web to be the new ubiquitous front-end for "everything", was the pain of having to re-write your application mulitple times: for Personal Computers (PCs) running Microsoft Windows, for Macintosh computers (Macs) running Mac OS, for Sun Microsystems computers running Solaris & NeWS, for NeXT Computers running NeXTSTEP, for SGI (Silicon Graphics Inc.) computers running IRIX, etc. And now, with the whole Android versus iOS "native" applications, we are right back where we started — and have this same pain again of rewriting our applications for each platform!

But, either way, this is where we are, and both HTTP and TCP should be considered for a (layer-4) transport-layer-protocol for the fist-protocol.