Names, identity, the number on the felt, chip styles
A design note, not a decision. Written 2026-09-06 from feedback hotel-oscar-25 (P-numbers and naming),
quebec-whiskey-46 (the account number set into the felt) and foxtrot-delta-81 (chip styles, token metadata).
Nothing on the board changed for this page except what's already listed in the change notes.
1 · "P3" — can players name themselves today?
Half of it exists. The join message already carries a name: join(gameId, playerToken, playerName, intentPublicKey) stores game.players[token].name, and the state broadcast sends playerName back out. But the frontend always sends "anon", there is no rename message, no form, and no rendering of the name — every surface prints the P-number. So: the wire supports a name at join; nothing lets a person set one or change one.
Two small pieces would make it real: a game_setPlayerName socket message (actor = the token's owner, validated length/charset, stored on the player), and a field in Profile. Rendering follows for free wherever playerName is already read.
What to show meanwhile
You were on the fence, and I'd keep the P-number for the closed test group exactly as you said — it is a debugging handle everyone in the room shares ("I'm P4"). The one change worth making now is in your own account modal: "P3 · (you)" reads oddly when you are the only reader of that line; "You" alone is enough there, and the P-number can live in the tooltip. Other players' cards keep the P-number until names exist.
What a name is, once it exists
Your question was the right one: a typed name is an avatar name — a label the player chose, attesting nothing. That is fine as long as the UI never lets it look like more. Three tiers, rendered differently so they can't be confused:
| Tier | Comes from | Attests | Show as |
|---|---|---|---|
| Chosen | the player types it | nothing — "call me Sam" | plain text, no mark |
| Bound | the account's key signed the binding (what Authenticate does today) | this browser controls account 0.0.x | the account id, ◆ mark |
| Verified | a domain proof for the account (xproof: a record the domain owner publishes naming the account) | the domain vouches for the account | the domain, ✓ mark, link to the proof |
The confusion you described — one player, several accounts, an organisation's account controlled by one person, multi-sig — resolves if identity always hangs off the account, never the player. A player is a seat at the table; the accounts are what sit in it. A seat can be labelled with a chosen name; an account can carry a verified one. When a player has one account (most people), the account's label is the natural thing to print on the seat. When they have several, the seat shows the chosen name (or the P-number) and each account keeps its own label. Multi-sig changes nothing here: the account is verified or not; who holds the keys is the account's business.
What Hedera offers (a survey, not an endorsement)
| Mechanism | What it gives | Fit |
|---|---|---|
| xproof (already integrated) | A domain publishes a signed statement naming an account; anyone can fetch and re-verify it. Verified-name tier above. | Best fit for organisations and merchants. The xproof site is currently down (feedback df07837d); the labelling should say "verified via xproof" only when the proof resolves live. |
HIP-27 / Hedera DID method (did:hedera:…) | Decentralised identifiers anchored on HCS, with a DID document (keys, service endpoints) and optional verifiable credentials. | The formal route. Heavy for a game: needs a resolver, credential issuers, and a story for who issues what. Worth knowing exists; not a first step. |
| Account memo (100 bytes, on the account entity) | Free text the account's key set. Some wallets show it. | Cheap self-description, but anyone can write anything — a chosen name at best, with the twist that it's on-chain and costs a transaction to change. |
| HCS profile topics (the pattern HashPack/Kabila/Hashinals use: a topic per account holding a JSON profile — name, avatar, links) | A public, mutable profile the account controls. | Closest to "wallet-level display name". Convention-based, not a HIP; several dialects. Reading a known dialect when present would let a player's wallet name appear without us storing anything. |
| Token metadata (HIP-412 NFTs, HIP-405/HIP-646/HIP-765/HIP-766 fungible & collection metadata) | Name, symbol, image, description, properties per token/collection. | Identity of assets, not people — see §3. Not a person identity mechanism. |
| Gaming convention | Games almost universally separate gamertag (chosen, unique-per-game) from account (auth). Uniqueness is enforced per game, changes are rate-limited, and impersonation is handled by marks, not by forbidding names. | Matches the tier model: chosen names are free and unremarkable; marks are what carry trust. |
Suggestion. Ship chosen names (small; the plumbing is half there), render the three tiers with three distinct marks, and treat verified names as an account attribute sourced from xproof when its proof resolves. Leave DIDs and HCS profiles as "read if present, never require" for later.
2 · The account number, set into the felt
Three treatments, drawn at roughly the proportions of a phone segment. The digits are 3833789 in every one; the idea is that you recognise the shape of the number the way you recognise a card's suit, without reading it.
Implementation sketch for A/B: an SVG <text> per wedge in the board's own layer, beneath the chip layer, clipped to the wedge path; font-size from the wedge's chord at mid-depth; two or three rows; fill-opacity the only knob. Later, a verified account swaps the digits for its mark or name in the same slot. All three could go behind a URL switch (?felt=a|b|c) for a live look.
3 · Chip styles, and what token metadata can supply
The "tall" shape is live behind a nerd switch (B05). Here are the candidates side by side, then what the token itself could contribute.
| Style | Idea | Trade-off |
|---|---|---|
| Pill (today) | amount then symbol, one line | Widest; the amount, not the asset, is what you read first. |
| Tall (B05, lab) | symbol over a muted amount | Squarer target, asset-first. Costs height in a crowded wedge. |
| Icon + symbol | a token icon (from metadata) before the symbol; amount muted | Recognition at a glance once icons exist; needs a fallback glyph for the many tokens without one. |
| Owner sleeve | the existing owner colour as a thick left edge; symbol bold, amount plain | Already half-there (the "Owner colour" chip style); combines with any of the above. |
| Dark face | charcoal chip, white symbol, grey amount | Highest contrast on the felt (the existing "Dark" style); pairs well with tall. |
A chip template
Every chip is already built in one place (makeAssetEl). A template is a small function (asset, amount, owner) → DOM registered by name; the body attribute picks which one runs, and a token could name a template in its metadata. Nothing exotic is needed to get there — the tall shape is exactly that pattern in miniature. People designing their own chips later is a matter of letting a template be loaded from a URL, sandboxed to markup and CSS.
What the token can tell us
| Standard | Fields worth reading | Use on a chip |
|---|---|---|
| HIP-412 (NFT metadata JSON) | name, image, type, properties, attributes[], localization | Art (already used), and properties is a free-form object where a collection could carry a chip hint — colour, template name, badge. |
| HIP-405 / HIP-646 / HIP-765 / HIP-766 | metadata for fungible tokens, NFT collections and non-fungible classes: the same JSON shape pointed to from the token's metadata field | A fungible token's image → the icon in "Icon + symbol"; properties.brand style hints if a token sets them. |
| Token entity | symbol, name, decimals, memo | What we use now. memo is occasionally a URL or a brand line. |
Suggestion. Define the chip hint as properties.katomia.chip = { template, colour, icon } inside the token's HIP-412-style metadata, read it when present, and provide three built-in templates (pill, tall, icon). A token issuer then styles their own chips without us shipping anything per token — and a token with no hint looks exactly as it does today.
Reply to the "select vs expand" note (charlie-lima-48): tapping anywhere on a row selects in the add-account list and expands in the account modal. The honest alignment would be an explicit eye control in both and tap-to-expand in both — but the add list has nothing to expand into yet, so the difference is real, not accidental. Left as is, per your instruction.