Skip to content

Customizable account display names on the leaderboard #487

Description

@skysupersonic

Proposal: customizable account display names on the leaderboard

Problem

Accounts are identified everywhere by their BTC address, so the leaderboard,
account pages, and other surfaces show long raw addresses. A short, optional
display name would make these far more readable and give miners a bit of
identity on the board.

Proposal

Let an account set an optional display name, shown alongside its address
(never instead of it). Concretely:

  • Non-unique and cosmetic. The BTC address stays the account identity and is
    always rendered, so a non-unique name can't be used to impersonate.
  • Reuses existing auth. Names are set through the existing signed
    /account/metadata flow (BIP322 / wallet signMessage), which already proves
    address ownership — no new auth surface.
  • Opt-in. Accounts that never set a name are completely unchanged.
  • Respects privacy. Accounts marked is_private are excluded from the bulk
    name lookup.

Where it lives (two repos)

  1. para — the source of truth. Store display_name in the existing
    account_metadata JSONB (no migration), validate it on /account/metadata,
    and expose a bulk GET /names (address → name). Purely backend.
  2. parastats — the site. Mirror the name into the local monitored_users
    table on metadata update (exactly like is_public is mirrored today), join
    it into the leaderboard queries, render name-over-address in the board
    components, and add an owner-only "set name" field on the account page that
    signs via the connected wallet.

This keeps a single source of truth in para and needs no per-render HTTP
calls, since the leaderboard already joins monitored_users.

Open questions for maintainers

  • OK with names living in para metadata + mirrored into parastats SQLite, or
    would you prefer names owned entirely by parastats?
  • Name policy: proposed 24-char cap, trimmed, control characters rejected. Want
    anything stricter (profanity/homoglyph filtering, charset limits)?
  • Should there be a one-time backfill so names set on para before deploy show
    up without the user re-saving (e.g. via the stats collector)?

Offer

I have working patches for both repos ready to open as PRs (backend first, since
parastats depends on the display_name field existing). Happy to adjust the
approach based on your feedback before opening them.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions