Auth Model and @anomaly IDs

Anomaly authenticates a persistent client identity before gameplay. The server derives a local enrollment ID and exposes the full value through normal LabAPI user-ID surfaces.

Server-local scope

The same client identity produces a stable ID on one server while producing a different ID on another server. This prevents a single public identifier from becoming a cross-server tracking handle.

Players retrieve the current server’s ID only after authentication by running anomaly.whoami. The client clears it on disconnect. The Launcher’s identity_public fingerprint is not an enrollment ID.

Accepted identity and rotation

On first contact the server atomically records the accepted client leaf and sequence. Later joins accept only:

• The exact accepted leaf.
• A contiguous signed advance that contains the accepted leaf.

Rollback, skipped lineage, and competing forks are rejected. Losing an identity without a valid rotation path creates a new server-local enrollment.

Moderation and permissions

Use the complete value ending in @anomaly in bans, allowlists, remote-admin mappings, and player-scoped persistence. Existing Steam mappings do not automatically migrate.

Do not ask players for user.json. For support, use the ID shown by anomaly.whoami and server authentication logs.

Duplicate sessions

When duplicate accounts are disabled, Anomaly follows the vanilla replacement behavior: a newly authenticated connection replaces the older session for the same enrollment. Disconnect cleanup removes a mapping only when it still belongs to that session, preventing an older disconnect from deleting the replacement.

Password status

Remote shared-password joins are not supported. RequirePassword=true rejects remote clients; only an explicitly enabled loopback compatibility mode exists for local testing.

Identity is not a permission

An @anomaly ID identifies an enrollment on this server. It grants no role or permission by itself.

Continue to Asset Distribution and Late-Join Behaviour.