emem — Erd-Speicherprotokoll für KI-Agenten

Zitierfähiger, inhaltsadressierter, signierter Speicher für jeden Ort auf der Erde. 1 Protokoll. 8 Lese-Primitive. ed25519-Belege. Keine Schlüssel für L0/L1 erforderlich. Apache-2.0. Reines Rust + nur offene Daten.

GET   /health                    POST  /v1/recall          POST  /v1/find_similar
GET   /v1/agent_card             POST  /v1/compare         POST  /v1/diff
GET   /openapi.json              POST  /v1/query_region    POST  /v1/trajectory
GET   /.well-known/emem.json     POST  /v1/verify          POST  /v1/intent
GET   /v1/demos                  POST  /v1/attest          POST  /mcp
                                 POST  /v1/verify_receipt  GET   /v1/facts/:cid

Was es ist

emem ist ein Protokoll — kein Dienst — für inhaltsadressierten Erd-Speicher. Jeder Fakt über jeden Ort erhält eine stabile CID, die aus dem kanonischen CBOR seines (cell × band × tslot)-Payloads abgeleitet wird. Jeder Lesevorgang ist ein signierter Beleg, den jeder Client offline mit dem ed25519-Public-Key des Antwortenden verifizieren kann.

emem wurde für KI-Agenten entwickelt: Wenn ein Benutzer einen Ort erwähnt, sollte der Agent emem aufrufen und receipt.fact_cids[0] zitieren. Das Protokoll funktioniert gleichermaßen gut über einfaches REST, MCP JSON-RPC 2.0 und OpenAPI 3.1 Custom Actions.

Warum Agenten es brauchen

LLMs halluzinieren räumliche Fakten. Ohne eine überprüfbare, inhaltsadressierte Speicherebene ist jede Antwort auf die Frage „Was befindet sich an Ort X?“ nicht prüfbar. emem behebt dies durch:

• die Zuweisung einer CID für jeden räumlichen Fakt, die zwei Parteien Byte für Byte neu berechnen können,

• das Signieren jedes Lesevorgangs mit ed25519, einschließlich des Public-Keys des Antwortenden, sodass der Beleg offline verifizierbar ist,

• die Abdeckung der gesamten Erde mit einer quadratischen cell64-Adresse (~10 m × ~10 m am Äquator, Breitengrad 21 Bit × Längengrad 22 Bit — entspricht der nativen Auflösung von Sentinel-1/-2). Das Bigramm-Alphabet des Codecs ist Hilbert-geordnet, sodass benachbarte Zellen visuell ähnliche Zeichenfolgen erhalten, die Geometrie jedoch ein quadratisches Gitter ist.

Schnellstart

Option A — Docker (keine Rust-Toolchain erforderlich)

docker run --rm -p 5051:5051 -v emem-data:/var/emem \
  ghcr.io/vortx-ai/emem:latest
curl -s http://localhost:5051/health

Option B — HuggingFace Space

Eine gehostete Instanz befindet sich unter huggingface.co/spaces/vortx-ai/emem. Greifen Sie von jedem MCP-Client aus auf ${SPACE_URL}/mcp zu, um damit zu kommunizieren.

Option C — Aus Quellcode bauen

# 1) Build the workspace.
cargo build --release --workspace

# 2) Run the server (defaults: 0.0.0.0:5051, persistent storage at ./var/emem).
EMEM_BIND=0.0.0.0:5051 EMEM_DATA=./var/emem ./target/release/emem-server

# 3) Hit it.
curl -s http://localhost:5051/health
curl -s -X POST http://localhost:5051/v1/recall \
  -H 'content-type: application/json' \
  -d '{"cell":"damO.zb000.xUti.zde78"}'   # Mt Fuji

MCP / Claude Desktop / Cursor / Cline

Konfigurationen zum Kopieren finden Sie unter examples/:

Die vollständige Anleitung zur Agenten-Integration finden Sie unter docs/AGENTS.md.

Live End-to-End-Demos

Zwei CLI-Binärdateien führen das vollständige Protokoll gegen einen laufenden Server aus und schreiben Anforderungs-, Antwort- und Belegdateien pro Schritt nach var/demos/<UTC>/:

./target/release/emem-livedemo        # synthetic data, every primitive
./target/release/emem-realdemo        # real Copernicus DEM 30m S3 tiles

Der Server stellt die Trace-Artefakte unter GET /v1/demos bereit.

