s8n/auth-limbo-v2
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
auth-limbo-v2/docs/MISSION.md
s8n 226bebadbd bootstrap: AuthLimbo v2 0.1.0-SNAPSHOT (design phase) 
Successor to s8n/auth-limbo following 2026-05-07 void-death incident.
Production-grade auth/login gatekeeper aspiring to 2b2t queue robustness
while explicitly avoiding pay-to-play / opaque-tier drama.

AGPL-3.0. Java 21. Paper 1.21.x.

Status: 0.1.0-SNAPSHOT, design phase. Architecture + roadmap docs land
from parallel research agents in subsequent commits.
2026-05-07 19:30:40 +01:00

3 KiB
Raw Blame History

MISSION

AuthLimbo v2 exists to gate Minecraft logins on a hardened, AuthMe-backed public server (racked.ru) without losing players, leaking metadata, or introducing pay-to-play drama.

Three invariants are non-negotiable.

1. Privacy invariant

  • No outbound telemetry. The plugin never phones home.
  • No third-party SDKs. Stats, analytics, crash-reporting — all out.
  • Local data stays local. Auth records, session tokens, and state files live on the operator's disk. The plugin never replicates them off-host.
  • Logs are minimum-necessary. UUID + event class. No IPs in normal logs (debug-only). No chat content. No coords beyond what the bug report needs.

2. Reliability invariant

  • No void deaths. A player who authenticates correctly must not die to gravity, void, or chunk-load races during the auth → spawn handoff. This is the bug v1 was written to patch (2026-05-07).
  • Login is a serialised state machine. No racing tasks. Every transition is logged with timestamp + UUID + state.
  • Failure modes are bounded. If the auth backend is down, players hold in limbo with a clear message — never get dumped into the live world half-authenticated.
  • Restart-safe. A mid-login player when the server stops must re-enter the same flow on next join, not be stuck in a half-state.

3. No-drama invariant

  • No paid priority. Ever. No queue-skip for money. See DRAMA-AVOIDANCE.md.
  • No opaque tiers. If the server has trust levels, the criteria are in the repo, in plain English, and earned not bought.
  • All policy changes via PR. Even operator-side. Anyone can read the history and see why a rule changed and when.

Operator

  • Operator: s8n (admin@s8n.ru)
  • Server: racked.ru (Minecraft Java, Paper 1.21.x, AuthMe-backed)
  • Brand: racked.ru is the gameplay brand; veilor is a separate security-company brand. Do not conflate. (See ai-lab memory project_brand_separation.md.)

Origin context

  • 2026-05-07: racked.ru void-death incident. AuthMe post-login teleport raced against chunk load → players spawned into unloaded chunks → fell into void.
  • v1 patch: F1 + F2 + F4 fixes landed in s8n/auth-limbo 1.1.0 (chunk-preload + delayed teleport + spawn-anchor verification).
  • v2 redesign: v1 worked, but the codebase was a rescue patch. v2 is the proper successor — reliability invariant baked into the architecture from line 1, not bolted on.

What "done" looks like for v2

A 1.0.0 release that:

  1. Has zero open void-death bugs and a regression test for each historical one.
  2. Survives a 200-concurrent-login storm test without dropping or dying.
  3. Carries a written security review of the auth path.
  4. Has an architecture doc that a new contributor can read in 30 minutes and understand the full state machine.
  5. Holds the no-drama invariant — no paid priority, no opaque tiers, policy changes via PR with reasoned commit messages.

When all five hold, we tag v1.0.0 and the design phase is over.