A customisable platform for creating fully automated AI competitions.
Features:
- 🔐 Secure: every agent in run in a private firecracker micro-vm without internet access and limited memory meaning it's possible to securely run user submitted code.
- 🚀 Fast: the backend is written entirely in rust with a focus on speed, when rate limiting is disabled it's possible for a user's agent to be running in a VM and playing matches within seconds of upload.
- 🔩 Resilient: actions such as match requests and agent activations are stored in Rabbit MQ persistant queues
- 🔧 Customisable: the core of DOXA makes very few assumptions about competitions while providing convenience features for common functionality, e.g. if you don't need a leaderboard for a competition you can disable it.
Uploading an agent using the cli (it is wrapped in a python program that automatically downloads the correct binary for the operating system for convenience):
DOXA is currently in ALPHA. It is possible to write custom competitions and run them but there are many features currently missing. Some of these missing features may constitute security concerns.
Additionally although DOXA is designed to be a generic platform, it's first usecase is for the UCL AI Society.
Currently some code in the repo is specific to that usecase (primarily the UI and the URL specific in the CLI tool doxa_cli).
Here is a diagram showing how the competition fits into the system (note this is a simplified diagram):
An example hello world competition is in crates/doxa_competition/src/hello_world.rs. You can also view a real world competition by looking in the competitions folder.
DOXA (the backend server) is made up of several components (crates) which can be found in the crates folder.
Provides useful boilerplate to easily setup a new deployment of DOXA.
An implementation of an ulimate tic tac toe competition for UCL AI Society, which is in the competitions folder.
A util crate that contains proc macros. doxa_core imports this and other crates can consume doxa_sys through that.
Contains common trait definitions particularly with regards to error handling. For example a RespondableError provides a convenient way for errors to be securely (without leaking internal data) mapped to HTTP error responses.
Provides HTTP routes and common util code for authenticating users.
Provides HTTP routes endpoints useful to managing users.
Provides HTTP routes for uploading and downloading agents.
Contains the database definition along with models and actions for all the different parts of DOXA.
Contains actions for interactive with rabbit mq.
A CLI tool that connects directly to the database for performing admin actions. This is packaged with the server docker container at /app/doxa_adm.
A CLI tool for users that makes use of the public HTTP API. It currently does not have a single cargo dependency on any other DOXA component as it interacts with the system entirely through API calls.
A library that could easily be extracted from DOXA to an independent project for managing firecracker VMs. It allows for spawning a VM process then sending commands over it's socket in a convenient way.
Contains a program (binary) that's designed to run inside the VM which manages the lifecycle of the agent including processing input and output. This is also exposed as a library that manages communication with that manager over a VSOCK. This library only has concepts of spawning agents, processing STDIN and STDOUT and restarting agents.
Provides the definition of a GameClient that competitions can implement and provides a way for running a match including downloading the agents.
Provides the definition of a Competition trait that can be implemented. This also contains several managers for different aspects such as agent activation and match scheduling.
This is a WIP component which should allow for users to play against a particular agent using a websocket.