No description, website, or topics provided.
Switch branches/tags
Nothing to show
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


A message board for cloud communication.

Types & Tables

A Message is a notification from some board member posted to a channel on the
board. Messages may be in reply to other messages; the Thread type describes
this relationship.

The Message type as a Postgres table:

        uuid |        timestamp         | poster  |  chan   | message
        uuid | timestamp with time zone | address | address |  text

The Thread type as a Postgres table:

                         before | disposition | after
                          uuid  |    flag     | uuid

An Address is a simply an LDH domain name which may have an @ and a short
"local component" in front of it. The Disposition flag is one of:

                Ignored   Acknowledged   Problem   Info   End

and is a way to indicate how a reply relates to the history of a process
spawned as a result of receiving the message.

When a client connects, they register subscriptions and an address as a
pre-requisite to sending messages. Their subscriptions form Registered

                 nick   |        timestamp         |  chans
                address | timestamp with time zone | [address]

In the implementation, registrations are tied to a client connection by
database connection metadata (in Postgres, this is procpid and backend_start
from pg_stat_activity).


We can imagine four kinds of "users" for the cloud message board:

  * Server bots receive messages, post replies and perform tasks.

  * Task bots post tasks, monitor replies and keep track of task status.

  * Admin bots observe overall error rates and throughput, monitor space usage
    and truncate tables.

  * Ad hoc bots connect to peform various analytics, not relevant to the
    operation of the board on a moment to moment basis but of interest to
    those maintaining the cloud.

From the roles above, we can expect that:

  * SELECTs of a very general nature need to be performed from time to time.

  * Deleting older messages, threads and subscriptions is necessary; but is
    also completely formulaic. A couple stored procedures and a foreign key
    constraint linking messages to threads is probably enough; we don't expect
    general DELETEs to be performed at all and thus no bot needs permission to
    do them.

  * Some very specific SELECTs need to be performed over and over again. For
    example, checking if there is, in a thread, new messages that indicate
    completion or failure, new messages that indicate locks being taken and so
    forth. These will eventually become stored procedures.

Data additions are very limited. There are no UPDATEs at all -- message/task
cancellation is accomplished with a reply having Belay in the disposition
column, for example; and subscription cancellations involve adding an
additional row to the subscriptions table. The two input operations are,

  * Posting a reply or a new message.

  * Updating one's subscriptions.

For a server bots, maybe we only allow replies; so after establishing a
connection and registering a subscript, server bots need only two operations:

  * reply, to form a mesasge;

  * inbox, to get a VIEW of relevant messages to SELECT from.

For task bots its useful to have a `post' function to kick off a thread and a
one or many stored procedures for walking the thread to find things like all
acknowledgments, all failed tasks, all incomplete tasks.