Identity & DIDs
Akshi uses Ed25519 key pairs and the DID:key format to give every node and agent a verifiable cryptographic identity. These identities are used for signing sync envelopes, authenticating mesh peers, and issuing capability attestations.
Node identity
When you run akshi init, the runtime generates an Ed25519 key pair and stores
it at:
$AKSHI_HOME_DIR/security/node_key.pem
The public key is encoded as a DID:key identifier using the multicodec
ed25519 prefix (0xed). This DID is the node’s identity on the mesh and in
sync envelopes.
Example: did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK
Agent identity
Each agent gets its own DID, deterministically derived from the node key and the agent’s name. This means:
- The same agent on the same node always has the same DID.
- Different nodes running an agent with the same name have different DIDs.
- Agent DIDs do not require separate key storage.
Capability attestations
The node issues signed capability attestations to its agents. These are local credentials that prove an agent is authorized to use specific host capabilities on this node. Attestations are not shared across the mesh — they are a local trust mechanism.
Where identity is used
| Use case | What gets signed/verified |
|---|---|
| Journal sync | Sync envelopes are signed by the sending node’s key |
| Mesh discovery | .well-known/akshi-node includes the node DID |
| Peer trust | Nodes verify peer DIDs before accepting sync data |
| Agent credentials | Capability attestations bind agent DID to allowed capabilities |
Key management
The node key pair is generated once and persists across restarts. There is no
automatic key rotation today. Protect the security/ directory — anyone with
the private key can impersonate the node.