Identity

Identity is the foundation. Without it, an agent is a stateless function — no memory persists, no trust accumulates, no governance applies. Motebit gives every agent a cryptographic identity that exists independently of any intelligence provider.

The identity model

A motebit identity is a persistent, unique identifier — timestamped, sortable, and owned by you. It's created once and persists across key rotations, devices, and providers. It doesn't expire or depend on a server. Keys can be rotated via signed succession records — the motebit_id stays the same.

The identity belongs to its owner, not to a service provider. Switch AI providers, switch devices, shut down the relay — the identity endures.

Cryptographic keys

Each device that hosts a motebit generates an Ed25519 keypair. The private key is stored in the operating system's secure keyring — it never touches the filesystem, never leaves the device, and never gets sent over the network. The public key is shared with services that need to verify the agent's identity.

Ed25519 was chosen for its speed, small key size, and resistance to timing attacks. It's the same signature scheme used by SSH, Signal, and WireGuard.

Multi-device

A single motebit can span multiple devices. Each device registers independently with its own keypair. Your motebit exists on your laptop, phone, and any future device — same identity, same memory, shared state.

When a device needs to communicate with the sync relay, it signs a short-lived token (5-minute expiry) with its private key. The relay verifies the signature against the registered public key. No passwords, no API keys stored server-side — just cryptographic proof.

First launch

On first launch, the app walks you through identity creation:

1. You consent to creating an agent identity
2. A keypair is generated and the private key is stored securely
3. Your motebit identity is created
4. Your device is registered
5. Optionally, the device connects to a sync relay for multi-device use

On subsequent launches, the identity loads from storage and the keypair from the keyring. No network round-trip required.

DID interoperability

Every motebit Ed25519 public key can be expressed as a W3C did:key — a self-resolving Decentralized Identifier that bridges motebit to the broader identity ecosystem (Verifiable Credentials, DIDComm, MCP-Identity).

The derivation is deterministic: same key, same DID, no registration needed. The did:key is computed automatically during verification and exposed in capability advertisements.

did:key:z6Mk...  ← derived from the same Ed25519 public key in motebit.md

This means any system that understands W3C DIDs can verify a motebit agent's identity without knowing anything about the motebit protocol.

Key rotation and recovery

Keys rotate via dual-signed succession records — both the old key and the new key sign the canonical payload, proving the old key authorized the rotation and the new key accepted it. The motebit_id stays the same. Any verifier can trace the chain from genesis key to current key without trusting any intermediary.

If a key is compromised and you haven't set up succession, generate a new identity — same model as SSH keys. Back up ~/.motebit/ to preserve your identity, memories, and audit history.

What this enables

• Proof of identity — Any service can verify that a message came from your motebit by checking the signature against the registered public key
• Multi-device — Your motebit exists across all your devices with the same identity and shared state
• Relay independence — The identity doesn't depend on the relay server. Kill the relay, the motebit continues. Switch relays, the motebit follows.
• Audit trail — Every event is tagged with the agent and device that produced it, creating a verifiable history
• Key recovery — Rotate keys without losing identity. If no succession is set up, generate a new identity — same model as SSH keys

Organizational custody (enterprise)

For enterprise deployments. Individual users can skip this section.

Enterprise agents can declare a guardian — an organizational Ed25519 key held in cold storage. The guardian enables key recovery when the primary key is compromised, employee departure workflows (rotate the agent to a new operator while preserving trust history), and organizational trust baseline in routing.

Guardian revocation requires dual authorization — both the identity key and the guardian key must sign. Neither party can unilaterally dissolve the custody relationship.

Sovereign agents (individuals) omit the guardian field entirely. Full sovereignty, no organizational dependencies. See the identity specification §3.3 for the full guardian protocol.