Your computer, a cloud vault
A host stores encrypted shards it cannot read. It only needs to do five things, and a compromised agent still leaks no usable data.
Five operations
Reports liveness and capacity every 60 seconds. Missed beats pause new placements.
Receives an encrypted blob under a random identifier. No filenames, no owners, no types.
Returns a shard when asked. The client checks the digest, so bad data is caught, not trusted.
Answers random integrity challenges. Failing one marks the shard for repair and lowers reputation.
Deletes a shard when it is no longer needed. Space returns to the pledge automatically.
What a node record contains
Only a name, region, pledged capacity, and operational counters. The agent token is shown once and stored as a hash.
{
"node": "node-osaka-01",
"region": "apac",
"pledged_gb": 500,
"shard_count": 1841,
"used_bytes": 21474836480,
"uptime_ratio": 0.987,
"last_heartbeat": "2026-04-11T08:31:04Z"
}Run the agent
One dependency-free file. Heartbeats, stores fragments, answers proofs, and serves reads.
curl -O https://your-site/mimir-agent.mjs MIMIR_TOKEN=<token from host console> \ MIMIR_API=https://your-site \ node mimir-agent.mjs ~/mimir-data
Why the agent is not trusted
Confidentiality comes from client-side encryption, availability from erasure coding, and integrity from client-verified digests. No single honest agent is required.