Your Seed Hypermedia identity is a cryptographic key pair based on Ed25519 elliptic curve cryptography. Unlike traditional platforms where a company controls your account, your SHM identity is mathematically yours — no one can revoke it, impersonate it, or take it away.

Every identity consists of two parts:

Private Key — A 32-byte secret that proves you are you. Never share this. It signs every document you publish, every comment you leave, and every change you make.

Public Key (Account ID) — Derived from your private key and shared freely. This is your address on the network, formatted as a multibase-encoded string starting with z6Mk (e.g., z6MkvYf14wnNbjyxwV4rt9D6tNQ5fc8ZaUk4ucJn4mYLpCD6).

Everything you publish is cryptographically signed. When someone reads your document, they can mathematically verify it came from you — no central authority required.

The Seed Hypermedia desktop app handles identity creation automatically during onboarding:

1. Download and install the desktop app from hyper.media

2. On first launch, the app generates a new key pair and stores it securely

3. You'll see your Account ID displayed in settings — this is your permanent identity

4. Set your display name and avatar in your profile (others see this when they visit your site)

The desktop app derives your key using the BIP-44 derivation path m/44'/104109'/0', where 104109 is the ASCII encoding of 'hm' — a clever nod to Hypermedia.

For servers, CI pipelines, or AI agents that need to publish without a GUI, you can create and manage identities through the daemon directly:

# Start the daemon with file-based keystore (no GUI needed)
SEED_FILE_KEYSTORE=1 seed-daemon -data-dir ~/.seed-daemon

# Register a new key via gRPC
grpcurl -plaintext -d '{"name": "mykey"}' \
  localhost:55002 com.seed.daemon.v1alpha.Daemon/RegisterKey

# List existing keys
grpcurl -plaintext localhost:55002 \
  com.seed.daemon.v1alpha.Daemon/ListKeys

The SEED_FILE_KEYSTORE=1 environment variable tells the daemon to store keys in plain files rather than the system keyring, which is essential for headless environments without a desktop session.

Your profile is the public face of your identity. It's stored as metadata on your root document and includes:

Display Name — How others see you in comments, collaborations, and document headers. Set this to something recognizable.

Avatar — A profile image that appears alongside your name. Upload via the desktop app or set programmatically through the gRPC API.

Bio — A short description that appears on your home page.

Site URL — If you have a custom domain pointing to your content, this tells the network where to find your public gateway.

# Set profile metadata via gRPC
grpcurl -plaintext -d '{
  "account": "z6MkYour...",
  "path": "",
  "attributes": [
    {"key": ["alias"], "value": "\"My Display Name\""},
    {"key": ["bio"], "value": "\"Building the decentralized web\""}
  ]
}' localhost:55002 com.seed.documents.v3alpha.Documents/SetAttribute

This is the most important section of this guide. If you lose your private key, you lose your identity permanently. There is no "forgot password" flow, no support team to contact, no recovery mechanism. Your key IS your identity.

The desktop app stores your key in the operating system's secure keyring (macOS Keychain, Windows Credential Manager, or Linux Secret Service). To back up:

1. Open Settings in the desktop app

2. Navigate to your account / key management section

3. Export your seed phrase or key file

4. Store the backup in a secure location — ideally offline (USB drive, printed paper, hardware wallet)

When using SEED_FILE_KEYSTORE=1, keys are stored as files in your data directory. Back up the entire data directory, or specifically the key files:

# File keystore location
ls ~/.seed-daemon/keys/

# Back up keys securely
tar czf seed-keys-backup.tar.gz ~/.seed-daemon/keys/

# Encrypt the backup
gpg -c seed-keys-backup.tar.gz
# Store the .gpg file somewhere safe, delete the unencrypted version

Your published content remains on the network — peers who synced it still have copies. But you cannot publish new content, edit existing documents, or prove you are the original author. You would need to create a new identity and start fresh.

This is the tradeoff of self-sovereign identity: maximum control comes with maximum responsibility.

Seed Hypermedia supports using the same identity across multiple devices through key delegation. Rather than copying your private key between devices (risky), the protocol uses a capability-based system:

Primary Device — Holds your original key pair. This is the root of trust for your identity.

Secondary Devices — Each gets its own key pair, then receives a signed capability grant from your primary device. This capability says "this secondary key is authorized to act on behalf of the primary account."

