• Should we store course splits in the API at all?
• Who is going to decide on the splits?
  • The mapper?
  • The map approval team?
• How are we going to store them?
• How do we handle potential updates?

At some point we will want to verify and store replays sent by servers and then place those runs into their respective *Records table.

How replays will be encoded, or scanned, is not decided yet. We could either implement it as part of the API, which would mean that part of its code would be closed-source. We could solve this by creating a separate, private, repository just for the Anti-Cheat, and include it as a git dependency in cargo. We would then also need a feature flag to disable that dependency and replace its code with dummy implementations accordingly. It sounds more complex than it is, but it would certainly add maintenance overhead to the API.

The alternative is that it's an entirely different service that the API communicates with. It could run independently, be written in another language, etc. This would increase the overall complexity of the system as we would have to account for the replay service being unavailable.

As for storage, we probably want to store them on an S3 Bucket.

Establish a system where players have a "max server count" that determines how
many servers they are allowed to create. Then, allow them to make a request for
creating a new server, which will only succeed if their
(max_count - current_count) > 0.

While I haven't looked into it yet, tracing-opentelemetry seems to be the way
to go to collect logs in a standardized fashion, and axiom is compatible with
OpenTelemetry, so we can still send those logs.

We should allow server owners to make PATCH /servers/{server_id} requests for
servers they own. This will allow them to edit details like the server's name
and IP address.

We should also allow them to re-generate keys for their servers, assuming they
currently have one.

Should we store "tags" for servers?

This could make searching for servers you want to play on easier.
Some considerations:

• Who is able to add create new tags? Admins? Server owners?
• Is this really that useful?
• Would many server owners put in the effort of choosing appropriate tags and keep them up to date?

sqlx-cli is currently required for running migrations, which is sub-optimal
considering it's not available in most package managers. You would have to
install rust or nix to actually use it, which includes the prod server, so I'd
rather have it be a shell script.

• Concrete ban reasons
  • partially implemented in #42
  • TODO: more reasons
• Appropriate durations (#42)
• Automatically revert expired bans this is unnecessary since we now compute is_banned dynamically
• Allow uploading replays for manual bans (#8)

same as the server tag
makes it easier for players to choose map matches they enjoy

e.g. ladder, slide, climb, bhop, strafe, combo

When making a GET request to /maps with the mapper parameter specified, only
that mapper will be included in the response object, rather than all the mappers.

How do we handle authorization?

This includes multiple frontends, such as the main website, the forum, and admin dashboards.
We can already authenticate users with Steam, but we need to manage their permissions ourselves.

Currently the following ideas are on the table:

1. store permissions in the database, associated with SteamIDs

   • really simple to implement
   • permissions can easily be revoked
   • authorized requests will probably be infrequent enough for this not to be a performance hit

2. store permissions in a JWT alongside the user's SteamID

   • even simpler to implement
   • permissions cannot be revoked
   • we won't have to make database lookups to authorize requests

I personally would go with approach 1), mainly because of revokations.

Next question is how do we scope permissions?

1. store them in a wildcard cookie

   • the user can login on one site, switch to another, and still be logged in
   • we are more vulnerable to XSS; if a user's credentials are compromised on one website, they can make authorized requests to any API endpoint
   • we only have to keep track of one session at a time

2. store separate sessions, each one scoped to a specific domain, with specific permissions

   • much more complicated to implement
   • less vulnerable

3. use a third party service like Keycloak

   • less maintenance required on our side
   • we are reliant on an external service we don't control
   • since Steam uses "OpenID 2.0", not "OpenID Connect", Keycloak specifically does not have "native" support for it; we would have to use some kind of extension, which is another liability
   • it might be overkill for our purposes

Depending on what we choose to do for scoping permissions, we also need to decide how we represent them. Assuming we store the permissions in the database and keep "global" sessions, I would create a separate table that stores a permissions bitfield.

CREATE TABLE Admins (
  `id` INT2 UNSIGNED NOT NULL PRIMARY KEY,
  `steam_id` INT4 UNSIGNED NOT NULL,
  `permissions` INT4 UNSIGNED NOT NULl,
  
  FOREIGN KEY (`steam_id`) REFERENCES Players (`steam_id`)
);

Each bit in the permissions integer would represent a distinct privilege, and whether the bit is 1 or not determines if the user has that privilege.

If we store scoped sessions in a UserSessions table or something, we would probably still want to store "global" permissions in an Admins table, but then compare the permissions of the current session against the permissions in the "global" table, and only allow permissions that are set in both.

We need to setup CI/CD so that the Docker image for the API gets built
automatically, and potentially even uploaded to a staging / prod server.

Building the image on prod is a pain, and not having to deploy updates manually
will be much more convenient.

• Basic CRUD operations
  • partially implemented in #45
• Replay storage & Anti-Cheat validation (#8)

If the API is under high load, the axiom log layer allocates a lot of memory
(possibly tokio tasks?), which does not go down after the amount of req/s goes
down.

This needs investigation.

The main cause of the leaks seems to have been axiom-rs, which was either allocating too many tokio tasks, or the backing reqwest::Client was keeping around connection pools for too long; but that dependency has been removed and replaced with a custom implementation.

It also appeared that utoipa-swagger-ui was re-generating the entire OpenAPI spec on every request, even if its specific routes have not been hit (?), which was causing insanely high memory usage. This has now also been removed, see #37 for details.

Spawning a lot of tasks that make HTTP requests with reqwest still causes high memory usage though, and it doesn't seem to go back down after a period of high load. It also doesn't go up as much again, if we stress it again, so I'm not sure how much memory it's simply re-using in the background, and how much is actually leaking. Either way, it's somewhere deep inside reqwest and I can't do much about it. I would like to solved, eventually, as it is a serious issue if the API ever gets under very high load, but at the moment I can't seem to do much about it.

Allow players to rate courses they have completed, or to rate a map as whole.

We should use LAST_INSERT_ID() instead.

• Basic CRUD operations for Jumpstats
• Replays (#8)

The database supports storing gameplay "sessions".

These sessions are gameplay statistics reported by servers in regular intervals.
The API should implement a basic CRUD interface for these sessions.

We should keep track of server requests in a way that allows us to detect
inactive servers, whose keys we can then revoke. The server owner should be able
to re-generate that key again though, which means we have to make a distinction
between inactive and degloballed servers.

If we attach descriptions to course filters, those descriptions could be
displayed in a Web UI, or ingame with a !description command or similar.

These descriptions would include any of the following:

• justification for the tier
• justification for the ranking status
• notes about difficult parts
• links to videos showing the route, or how to land difficult jumps
• ...