[Feature] Add SourceBans to profile information

[MaxOhNoo]

A useful addition to profile information would be SourceBans. MAC could search through public ban lists with a user's steam ID, like what https://steamhistory.net does.

https://www.skial.com/sourcebans/index.php?p=banlist
https://sourcebans.gflclan.com/index.php?p=banlist
https://bans.scrap.tf/index.php?p=banlist
(and many more available with some basic research)

[MaxOhNoo]

Given how complex this would be, I'm going to try to get this working by itself and hopefully come back with at least part of a pull request.

[lili7h]

IMO, since this is simply presented in profile information when viewing someones profile (i.e. the player details modal or something), i think the following would be needed for an intro implementation:

• A preferences item in the client preferences to toggle SourceBan lookups (using steamhistory's API)
• A dispatcher that asynchronously batches and sends API requests for groups of players to the proxied steamhistory.net endpoint that masterbase will host
• A processer group to read in the response results and append data to the PlayerRecords
• A cache kind of like the steam user cache to cache SourceBan results in (I think more than 3 hours is fine, since SourceBans is slower, maybe a day? 7 days?) (this is for improving performance)
• A modification to the API spec to allow the backend to ship this data back to the frontend. The hacky way is to ship it in the customData field for Player Records. Realistically these additions are what the customData field was designed for

And for the frontend, we would need:

• Modifications to the player objects to house SourceBans information
• Modifications to the API response handlers to extract SourceBans information from the customData field
• Modifications to the player information modal to display the SourceBans information

Decisions that need to be made:

• A concrete specification on how to provide the SourceBans information to the front end. I.e. what format does it appear in the customData field? It has to be JSON, and has to be consistent and well-documented.

This is not a small task, and requires front-end integration for work. Tbh this should also be paired with work needed doing on the front end to integrate other preference items into the preferences panel.

[lili7h]

I should note: design philosophy has it as the requirement that the Back end is the one making these API requests. So hacking the information into just the front-end presentation layer is not acceptable, at least for the main repo. The front-end should only ever interact with the associated client-backend and never to the internet.

Further it should be heavily considered how these API requests are batched and sent, because players can join a server with upwards of 99 other players on it, and we don't want to be slamming out 99 requests per SourceBans API. So a batching mechanism, if the API supports it, would be amazing. Otherwise, we would need a backoff or maximum amount of requests per time period mechanism.

The above is also why I deem it mandatory that there be an associated toggle option for the SourceBans info, and that its opt-in, not opt-out. (Default to NO)

[lili7h]

Happy for other dev input on the usefulness of this Feature Request, and on my above checklist

[kavorite]

https://steamhistory.net/ turned out to be an exciting lead. I contacted its author and maintainer, @0x000015, requesting comment on this issue.

It turns out they stood up an API specifically in anticipation of use-cases like ours, saving us the effort of indexing all the TF2 servers hosting source bans on the server browser and warehousing that data ourselves. Alternatively, it spares community server maintainers the pain of being burst with 24 Steam ID requests every time a MAC user joins a new session and getting DDoSed by everyone running MAC.

The only stipulation is that we use some intermediate centralized broker to cache the results. Hence, I've created a tracking issue in the MB repo: MegaAntiCheat/masterbase#75. Re: Lilith's implementation outline SteamHistory eliminates the need for any configurable list of SB servers by providing a pretty comprehensive aggregation of source bans from popular community hosting providers. Requests to SH can be proxied (and transparently cached) via masterbase.

[kavorite]

Re: the updates to the checklist, @lili7h, I don't mind the client having a local TTL for any given player's results from the MB; we could return the age of the cached data from our endpoint to set it dynamically if you prefer.

I also found an example JSON response on the SH API's index page that I'm copying here for completeness. I won't bother formalizing it; we aren't exactly developing a compiler here. The data should be pretty homogenous, with most deviations indicating error cases.

{
 "response": [
  {
   "SteamID": "7656XXXXXXXXXXXXX",
   "Name": "Username",
   "CurrentState": "Permanent",
   "BanReason": "Hacker",
   "UnbanReason": null,
   "BanTimestamp": 1685513965,
   "UnbanTimestamp": 0,
   "Server": "Skial"
  }
 ]
}

[kavorite]

@lili7h I've received additional clarification from @0x000015. SteamHistory's backend is much better optimized to handle distributed requests than the Sourceban web server implementation as long as we batch them properly, so centralizing the cache isn't as pressing of a need as first anticipated. XVH says they'll advise us to implement MB#75 if there are any issues supporting our throughput.

[lili7h]

Tracking this feature request in branch feat/SourceBansInfo