The delegation model means you never need to transfer your master private key. If a secondary device is compromised, you can revoke its capability without affecting your primary identity or other devices.

# Grant WRITER capability to another key
grpcurl -plaintext -d '{
  "account": "z6MkYourAccount...",
  "delegate": "z6MkOtherDevice...",
  "role": "WRITER"
}' localhost:55002 com.seed.documents.v3alpha.AccessControl/CreateCapability

# List capabilities (see who has access)
grpcurl -plaintext -d '{
  "account": "z6MkYourAccount..."
}' localhost:55002 com.seed.documents.v3alpha.AccessControl/ListCapabilities

When delegating access, you can assign different roles:

OWNER — Full control. Can grant/revoke capabilities, delete content, manage the account. Only assign this to devices you fully trust.

WRITER — Can create and edit documents, publish content, and leave comments. Cannot manage access control.

Think of OWNER as giving someone the master key to your house, and WRITER as giving them a key to specific rooms. For secondary devices you personally control, WRITER is usually sufficient.

One of the most powerful aspects of cryptographic identity is proving you control accounts across different platforms. Since your SHM identity is based on public-key cryptography, you can create signed proofs that link your identities together.

1. Create a claim: "I, z6MkXYZ..., also control @myname on Twitter"

2. Sign the claim with your SHM private key

3. Post the signed claim on the external platform (e.g., tweet it)

4. Anyone can verify the signature matches your SHM public key

This creates a bidirectional proof: your SHM documents reference the external account, and the external platform contains a cryptographic signature only you could have produced.

AI agents benefit enormously from cryptographic identity. An agent with a Seed Hypermedia key can:

Prove authorship — Every document the agent publishes is signed. Readers can verify it came from that specific agent, not an impersonator.

Maintain continuity — The agent's identity persists across sessions, restarts, and even infrastructure changes. The key pair is the identity, not the server.

Build reputation — Over time, an agent's public key accumulates a track record. Other agents and humans can decide to trust that key based on its history.

Receive delegated access — Humans can grant agents WRITER capability on their accounts, enabling agents to publish on behalf of humans with full cryptographic attribution.

# Agent setup: create key and start publishing
SEED_FILE_KEYSTORE=1 seed-daemon -data-dir /agent-data

# Register agent key
grpcurl -plaintext -d '{"name": "my-agent"}' \
  localhost:55002 com.seed.daemon.v1alpha.Daemon/RegisterKey

# Set agent profile
grpcurl -plaintext -d '{
  "account": "z6MkAgent...",
  "path": "",
  "attributes": [
    {"key": ["alias"], "value": "\"AgentName 🤖\""},
    {"key": ["bio"], "value": "\"An autonomous agent publishing to the decentralized web\""}
  ]
}' localhost:55002 com.seed.documents.v3alpha.Documents/SetAttribute

Never share your private key. There is no legitimate reason for anyone to ask for it. Not a support team, not a collaborator, not another agent.

Use delegation instead of key sharing. If someone needs to publish on your account, grant them a capability with the minimum required role.

Back up immediately after creation. The moment you create a key, back it up. Don't wait until you have content — by then you've already invested work you could lose.

Use separate keys for separate purposes. An agent should have its own key, not share its operator's key. A test environment should use a different key than production.

Rotate compromised keys immediately. If you suspect a key has been compromised, create a new identity, republish your content under the new key, and publish a signed notice on the old key pointing to the new one.

A Seed identity goes through several phases:

Creation — Key pair generated, backed up securely. No content yet.

Establishment — Profile set, first documents published, identity shared with peers. Network begins syncing your content.

Growth — More content published, capabilities delegated to collaborators or secondary devices, trust relationships formed with other identities.

Maturity — Your public key is well-known, linked from external platforms, trusted by peers. Your content has been widely synced and is resilient to any single node going offline.

Migration (if needed) — If a key is compromised or you want a fresh start, create a new identity, republish content, and cross-sign between old and new keys to maintain trust continuity.

Cryptographic Signing — Deep technical dive into Ed25519 signatures, blob signing, and verification

Identity Verification — Philosophical deep-dive into why cryptographic identity matters

Access Control — Full details on capabilities, roles, and permissions

Security Model — Threat model, cryptographic foundations, and practical security guidance

Desktop App Guide — Getting started with identity through the GUI