auth-limbo-v2/docs/DRAMA-AVOIDANCE.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.2 KiB

DRAMA-AVOIDANCE

Explicit ethics statement for AuthLimbo v2 and any server using it.

The Minecraft public-server space is full of failure modes that aren't technical — they're social. This document pins down what this project will and won't do, so that future operators (including me, six months from now, tired) don't drift.

Hard rules

NO paid priority queue. Ever.

  • No "skip the queue for $5/month."
  • No "VIP slot reservation" tier.
  • No "donor instant join."
  • The queue is FIFO. Period.

If the server is full, everyone waits the same way. Operators may reserve slots only for documented administrative purposes (moderation, emergency response) and those slots are listed in the repo with named holders.

NO opaque veteran tiers

  • No hidden "respected player" perks.
  • No mod-discretion permission grants without a written rule.
  • If the server has trust levels (e.g. build access, /tp privileges), the criteria are:
    1. Documented in the repo (e.g. docs/TRUST-TIERS.md if/when it exists).
    2. Earned via measurable, public criteria (hours played, no warns in N days, etc.).
    3. Auditable — anyone can ask "why does X have rank Y?" and the answer is in the data, not a vibe.

All exploits / known-bugs in CHANGELOG

  • Every CVE-class issue gets a ### Security block with the date it was discovered, the date it was fixed, and the commit hash.
  • We don't memory-hole bugs. Drama feeds on hidden history.

All policy changes via PR

  • Operator-side rule changes (whitelist policy, kick rules, etc.) that touch the plugin's behaviour go through a PR with a written reason in the commit message.
  • "Why was this added?" must always have an answer in the git log.

Reproducible builds

  • mvn -B clean package from a tagged commit must produce a jar that matches the published artifact's sha256.
  • Tags carry a release note in CHANGELOG.md with the expected hash.
  • No "trust-me-bro" jars. If you can't reproduce it, you can't audit it.

Soft rules (norms, not constraints)

  • No callouts. When a player misbehaves, log + ban. No public shaming threads.
  • No "exec lounge" channels. Mod chat exists for moderation, not for a clique. Anything that smells like an in-group should be questioned.
  • Operators are accountable, not entitled. Running the server is a job. The community doesn't owe them deference.

What this means in code

  • The plugin will never expose a permission node like authlimbo.priority or authlimbo.skipqueue.
  • The plugin will never read a "donor" flag from any external service.
  • The plugin's queue ordering is purely arrival-time + admin-reserved. No other inputs.

If you find yourself adding a feature that violates one of these, stop, write up the use-case in an issue, and let the community push back before merging. The drama-avoidance invariant is more important than any single feature.

Why this document exists

Because every Minecraft community that fell apart did so because nobody wrote down what the project would not do. This is that document. It is binding on this codebase. Forks may diverge — and because the project is AGPL-3.0, those forks must publish their divergence and the reasons.