Memory.Wiki roadmap
A snapshot of what's shipping, what's queued, and what's deliberately not on the list.
Live now (v6)
- URL primitive at three scopes: Document, Bundle, Hub, all fetchable as markdown.
- Capture from anywhere: paste, file drop, ChatGPT/Claude/Gemini share URLs,
/memory.wikiin Claude Code / Cursor / Codex / Aider, Chrome extension, MCP server. - Memory.Wiki Memory pipeline: doc, chunk, bundle embeddings (idempotent), public Recall API with vector and hybrid BM25 plus RRF, hub semantic graph, cross-hub citation rollup.
- Auto-synthesis with diff-and-accept UI, confidence tags, hub log, hub lint.
- Time-traveling hub:
/hub/<slug>?at=<date>shows past state. - Shared bundles with discoverable opt-in.
- Permission-aware AI fetching: restricted resources return structured markdown errors, not 404 walls.
- MWBench cross-AI verification: 100% accuracy across Claude, OpenAI, and Gemini, including on truly unseen content. See /mwbench.
Queued
- Bundle metadata auto-re-embed on PATCH (currently manual).
- Cross-encoder reranker on top of RRF for higher chunk precision (when hub sizes warrant the extra 50 to 100 ms latency).
- Public flip from
/(editor) to two-door landing. Held for end of August 2026. - Stripe Pro. Beta is free; pricing decided after launch metrics.
Considered but deliberately deferred
- Multi-vector / late interaction (ColBERT-style) retrieval. Overkill until hubs reach thousands of docs.
- Mobile native app. Web works on mobile; native is a distraction at this stage.
- Workspace / team accounts. Current sharing primitives (allowed_emails per doc and bundle) cover most multi-user needs without team complexity.
Not in scope
- Becoming an LLM provider, or a chat UI, or a vector DB SaaS. Memory.Wiki publishes; it doesn't host inference or own the storage layer.
- Building a vendor-locked integration. Every Memory.Wiki URL is meant to be readable by any AI; that contract trumps any one-vendor optimization.