Dot - User

This is the user asset for TMC's Dot collection. It carries a player's profile between servers while making sure those servers cannot work out that it is the same person.

This collection of assets provides modular building blocks for creating games and applications within the TMC ecosystem, ensuring consistency and interoperability across all dot-* assets. This includes core functionality, networking, authentication, cloud integration, and more.

These assets are COMPLETELY OPEN SOURCE. You are free to use, modify, and distribute them under the terms of the MIT license. The only thing not open source is the back-end web infrastructure. So if you opt into using your own authentication backend instead of integrating with TMC, you will need to build and integrate your own back-end infrastructure.

From Maintainer & WARNING

This asset, along with all the others, was built initially with Claude Code and will continue to be maintained and extended using it. This is because I (gamemann) cannot build the entire TMC platform alone (I wish I could lol).

Please treat this as partially tested. Every asset has its own headless test suite and those suites pass, but very little of this has been in front of real players yet. Expect rough edges, and please report anything you run into.

I intend on reviewing code, testing, and editing documentation regularly. If you're interested in helping out, please let me know!

Profiles That Follow a Player

Player profiles that follow a person between servers, without letting those servers
work out that it is the same person.

Display name, avatar reference, preferences. Pluggable storage — a JSON directory, an
in-memory store, or an open HTTP backbone anyone can self-host. Resolved once on join,
cached, and never re-read on the hot path.

Part of the dot-* family. Requires dot-core. Works with
dot-auth, dot-server and
dot-user-avatar, and imports none of them.

Install

Copy addons/dot_user/ and addons/dot_core/ into your project and enable both in
Project → Project Settings → Plugins.

Use

var manager := DotUserManager.new()
manager.server_id = "eu-west-1"
add_child(manager)

# identity is anything with uid, display_name and is_guest — DotAuthIdentity,
# dot-server's DotGuestIdentity, or your own.
var resolved := await manager.resolve(identity)
if resolved.ok:
    var profile: DotUserProfile = resolved.value
    print(profile.display_name)

Nothing is imported and nothing is an autoload. DotUserManager registers itself in
DotRegistry as dot_user_manager, which is how dot-server and dot-user-avatar find
it.

The identity problem, and the answer

The natural key for a profile is the account id. Hand it to every community-run server
and any two operators can compare logs and reconstruct where a person has been. Nobody
has to be malicious; it is a property of the identifier.

So a server never sees the account id. It sees a scoped id:

scoped_id = base64url(HMAC-SHA256(key, scope + U+001F + account_id))[:22]

Stable for that player on that server, so bans and profiles work. Different on every
other scope, so operators cannot correlate. Not reversible, because the key never
leaves whoever mints identities.

A player who wants to be recognised across a set of servers opts into a shared
scope. A standalone server with no issuer generates its own key on first run and gets
the same isolation for free.

Three properties, and dropping any one makes it theatre: the key never leaves the
issuer, the derivation is a keyed MAC rather than a hash, and opting into a shared
scope is per-scope rather than global.

What is in the box

DotUserScope	The derivation above, plus verification and key persistence.
DotUserName	Display-name sanitising and validation. The hostile-string layer.
DotUserProfile	The record. Bounded, versioned, migratable, with a public subset.
DotUserStore	Where profiles live. Memory, Local (JSON files), Backbone (HTTP).
DotUserManager	Resolve on join, cache, write back, rename, rate-limit.
DotUserConfig	Layered: exported defaults < JSON < DOT_USER_* < --user-*.

Display names

A display name is the most hostile string a platform accepts — it is shown to every
other player and chosen by the person it is shown for. DotUserName strips
bidirectional overrides, zero-width characters, stacked combining marks and control
characters, collapses whitespace, and refuses names that are empty, over-long, or made
entirely of punctuation.

It says nothing about whether a name is offensive. That is a policy question with a
different answer in every community, and DotUserManager.name_filter is the hook.

By default an authenticated player cannot rename themselves — their name comes from
their account, and a player who can override it can appear as somebody else. Guests
have no account name, so they can pick one.

Storage

DotUserStore follows the same two rules as dot-server's ban store, for the same
reasons:

• Loads may be slow; lookups on the join path may not. A resolved profile stays
  cached after the player leaves, so a map change does not re-read for everyone at
  once.
• A failed read never destroys a profile. If the store cannot answer, the player
  gets a session-only profile that save() refuses to persist. Writing a fresh one
  would overwrite the real profile on disconnect — a network blip turned into data
  loss.

Validating

godot --headless --path . --import
godot --headless --path . res://examples/user_demo.tscn     # 137 checks

Exits non-zero on failure.

MIT licensed.