LibertyNetLibertyNet para desenvolvedores
Ainda não traduzidoEsta página ainda não foi traduzida para Português, então você está lendo o original em inglês. Não falta por ser sem importância — apenas ainda não foi escrita. Contribuições são bem-vindas. Ajude a traduzir esta página

Dashboard

Your operator account and the live network, with every identity verified in your own browser.

A small web app showing what your operator identity looks like through the public API, and what the network looks like right now.

bash
cd dev-portal/dashboard
npm install && npm run dev      # http://localhost:3000
Nota

Not deployed. It builds to a static export with no server component, so it can be hosted anywhere — but choosing a host and a domain is a decision for the project owner, not something to do silently as part of a documentation change.

Pages

PageShowsNeeds a session
OverviewRegistered / verified / online / failed countsNo
NetworkEvery node, with a fingerprint and computed freshnessNo
My nodesNodes bound to you, with their agreed limitsYes
CreditsThe balance envelope, with its source fieldYes

Everything not marked "needs a session" works without signing in — discovery is public.

There is no API key manager

Aviso

LibertyNet has no API keys.

Discovery needs no credential at all. Operator access is a signature-based challenge–response that yields a 1-hour session token. There is no key to issue, nothing to store at rest, and nothing to rotate.

A key-management UI would have meant inventing a concept the network does not have, and teaching developers to hunt for a key that does not exist. So there is not one.

What the usual security requirements were protecting against is handled structurally instead:

RequirementHow it is met
Keys never reach the frontendThere are no keys.
Keys never reach logsThere are no keys.
Encrypted at restNothing is stored at rest. The session token lives in memory only.
Resistant to credential stuffingNo password exists to stuff. Authentication is a signature over a single-use, 300-second challenge.

What happens to your private key

  1. It stays in your browser

    Used once, in the tab, to sign one challenge. Never transmitted.

  2. It is zeroed immediately

    Whether the login succeeded or failed.

  3. It never appears in an error

    Failures report a message and nothing else — a key in a stack trace is a key in your error reporter.

The resulting session token is held in React memory: not localStorage, not a cookie, not sessionStorage. A page refresh signs you out, which is deliberate — anything persisted is readable by every script on the origin and survives into profile backups. A one-hour token is not worth that exposure.

The Credits page is careful on purpose

The credits endpoint returns 200 with a body that looks exactly like a balance, and every number in it is 0. Não conectado

So the page shows the caveat and greys the figures rather than presenting them as measurements — because a 0 rendered next to the word "earnings" is a lie told through a number. It also prints the raw response, so you can check the page against what the API actually said.

Why Credits work this way →

Relationship to the Operator Console

Different jobs, deliberately not merged:

Purpose
Operator ConsoleThe end-user product for node operators: identity creation, mnemonic recovery, device binding, multi-account vaults. Manages keys.
Developer DashboardThe developer view: what my account looks like through the public API, what the network looks like, what is actually wired. Manages nothing.

To bind a node, use the Console. This dashboard deliberately does not implement binding — the signing involved should not be reimplemented.

Verify it yourself

Every identity the dashboard displays is checked in your browser, against the same arithmetic you can run by hand:

bash
node examples/verify-network/verify.mjs
# → 27/27 identities verified

If the dashboard and that script ever disagree, trust the script and tell us.