Safety & fairness
TSPML's safety stance is warn-only and deliberately honest: label what mods touch, disclose the risks in plain language, and never claim protections the platform can't actually provide.
Trust model: mods are code
A mod is JavaScript running unsandboxed in the portal page, at the same trust level as the page itself. The capability labels in mod.json (dom, storage, network, physics, multiplayer) are consented-advisory, not enforced: in a same-realm JavaScript page, a mod can always reach window and fetch no matter what object it was handed. True isolation would require SES lockdown plus a membrane, and until/unless that ships, TSPML refuses to advertise an "enforced sandbox" it doesn't have.
The practical rule, stated everywhere it matters: only add mods you wrote or trust, exactly like installing software.
Two portal features support that judgment without replacing it:
- The source button on every mod card shows the exact stored manifest, code, and mixins. What you see is what runs.
- The origin line on every card shows where the mod came from: the URL it was imported from, or "pasted".
Share links are confirm-first
A share link (?mods= parameters in a portal URL) carries mod URLs only, never code, and opening one never auto-runs anything. The portal lists every URL the link carries and does nothing until you click Import. Each link is re-validated against the import rules before it's even shown; refused links are displayed with the reason rather than silently dropped. This is deliberate: a link that silently installed code would be a drive-by, and the confirm list is what stands between you and one.
Fairness: warn-only labels
Every mod is classified:
| Class | Treatment |
|---|---|
| Cosmetic / local (HUDs, sounds, keybinds, local tracks) | Always fine |
| Physics-affecting (touches the sim or timing) | Flagged |
| Multiplayer-affecting | Flagged |
TSPML labels and discloses; it does not block. The reasoning: client-side gates on an untrusted client can't stop a determined cheater anyway, and pretending otherwise is theater. The real defense (server-side replay validation) belongs to Kodub.
The ban-risk disclosure
PolyTrack's leaderboards validate runs as deterministic input replays, and Kodub has stated server-side anti-cheat is in development. A physics or speed mod can trivially break replay validity, and uploading such runs risks leaderboard bans. TSPML puts this in the docs, the mod panel, and anywhere a flagged mod surfaces. Upload modded runs at your own risk; with vanillaSafe: false mods, preferably don't.
Failure containment (the safety that IS enforced)
What TSPML can guarantee mechanically, it does:
- Per-mod isolation. A mod that throws at load, in a listener, or during unload is caught and reported; other mods and the game are untouched.
- Per-patch isolation. A failing mixin fails one patch of one mod, with a named reason.
- Fail-closed patching. A mappings/bundle mismatch means no patches, never mis-targeted ones; if the base transform can't apply, the portal serves the vanilla game and says so.
- No cross-user surface. Your mods and patch plans exist only in your browser; the server never stores user code.
Legal / ToS posture
- TSPML ships loader, mappings metadata, and mod tooling only, never the game. The portal fetches each user's live copy and transforms it in memory.
- Running a modified client remains a ToS gray area; Kodub has not stated a position. The docs say this plainly rather than hiding it.
- Takedown policy: on any request from Kodub, the project pulls the affected pieces and cooperates. TSPML positions itself as a fan tool that protects leaderboards (honest labels, disclosure-first) rather than an adversary.