Skip to content
Closed
Milestone

The Future of Beymax

This is going to be a sort of meta milestone, tracking where Beymax is headed:

  • Overhaul Beymax's API and bring up to par with the latest Discord has to offer (%API 2.0 Overhaul)
  • [ X Refactor the repository. Beymax's internal API (core, suites, args, utils, etc) will become beymax/api and will be distributed to pip as beymax. The existing suites will be moved to beymax/bots, providing presets for users making their own bots, but no Client will be created. Finally, the production implementation will be moved to beymax/production and will be distributed as a docker image at docker.graubs.info/agraubert/beymax. All of these repo changes will come with Wiki/documentation overhauls. beymax/api may get it's own sphinx/readthedocs implementation
  • Add beymax/controller, an implementation of a controller node. beymax/api should provide an interface and a dummy (local controller) implementation to use for smaller bots, while beymax/controller will provide the production implementation. beymax/controller should be distributed to pip as beymax_controller and should also provide the CLI tool beymax-ctl. beymax/controller should come with a webUI, featuring cookie auth and the ability to control the controller. Individual beymax clients using the web controller (as opposed to the local controller) must authenticate with their controller before starting the shard. This will be deployed and tested at test.beymax.dev
  • Polish, test, docs, updates. Keep grinding until ready for a deployment to the live beymax.dev. At this point, both test and prod should always be live. For testing purposes, it may make sense for test.beymax.dev's controller to always be up, and only run test shards when actively testing.

Authentication

  • The webui should use cookie authentication for requests.
  • The webui should provide the following unauthenticated pages:
    • Homepage (showing some info, maybe a video, links to other pages, etc)
    • Status page (showing aggregates like requests per minute last hour, long requests per minute last hour, last check-in from all shards, and how many guilds they are serving)
    • Invite page (with a flow or simple redirect to bring users to the add-bot-to-my-server discord invite page)
    • Dev links (links to gitlab and docs)
  • The shards should all register using a single-use token (or 'trusted tokens' for docker-compose, so that the controller can be pre-programmed with pre-decided tokens). Bots should then be issued refresh and auth tokens. Auth tokens should be used in every request, and rotated periodically.
  • The /config command should generate a url with a login token. When the url is loaded, the webui passes the login token through to the controller API and converts it to a short-lived auth cookie. The cookie should be scoped for only the server that issued the command.

Order of operations

This milestone represents an enormous change to Beymax. I believe that the easiest path forward is:

  1. Add the controller interfaces (#132)
  2. Update the code to anticipate multiple guilds (#134, and related Multi-Server Blocker issues)
  3. Add updated error tracing behavior (#136)
  4. Test and deploy, no announcement (Increment API to 0.1.0 :: Beta)
  5. Implement the web controller (#133)
  6. Add post-controller enhancements (Post-controller-era issues)
  7. Redeploy with announcement (Increment API to 1.0.0 :: Production)

Countdown to deployment

As mentioned in #133 , here are the steps to complete after that issue is closed

  • Build, deploy test.beymax.dev on docker server.
  • 3-day test and polish period, during which new issues should be opened as their own issues
  • During this time, work may continue on other Post-controller-era issues and enhancements as well as bugs or polish discovered during the test period
  • After the test period and after all related issues are resolved (see previous bullet) begin a 14-day stability test. The stability test should not start if there are other issues in this milestone
  • During the stability test, work on production infrastructure. Select a hosting platform and set up containers (including psql container, with different permissions [ie: shard credentials must not have access to AuthTokens]). Also update webhooks so that tagged deployments will update the pods
  • Deploy release