# Community Messaging Project (CMP)

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

## Architecture

Meta ...

Example ...

## The IRC bots

Historically, the IRC bots were first. :)

### Eggdrop Bot TCL plugin

Channel and ban configuration from a webserver
simple XML (yikes anyhow)

* Can act as standalone community IRC messaging service (CIMS)
* expands itself with eggdrop botnet ability
* expands itself with the messaging service and control server

It provides the following commands on the messaging service:
Link

### Standalone Go-Lang Bot

Configuration from a webserver
YAML

It provides the following commands on the messaging service:
Link

## The gameserver joining bots

A gameserver joining bot joins the gameservers by whatever means
the gameserver protocol allows and then allows commands to be used
by users to interact with other people.

### QuakeWorld Bot

The current QuakeWorld Bot connects to the quakeworld (qw) gameservers that are 
defined in its configuration file. It is able to connect to
nearly unlimited qw servers. But be sure to have a look at the cpu strain it will
get on the server.

It also connects to the control server via SSH to send and receive
network commands.

* Can act as standalone QuakeWorld Bot community messaging
* Expands itself with the messaging service and control server

It provides the following commands on the messaging service:
Link

## The portal websites

### PHP Client

A php client written by Sni is also available but kinda unmaintained. It is in use by
quakeworld.nu. It connects to the control server by SSH to read and write
network messages.

Link

## The Control Server

The "Control Server" merely is a client on the messaging service. But since
it is the portion that actually helps forming processes between the other clients, we began calling
it "Server". Generally it allows for more interaction between the various kinds of clients.

So it defines a minimal set of text protocol under which the other clients can
talk to each other and even provides some simple services to, for example, resolve
IP addresses to nice short names and countries. 

It provides the following commands on the messaging service:
Link

## The transport layer

Every client connects (or _can_ connect) to a messaging service where they can interact
with the other clients. It is the communication
backbone. So to say, it's the transport laer of the messages with
which the programs interact. Let's say 'message transport' and 'messaging service' are
synonyms and 'network commands' are the commands that clients chose to provide and 
request on each other within the Community Messaging Project.

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.

## Final words

This messaging service has been in use in the quakeworld community now for over
a decade, dating back to 2002. Let's keep it alive and expandable.