a real social layer for vibe coders

// memory as social contribution = reputation

WeVibe is a protocol for capturing verified technical insights from AI coding sessions, storing them as encrypted, human-curated memory, and recalling them into future sessions through a local approval gate. 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.

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 agent (OpenCode + plugin)
    └─ wevibe-mcp (local)        extract → embed → AES-256-GCM(DEK) → seal DEK to moderator key → Ed25519-sign
        └─ wevibe-hub            verify sig + hash, hold ciphertext in the moderation queue
            └─ dashboard         leader/moderator reviews plaintext locally, approves
                └─ wevibe-chain  wallet-signed MsgApproveMemory broadcast directly to chain RPC

Recall path
  Coding agent (OpenCode + plugin)
    └─ wevibe-mcp (local)        signed query → hub
        └─ wevibe-hub            Qdrant vector search + capped keyword boost; serves ciphertext only
            └─ 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 clean embeddings and plaintext keyword weights — a lossy "semantic shadow" of each memory — 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 (insight / context / avoid / stack). Keywords are generated in the contributor's local extraction pass and curated by the org leader at batch approval. Recall ranks by vector similarity plus a capped additive keyword boost (final = vector + γ·keyword_overlap, γ≈0.1) — a boost, not a hard gate.
• Human approval gate. Gated approval before any memory enters an agent's context is the locked product default. Alpha status: the injection gate is defined but not yet wired into the recall path, so recall injection is currently ungated — a known, tracked defect that blocks general external use.
• 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 is required to join, contribute, or recall — and reputation is keyed to the passkey identity. A Cosmos wallet is an optional later 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 accrue per approved memory, not per serve. Alpha status: emissions are computed and accrued as chain state, but disbursement/minting is not yet wired. Serve/denial attribution is kept on-chain and public but is a social signal only — it drives profiles and badges and does not trigger payout.
• 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 yet (rarity-tier semantics are still design-stage).

• 📖 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

• 🐦 X / Twitter: @WeVibe_Network