The Workflow of the GUI / Widget BBS Protocol

Tue, September 04 2018

The Workflow of the GUI / Widget BBS Protocol

Workflow

A base Rhenium BBS (name of one of my BBS packages that implements the GUI protocol) comes with the following workflow:
  1. List of Windows/Forms
  2. Client Fetches First Form - the LOGIN SCREEN
  3. (Optionally) Fetches the Register my Account or Apply for Membership form.
  4. Fetches the Main Menu
    1. Then interacts with each available menu form
    2. Can join the Global/Public Chat
    3. Can Initiate or Accept Private Chat
  5. Display the Goodbye Form
  6. (Optionally) Download BBS List, Write a One Liner
  7. Disconnect and Close all BBS Windows/Forms

Example

The workflow is programmable by each SysOp of each BBS. The first step the client will always do when connecting to a system if request "Forms", using JSONRPC the question will always look like this:

{"jsonrpc": "2.0", "method": "FORMS", "params": [], "id": "0"}

Depending upon the SysOp's preference, the reply can be as simple as:

{
    "jsonrpc": "2.0",
    "result": {
        "FORMS": "LOGIN",
        "LOGIN": ["window(center,center,280,200,'My ExchangeBBS Login')",
            "caption(8,10,'Username:')",
            "edit(8,32,260,'email')",
            "caption(8,82,'Password:')",
            "password(8,32,104,'pwrd')",
            "button(200,150,'Login','POST:email,pwrd')"
        ]
    },
    "id": "1"
}

The above looks like:

More Advanced Example

The response can contain a list of more FORMS for the terminal to request. The choice to show multiple forms could be used to display a "SPLASH" screen, or a introduction/logo screen common with hacker BBSes. The JSON response would look like:

{
    "jsonrpc": "2.0",
    "result": {
        "FORMS": "LOGIN",
        "LOGIN": ["window(center,center,280,200,'My ExchangeBBS Login')",
            "caption(8,10,'Username:')",
            "edit(8,32,260,'email')",
            "caption(8,82,'Password:')",
            "password(8,32,104,'pwrd')",
            "button(200,150,'Login','POST:email,pwrd')"
        ],
        "SPLASH": ["window(center,center,480,400,'')",
            "image(client,'splash.png')",
            "caption(24,256,'Exchange BBS\r\nWorld Headquarters','#FFFF00',32)",
            "timer(5000,'close')"
        ]
    },
    "id": "1"
}

That shows a splash, that closes automatically in 5000ms. For demo purposes, this is what it looks like:


Rendering would be the workflow of Window (with no title), Image (aligned to client), Caption (large in Yellow), Timer that calls close in 5,000ms (5 seconds). Both the LOGIN and SPLASH window are displayed, however the Splash is built last, so it appears "on top", and since it is larger than the LOGIN form, you do not see the LOGIN form yet. The 5 second time could be reserved for the server to do a reverse IP lookup on the client's connection, run it through known blacklists, and decide to drop the connection or not.

* Note: If the server drops the connection, the client will close all open windows for the session. You should also note, that the client and server can operate in connectionless mode - useful for web browser interfaces too.

Normal Workflow

A base system without any end-user (SysOp) modifications will flow like:
  • C: Requests FORMS
  • S: Respond with LOGIN Form
  • C: Submit Login Credentials
  • S: Respond with NOTIFICATION Form (Button 1 Register as New, Button 2 Try LOGIN Again)
  • C: Requests NEW Form
  • S: Response with NEW Form
  • C: Submit New Registration Fields
  • S: Respond with NOTIFICATION Form (Depending upon SysOp Setting - Greeting Limited Access, or Goodbye until SysOp Verifies you) Another option is system send a validation link to user's email.
  • C: Request LIMITED Form
  • S: Respond with LIMITED Form
  • C: Submits Feature from LIMITED Form
  • S: Respond Feature Form (repeat last two steps until Feature is GOODBYE or System TIMEOUT)
  • C: Request GOODBYE Form
  • S: Respond with GOODBYE Form
This is a very simple to use implementation. To avoid problem users, the LIMITED Form does not give the new user many options to execute. Normally a new SysOp starts out with this very basic workflow until he/she gets familiar with all of the features of the BBS. Depending upon the theme of the BBS and the personal goal of the SysOp they may enable a lot of features on the LIMITED or as some do, kick the user off until they manually verify the user.

Since we run the WHQ (World Head Quarters) we actually have a "Which BBS Look would you like", and offer a bare basic system for those interested in "What does it look like when I install it?", then we offer a more robust system for those interested in "What can the software do?", and lastly, we offer an extremely modified version for those who are interested in "I want it to be different".