Using Jabber/XMPP for Universal Go Server (UGS)

Version 1.0 Mike Albon (7 February 2005)

Rationale:

Using xmpp for providing application services between peers removes a lot of problems. As xmpp is extensible by its nature, this means that UGS can solve go problems rather than solving firewall/accessibility/security problems. This document is intended as a discussion for how xmpp and related technologies can be used. The server side is discussed here, not the client.

Requirements:

The UGS has some functionality requirements as specified in the wish-list, these listed will be addressed:



A vision of how it could work:

The sections below are a view on how it could be implemented using existing standards and code where applicable. All the example will use Jabber.org.uk as the providing server. The UGS specific components will be under ugs.jabber.org.uk.

Adding an account:

To use the service a user would need to register a 'nickname' with the authorisation service. The registration service within xmpp can ask for arbitrary information from a user as part of this process. The authorisation service administrator can then manage the users allowing Message of the day or Welcome messages. Disable/enable users. Blacklist/White-list management, etc. JEP-0133 - Service Administration would form the bulk of the tasks needed to be done globally. All other tasks (like joining a 'club')can be handled using the JEP-0050 – Ad hoc Commands facility.

The authorisation service then provides the other sub-services with user account details.



Sub-services:

Chat Rooms:

Using the Multi User Conference specification of Jabber (JEP-0045) all common scenarios can be catered for.

All rooms could use the authorisation service to provide reserved nicknames as provided for by MUC. This would enable only allowing tournament members joining etc.

Hierarchical naming can be provided for using DISCO. For an example see chat.yahoo.dev.jabber.org.uk.

There is an existing MUC component which potentially could be modified to provide any necessary extensions, like relaying proficiency information. Ad hoc commands could be used to issue a challenge in a chat room.

Game Storage:

Storing games could be done using the Publish-Subscribe protocol (JEP-0060). This will enable the owner of the data to have some control over who sees their games. It also enables the games to be stored once rather than once per player. Training games could also be stored but not enabled for public viewing.

The Authorisation service can be used to provide details of users and their group memberships, and the access controls can be based on that information. Idavol is an existing pubsub component which could be used/extended to provide these services.

Game Server:

Using a simple move protocol built on top of messages games could be played and monitored by 3rd parties. This could be implemented as a MUC or another mechanism. The game server can also 'copy' the moves to the game storage component if configured too. The game server would control all the game semantics and legal moves. If the protocol is written generically it could be re-purposed to provide other games like chess.

For games like those which are ranking or tournament, an extension to MUC could be made to allow communication between the assessors/observers without the comments being visible to the players until the game is complete. Observers/Assessors may also wish to suggest strategies by using example moves, again without the players knowledge.

Diagram of a normal dedicated client connecting to the services:


Diagram of a volity client connecting via a front end process: