|
@@ -0,0 +1,126 @@
|
|
|
+# 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 layer 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.
|