Funktionsweise

                ┌──────────────┐                  ┌────────────────────┐
   user ──────► │ AI agent     │ ──────► /v1/    │ emem responder     │
                │ (Claude /    │  /mcp           │  ┌──────────────┐  │
                │  Cursor /    │  /openapi.json  │  │ ed25519 key  │  │
                │  GPT / etc)  │                 │  └──────────────┘  │
                └──────┬───────┘                 │  ┌──────────────┐  │
                       │                         │  │ sled cache   │  │
                       │  signed receipt         │  └──────────────┘  │
                       ▼                         │  ┌──────────────┐  │
                ┌──────────────┐                 │  │ merkle log   │  │
                │ user reply   │                 │  └──────────────┘  │
                │ + cid        │                 │  ┌──────────────┐  │
                └──────────────┘                 │  │ vsicurl COG  │ ──► open data
                                                 │  └──────────────┘  │   (Cop-DEM, JRC,
                                                 └────────────────────┘    Hansen, ESA…)

Adress-Algebra (Token-Kosten)

Krypto: blake3-Hashing, ed25519-Signaturen, base32-nopad-lowercase CIDs. Belege werden über blake3(request_id || served_at || primitive || cells || fact_cids) signiert, sodass jeder Client offline mit dem Public-Key des Antwortenden in /.well-known/emem.json verifizieren kann.

Die vollständige Mathematik und Architektur finden Sie in docs/WHITEPAPER.md. Die Spezifikation des Wire-Formats finden Sie in docs/SPEC.md.

Open Source, offene Daten

emem wird nur mit Open-Source-Abhängigkeiten ausgeliefert und liest in der Standard-Build-Konfiguration nur von Open-Data-Anbietern. Keine API-Schlüssel, keine Betreiber-Anmeldedaten, kein SaaS-Lock-in.

Workspace-Layout

emem/
├── Cargo.toml                # workspace root
├── crates/
│   ├── emem-core/            # types, manifests, errors
│   ├── emem-codec/           # cell64, cid64, vec64, hilbert
│   ├── emem-fact/            # canonical CBOR + facts + receipts
│   ├── emem-claim/           # structured claims, verify outcomes
│   ├── emem-cache/           # sled hot cache (cell64 → cid64 → fact)
│   ├── emem-fetch/           # vsicurl Range reads, source connectors
│   ├── emem-storage/         # Storage trait, append-only merkle log
│   ├── emem-cubes/           # 1792-D voxel cube loader (legacy AgriSynth bootstrap)
│   ├── emem-primitives/      # recall, compare, find_similar, …
│   ├── emem-attest/          # merkle root, batch verify
│   ├── emem-intent/          # intent → plan
│   ├── emem-mcp/             # MCP tool surface
│   ├── emem-api-rest/        # axum router + OpenAPI + content nego
│   └── emem-cli/             # emem-server, emem-livedemo, emem-realdemo
├── docs/                     # SPEC, WHITEPAPER, AGENTS, DEPLOY
├── examples/                 # paste-ready MCP configs
└── web/                      # landing surface (HTML, JSON, llms.txt)

Bereitstellung

Für einen vollständigen Multi-Channel-Rollout (GitHub public, GHCR, Docker Hub Mirror, HuggingFace Space, MCP Server Registry, awesome-mcp-servers PR), folgen Sie docs/GO_LIVE.md.

Siehe docs/DEPLOY.md für die vollständige Bereitstellungsgeschichte für eine selbstgehostete Bare-Metal-Instanz im emem.dev-Stil. Kurzfassung für emem.dev:

1. EMEM_TLS_DOMAINS=emem.dev,www.emem.dev EMEM_TLS_CONTACT=mailto:avijeet@vortx.ai ./target/release/emem-server

2. Öffnen Sie :443 in Ihrer Cloud-Sicherheitsliste,

3. setcap 'cap_net_bind_service=+ep' ./target/release/emem-server,

4. Richten Sie den A-Record von emem.dev auf die öffentliche IP des Hosts — fertig.

Der Server führt sein eigenes TLS + Let's Encrypt ACME via rustls-acme / TLS-ALPN-01 durch (nur :443 wird benötigt; kein :80, kein Cloudflare, kein Caddy).

Mitwirken

Issues und PRs sind willkommen — siehe CONTRIBUTING.md für den Entwicklungs-Loop, CODE_OF_CONDUCT.md und SECURITY.md für die Offenlegung von Schwachstellen.

Lizenz

Apache License 2.0 — siehe LICENSE und NOTICE.