Identity is a keypair

In a P2P system there is no "create account" endpoint. On first launch your app
generates a random secret, derives an Ed25519 keypair from it, and that is you:

• The public key is your global identity. You hand it out freely; peers use

it to verify everything you publish.

• The secret key signs your writes. Anyone holding it is you.

This is exactly how p2pbuilders works: each user is one Hypercore whose public
key is their identity. Nicknames are just advisory profile records — the key is
the name.

What this buys you

• Permissionless entry. Nobody can stop you from generating a key.
• Global verifiability. Any peer can check any record offline — no

authentication server in the loop.

• Pseudonymity by default. A key says nothing about you until you attach

something to it.

What it costs you

• No recovery. Lose the secret, lose the identity. There is no "forgot

password". Back up the key material (p2pbuilders stores it mode 0600 on
disk; the web build keeps it in local storage — export it).

• No revocation. A leaked key is a stolen identity. The best you can do is

publish from a new key and tell people.

• Sybils are free. Anyone can mint a million keys. Anti-spam has to come

from somewhere else — cost (proof-of-work), time (reputation aging), or
curation (blocklists). See Trust without a boss.

Practical rules we follow

1. One key per app, derived from one stored primary secret (Corestore does the

derivation — see the Corestore walkthrough).

1. Treat "the user typed a nickname" as decoration, never as identity.
2. Show short key prefixes in the UI, full keys on demand — people verify by

comparing prefixes out-of-band.