a real memory layer for AI coding agents // encrypted · attributed · human-gated

WeVibe is a memory layer for AI coding agents. A local plugin and MCP path retrieve relevant community memory, present each candidate to the user, and inject only approved memory into the session. No recalled memory enters an agent's context without human eyes on it first.

State — memory provenance, org membership, reputation, and economics — is anchored on a sovereign Cosmos SDK + CometBFT appchain. Encryption, decryption, sanitization, and context injection run locally on the contributor's machine.

A memory's standing in the corpus is not a frozen formula written into consensus. The chain records content-free, consumer-signed observations as an immutable append-only event log — a memory was served, blocked, or produced a measurable outcome. Standing is computed from that log at the edge, by a published and versioned policy whose hash is anchored on-chain. Nothing on-chain is ever a verdict, so no verdict can be rewritten, withheld, or lost with the infrastructure that computed it.

The protocol's sovereignty contract is the Four Exit Guarantees: no single party — including WeVibe — holds unilateral ability to READ plaintext from outside, WITHHOLD the network's function from a principal acting within their rights, REWRITE the historical record, or KILL an organization's knowledge by withdrawing infrastructure. The chain is the only durable authority; every other component is disposable and can be rebuilt from it.

It is a protocol with open, auditable data surfaces rather than a single closed SaaS: the chain is the source of truth, the display layer is a forkable client over chain RPC, and the network is non-custodial (it holds no user or org funds).

Status: alpha / testnet. The chain, hub, local client, and plugin each do one narrow job today. Interfaces, schema, and economics may change before mainnet.

WeVibe splits into four cooperating tiers — a local client, the hub, a proxy re-encryption (PRE) boundary, and the chain:

Contribution path

Coding session captured by plugin event stream
  └─ wevibe-dashboard     /sessions → Extract Memories (consent gate 1 — local only, no submission)
      └─ wevibe-dashboard  Submit N (consent gate 2 — explicit off-machine send)
          └─ wevibe-mcp    wevibe-guard scan → AES-256-GCM(DEK) → seal DEK to moderator key → Ed25519-sign
              └─ wevibe-hub   verify sig + hash, hold ciphertext in moderation queue
                  └─ wevibe-dashboard  leader curates labels, reviews plaintext locally, approves
                      └─ wevibe-chain  wallet-signed batch commit broadcast directly to chain RPC

Recall path

Repeat build/test failure in session (second failure under same stable failureKey)
  └─ wevibe-mcp (local)   build need-card → compute query embedding locally (Ollama, nomic-embed-text)
      └─ wevibe-hub        Qdrant vector + label-boosted search; rank by edge-computed standing; serve ciphertext
          └─ wevibe-umbral  PRE re-encrypts the wrapped DEK to the member key (never sees plaintext)
      └─ wevibe-mcp (local) local PRE decrypt → wevibe-guard scan → human approval gate → inject

Display path

wevibe-social-graph    reads chain state over REST/RPC → public profiles + badges (read-time, forkable)

Encryption boundary. Each memory is encrypted with a unique AES-256-GCM data key (DEK). The DEK is sealed to the moderator's X25519 key at submit, re-wrapped under the org's epoch key on approval, and re-encrypted to a member's key at recall via Umbral proxy re-encryption inside an isolated sidecar. The hub serves ciphertext and never holds a plaintext DEK or plaintext memory content. Honest scope: the hub does hold embeddings and label metadata that constitute a disclosed semantic shadow — so while the hub cannot decrypt content, it is not the case that nothing content-derived ever leaves the machine.

Memory model. A memory is a single situation-centric retrieval card (implement / context / dnd / stack). Labels are curated by the org leader at batch approval and serve as retrieval bonus terms — never hard gates, never inputs to standing. Recall scoring: relevance = vector_score + min(γ · label_boost, δ · vector_score) (γ=0.1, δ=0.15); standing enters as a separate term computed from the evidence log, never as a stored value read from chain.

Recall trigger. Recall fires on one gated condition: the second failure under the same stable failureKey while the session remains in a failing state. It does not fire on every prompt.

Human approval gate. Every recalled memory passes an explicit human gate — ACCEPT / DENY / BLOCK / REPORT — before entering an agent's context. The gate blocks; there is no timeout or fallthrough. ACCEPT injects context and signs a serve event; DENY blocks for this session; BLOCK adds to the personal blacklist; REPORT files an on-chain report.

Standing: computed, not stored. standing(memory) = policy_v(events(memory)) — events(memory) is that memory's slice of the public append-only event log; policy_v is a published, versioned, deterministic function whose hash is anchored on-chain. Nothing on-chain is ever a verdict. Any client, auditor, or replacement hub can recompute standing byte-for-byte from the same public log. The live anchor is edge-policy-v1, anchored at block height 45.

Identity. Each participant holds an Ed25519 protocol-identity key with an associated X25519 key for encryption. Onboarding is passkey-first (Face ID / fingerprint) — no wallet or seed phrase required to join, contribute, or recall. A Cosmos wallet is an optional upgrade, required only to claim accrued VIBE or to hold a leader/moderator role.

Economics. A single token, VIBE, on a 32-year fixed emission schedule (1B supply). Contributor rewards are a flat even split of each epoch's budget across qualifying approved contributors (qualification = approval count ≥ threshold). Org creation uses a slot-auction model with 50% of the slot fee burned. Alpha status: emissions are computed and accrued as chain state, but disbursement/minting is not yet wired.

Reputation & badges. The x/reputation module keeps on-chain contribution/serve aggregates. Three badge families — serve-milestone, rarity-tier, and contribution-volume — are scoped per-org (no cross-org leaderboard) and are strictly non-economic. Badges are computed at read time by the forkable social-graph client; there is no on-chain badge entity.

📖 Read the docs: wevibe-docs — start with WHITEPAPER.md and TOPOLOGY.md
🧪 Run the stack locally: wevibe-docs/SELF-HOSTING.md (or make docker-up from wevibe-meta)
🛠️ Set up the dev workspace: wevibe-meta