DUXPLIMA Documentation

Concepts

Accounts and their kinds, names, the door, ways in, the lane, and what is kept where.

Accounts and kinds

An account is one name with one UUID. Its kind is how it gets in:

KindGets in by
crackedA password
premiumThe Mojang handshake, proving the name is theirs; a backup password when Mojang is down
bedrockFloodgate vouching through Xbox Live

A name is held once, in the case it was registered in: once Notch has an account, notch is refused with a message naming Notch.

The door

flowchart TD
  C[Connection] --> P{Protection: bans, limits, countries}
  P -- refused --> X[Kicked with a reason]
  P --> N{Name allowed and free?}
  N -- no --> X
  N --> K{Kind}
  K -- premium, proved --> IN[In]
  K -- bedrock, vouched --> IN
  K -- session from same address --> IN
  K -- cracked --> W[Waiting room: register or log in]
  W --> F{Second factor?}
  F -- yes --> CODE[Code] --> IN
  F -- no --> IN

Ways in

How a session got in is its method: password, registered, premium, bedrock, session, forced (staff) or network (the proxy vouched). %uxmauth_method% reads it, and the effects have a list per way.

The lane

Hashing a password is slow on purpose. Hashes run on a lane of their own, lane.threads at a time up to lane.max-threads, with lane.queue waiting; a login past the queue is told to try again in a moment rather than left hanging. Nothing the door does runs on the server's main thread.

Typed passwords stay private

A player command works for a player who has not logged in, and the password after it is kept out of the console and the log.

What is kept where

Accounts, sessions, address bans, factors, linked addresses, codes, the login history and a network's last servers are all in one database, so every member of a network reads them alike. See Database.

Related: Your first setup, Premium names