zk
e363bd2532
* docs: migrate from mkdocs to mdbook - Rename old mkdocs docs/ to old-docs/ for reference - Set up new docs/ with mdbook (book.toml + src/ tree) - Mirror full nav structure from mkdocs.yml into SUMMARY.md - Add Justfile-docs with docs-serve, docs-build, docs-check, docs-install recipes - Import Justfile-docs from root Justfile - Rewrite .github/workflows/docs.yml: build step uses taiki-e/install-action to install mdbook, split into separate build + deploy jobs, PR builds run the check step too * ci(docs): pin actions to SHAs, install mdbook via release binary * ci(docs): install mdbook from apt instead of curling a release binary * dev: replace mkdocs python stack with mdbook in dev image * ci(docs): apt only works on Debian; restore release binary install for Ubuntu CI * docs: fix duplicate file entries in SUMMARY.md * docs: remove docs-install recipe * docs: remove site-url from book.toml to fix asset loading * dev: install mdbook from upstream release binary, not Debian apt The Debian package (0.4.x+ds) strips bundled font assets, leaving the built site without fonts/fonts.css. Use the upstream tarball (same as CI) so the theme is complete. Handles x86_64 and aarch64. * docs: vendor mdbook tarballs in dev/mdbook/, install from there Dockerfile.dev uses COPY + tar to install the right arch at build time. CI extracts the x86_64 tarball directly from the checkout. No network access required for either — and no stripped-fonts Debian package. * fix: unwritten
1.3 KiB
Score ID implementation
Score IDs exist to dedupe scores when a user re-submits
the same scores. This happens frequently with file/
and api/ Import Types,
as they typically resubmit the same scores.
If a user only got a score once, we don't want to store it twice.
Sadly, we can't depend on things like timestamps to assert whether or whether not we've saw a score before. Many services alter/tamper their timestamps such that they're unreliable.
!!! example E-Amusement IIDX CSVs will change the timestamp of every single score when a new version comes out to the second the user created their new account.
Hashing
The score ID is created by joining the following properties:
- The
userIDthat got this score - The
chartIDthat this score was on - All Provided Metrics for this GPT
- Any Optional Metrics that have been marked as
partOfScoreID
and then hashing them with SHA256.
This is then prefixed with T, and returned.
Clobbering
Since a scoreID isn't necessarily all of the possible statistics for a score, it's possible for users to "clobber" their scores, by importing a score without as many pieces of info (i.e. no judgements), then trying to import that same score with judgements later will not work, as the scoreID sees it as a duplicate.
See Clobbering.