MC Speedrun Possible Future Verification Strategies

__**Possible Verification Strategies (so far)**__:
**0. Reject if no seed in the description. This is obvious but I'm putting it here to be exhaustive about the verification process.**

**1. Easy to find rule breaks. These should be checked for every run\*:**
- Shaders: Look at any run footage.
- UHC Ores?: Might require some digging into the run which is why I'm unsure.
- Resource Pack?: Not as easy to check as the others since it requires evaluating if the resource pack is reject worthy.
- World Generation: Look at the start of the run.
- Gamma: Look at any "brightness 0" part in the run.
- Badlion: Look at any run footage.
- Forge: Done by checking the title screen version.
- Past broadcast: Done by checking Twitch.
- /time set 0: Done by checking the start of the run. Note that we could allow this by just retiming to world load, but it would mean more runs to verify :admirAAAAAAAA:
- Co-op time end: Done by checking the end of the run.
- Not doing first input timing on world load timing: Done by checking the start of the run.
- If the category actually completed its objective (would be much more relevant for catexts): Dependent on category, usually involves checking the end of the run.
\* Possible exclusions:
- Unconditional auto-verify runs: may just not be worth it, although it would be good to teach the player about the rules.
- Co-op runs: Apart from Badlion, Forge, and time start/end, client side checks might not be worth (mainly thinking about gamma, since unless if the other runners provide POV it's impossible to tell)

**2. Auto-verification cutoffs. Currently, the following cutoffs we have are:**
- All RSG categories, including Co-op: auto-verify if the run is equal or longer than 1:30:00
We can probably lower the cutoffs, as well as add SSG cutoffs. Probably don't add cutoffs for the really inactive categories (AA, AAdv, any glitched category except SSP)

**3. Trust requirements:**
We can also probably lower the cutoffs for "trusted/familiar" runners, as in runners which have more runs. This is the most complex strategy and would require verifier discussion (and possibly even community suggestions). Here are some examples to determine trust/familiarity:
- Number of runs in the specific category
- Whether the run was streamed
- Total runs done of minecraft
Some options might require some database/custom SRC client for verifiers to look up this info. Note that this would not apply to very good runs, but we would need to establish what counts as a good run (e.g. based on time/rank).

**4. Dealing with hard to spot rule breaks, as in rule breaks which require watching the entire video to prove that they did not happen:**
This is something we might need to accept in order to get through the queue. We could also tie these specific rule breaks into 3. to determine whether we can auto-verify.
- Difficulty changing
- UHC ores? probably not that hard to find but maybe
- Accessing Structures in No Structures
- Optifine Zoom
- possibly some obtain multiple item catexts where there is no requirement to show inventory at the end of the run. An example would be in all minerals where when the runner picks up the final mineral, you cannot see all minerals in the hotbar, and the runner doesn't open their inventory after time end. In this case, you would not be able to auto-verify a run like this, as there is no guarantee that the runner actually achieved the goal). We could potentially require "Obtain Multiple Item" runs to show inventory at the end if the items are not in the hotbar, or give timestamps to each item picked up (although the latter does not prevent the case of tossing the item).

**5. Only verifying most recent PB**
- Due to SRC's """feature""" of only displaying the 50 oldest runs in the queue, this would require a custom SRC client to actually see all the runs in the queue
- Question: Should 1. be applied to "obsolete" runs?
- Probably should require verifiers to add a note that the run was auto-verified based on obsoletion (in case someone notices something about the auto-verified run, the auto-verified mark would be a defense against lazy verification *cough April*)

**6. Alternatives:**
- "Randomized" verifying, as in, decide to verify a given run based on a percentage, possibly depending on the time/rank and other factors.
- Partial video viewing for "mid-tier" runs, e.g. between 40:00 and 1:00:00 only watch first and last 10 mins

**Additional Notes:**
- "Who cares about Category Extensions?" (Looking at you, April) While they aren't as important as the main boards, they're still an important part of the community and culture. Many of the categories are interesting in the runs they produce, and a lot of good routing, addition to the knowledge base, and seedfinding has come out of them. Category Extensions should be at least tried to be taken seriously in terms of verification before we decide to make concessions greater than the main boards against them.