documentation

Community Messaging Project

To communicate humanly between IRC, portal websites and gameservers or even more.

Architecture

Meta ...

Example ...

The IRC bots

Eggdrop Bot TCL plugin

Configuration from a webserver XML

provides the following commands on the messaging service:

Standalone Go-Lang Bot

Configuration from a webserver YAML

provides the following commands on the messaging service:

Control Server

Commands to publish provides the following commands on the messaging service:

Messaging Service

Every client connects to a messaging service where they can interact with a command and control server program. It is the communication backbone. So to say, it's the transport of the messages with which the programs interact. Let's say 'Program message transport' is a synonym.

As a future (late 2017?) underlying message transport I chose NATS from Apcera. https://nats.io

At the very moment (since 2014), the whole message transport is done via a ruby server that works together with a SSH-Server to send and receive messages. It is nicely working but there we have a single point of failure. There is only one Server that all clients have to connect to. We need this more scalable and failsafe.

Have a look at the quakeworld community. We provide and use this IRC broadcasting service now for over a decade. It sure works, but this community is a golden nugget in comparison to many other communities. It deserves an even better working service which they can expand and code on.

Resiliency of program message transport

Communities change and people come and go. So do servers and all those moving parts of a networked program. Lets make it more resilient.

You can join the whole network by adding a cluster node to the messaging service. This would then extend the messaging service to make it more resilient. This also means, the communication between all clients would be working in all those conditions when a server fails. The clients would still find a messaging server inside the cluster. See https://nats.io for clustered NATS.

Even more, lets say, if the whole NATS portion of the network fails, clients would still need to be able to connect to the network. So, we could - in some unknown future - even add Amazon Web Services Simple Queuing Service (SQS) to this network by coding a gateway from NATS to SQS. But that's future talk for something that was never meant THIS big. ;-) Let's dream.