--- title: "q1. yes" url: https://memory.wiki/Jgmu7Yc8 updated: 2026-05-20T14:29:32.291Z source: "chrome" --- # q1. yes > Captured from Claude on 5/20/2026 --- ## User q1. yes v7 plan 전체 정리 및 Manifesto v7 (이름 변경 반영) 수집,소화,활용 에 제안한것 일단 전부 킵하고 어떻게 할지 계획에 넣어줘 --- ## Claude # Why I'm building memory.wiki I built memory.wiki in five months, mostly nights and weekends, then went full-time. This is why. ## The problem isn't memory. It's delivery. Every day, millions of people pour their thinking into ChatGPT, Claude, Gemini, and Cursor. We ask hard questions. We get back genuinely useful answers — strategies, code, frameworks, insights that took experts decades to develop. Then we close the tab. That answer is gone. Not literally — it sits in some chat history we'll never search. But functionally gone. We can't find it. We can't connect it to last week's insight. We can't ship it back into tomorrow's conversation. The next day, we ask similar questions. We re-paste the same context. We re-explain who we are, what we're working on, what we already decided. We get similar answers. We close the tab again. The industry calls this an "AI memory problem." The startups attacking it — Mem0, Letta, ChatGPT Memory — all build the same thing: a memory store the LLM queries to remember about you. That's not actually the problem. The problem is that **your knowledge has nowhere to live that any AI can read.** It can live in Notion (but the AI can't fetch it without auth). It can live in a Google Doc (same problem). It can live in your local files (no AI sees them). It can live in ChatGPT Memory (but only ChatGPT can read it). Each container is closed. We don't need another memory store. We need a place where your knowledge lives as a URL — one that any AI can read, that updates as you edit, that holds not just docs but the relationships between them. That's memory.wiki. ## The one idea A memory.wiki URL is an API for any AI. Paste `memory.wiki/` into ChatGPT. The LLM fetches it and gets clean markdown. Paste `memory.wiki/b/` (a bundle) and the LLM gets a pre-built map of how the docs in that bundle relate. Paste `memory.wiki/hub/` (your whole hub) and the LLM gets the shape of your thinking — every concept, every relation, every bundle, organized for an AI to read. No app to install. No SDK to integrate. No format to learn. Just markdown over HTTPS, in three nested scopes, ready for any LLM that can hit a URL. That's the entire product. Every feature exists to make those URLs more useful. ## Three tiers: capture, digest, deliver memory.wiki has three layers. They map to a simple workflow. **You capture.** Markdown comes from anywhere — Chrome extension on ChatGPT, VS Code, your terminal, your Mac clipboard, the web editor. Each capture becomes a Document URL. Living, editable, addressable. **The system digests.** An LLM extracts concepts from every doc you save, building your personal ontology. When you bundle docs together, another LLM analyzes the set — themes, insights, the edges between ideas. Embeddings power semantic search. Your concept index grows across every bundle, accumulating into a graph of how you think. **You deliver.** Three URL scopes — Doc, Bundle, Hub — each tuned for its purpose. Compact responses ship the AI-built graph and links instead of full bodies, so your LLM gets the map for ~95% fewer tokens. Full responses inline everything when you need it. The 26-tool MCP server lets agents write back, search semantically, and live inside your hub. That's the loop. Capture once, the system organizes, deliver everywhere. ## The graph is the product Most knowledge tools store docs. memory.wiki stores docs *and* the graph between them. Every time you save a doc, an LLM extracts concepts and tags them. Every time you bundle docs, another LLM finds themes and draws edges. Every concept across every bundle accumulates into your personal ontology — typed relations, weights, cross-references. The bundle canvas shows you this graph. The galaxy at `/galaxy` shows you the same graph zoomed out. The hub URL ships the same graph as markdown for an LLM to read. The MCP server queries the same graph through 26 different tools. **Every memory.wiki surface is a different reader of the same underlying graph. The graph is the product.** That's the lock-in mechanism, and I'm being honest about it. You can export your markdown anytime — it's plain text, your property. But the graph that's been accumulating for months — the concept weights, the cross-bundle relations, the semantic embeddings — that's harder to reconstruct elsewhere. The longer you use memory.wiki, the more your knowledge has shape. Some tools build moats by closing exits. memory.wiki builds them by being open enough that staying is just easier than leaving. ## Why not just use Mem0, or Notion, or LLM Wiki? Let me be honest about who memory.wiki is and isn't. **memory.wiki is not Mem0.** Mem0 extracts memory from your conversations automatically. You don't curate; the LLM decides what matters. That's a reasonable design. It just answers a different question. Mem0 asks "what should the AI remember about you?" memory.wiki asks "what do you want to deploy to your AI?" Both have a place. They could even work together. **memory.wiki is not Karpathy's LLM Wiki.** Karpathy's LLM Wiki pattern is brilliant — local docs, LLM-compiled wiki, organized for retrieval, lives in Obsidian. memory.wiki is cloud-based, human-AI collaborated, organized for delivery. LLM Wiki is one unified knowledge base. memory.wiki is doc + bundle + hub — three scopes you compose. You can use both: your LLM Wiki for local query, memory.wiki for cross-AI deployment. The integration is on the roadmap. **memory.wiki is not Notion or Google Docs.** Notion is a closed workspace. Notion AI works inside Notion. Google Docs is closed to AI without auth. memory.wiki is open URLs that any AI can fetch. Your knowledge isn't trapped in someone's app. **memory.wiki is not ChatGPT Memory.** ChatGPT remembers about you, inside ChatGPT. memory.wiki is your knowledge, deployable to ChatGPT, Claude, Cursor — anywhere a URL can be pasted. memory.wiki is the layer in between extraction and storage. **Your knowledge graph, built with AI, deployed to AI, owned by you.** ## Why now There's a narrow window where this matters. For the past two years, every AI company has been building closed memory inside its walls. ChatGPT Memory. Google Memory Bank. The extracted-memory startups inside their SDKs. Each one is trying to own your knowledge inside their product. In two more years, one of two things will be true. Either the closed systems win, and your knowledge lives inside whichever AI you happen to use — owned by them, queryable only through their API. Or an open standard emerges — markdown URLs that any AI can fetch, knowledge you carry across vendors, formats you control. I'm building memory.wiki to make the second outcome more likely. This is the same bet that HTTP made about documents. HTTP didn't win because anyone declared it. It won because the primitive was right and the alternatives were worse. Markdown URLs can be that for AI memory. Plain text. Universally readable. AI-native. Composable into bundles and hubs. The format is already in use by every LLM. The transport is already in use by every browser. We just need to assemble them into a layer. That layer is memory.wiki. ## What I've built so far In about five months — most of it nights and weekends before I went full-time — I shipped: - A web app (mdfy.app, soon memory.wiki) with WYSIWYG markdown editing and the three URL scopes (Doc, Bundle, Hub) - A Chrome extension for one-click capture from ChatGPT, Claude, and Gemini - A VS Code extension on the Marketplace - A macOS desktop app (signed, notarized) - A CLI on npm - An MCP server on npm with 26 tools — any host that speaks MCP (Claude Desktop, Cursor, Cline, Windsurf) gets the full hub as native AI tooling - A macOS QuickLook plugin - Real-time collaborative editing (Yjs CRDT over Supabase Realtime) - AI auto-extraction of concepts on every doc save - AI graph analysis on every bundle (themes, insights, typed edges) - Per-doc, per-chunk, per-bundle embeddings for semantic search - A galaxy visualization at `/galaxy` that renders your concept index live - Three-provider AI failover (Anthropic, OpenAI, Gemini) - One unified renderer across every viewer, embed, and channel I shipped this fast because the primitive — markdown URL — is the right one. Every surface composes. Every surface ships the same graph in a different form. That's where memory.wiki is now. The infrastructure is built. The next four months are about making each tier — capture, digest, deliver — significantly stronger. ## What's next (the next 16 weeks) **Capture stronger.** iOS Share Sheet so any iOS app can send to your hub. AI conversation auto-suggest in the Chrome extension — the extension watches your ChatGPT/Claude session and offers to save interesting answers, you decide. Email forward to send newsletters into your hub. Voice capture on mobile, eventually. **Digest stronger.** AI bundle generation — describe what you want bundled in natural language, the LLM searches your hub, drafts the bundle, you review and save. Question-driven exploration — ask your hub a question, get an answer with citations. Cross-bundle auto-linking — when concepts span bundles, the system surfaces the connections. **Deliver stronger.** Direct LLM platform integration — a Custom GPT for ChatGPT, one-click MCP setup for Claude Desktop, cursor rules for Cursor. Embedded chat right inside memory.wiki, with your hub as auto-context. Public hubs so you can share the shape of your thinking the way people share Substack feeds. AI-specific format adapters that tune the URL payload for Claude, GPT, or Cursor. Launch is the end of August 2026. The Bundle Spec — the open format that memory.wiki bundles use — goes public the same week, as an RFC on GitHub. Any tool can implement it. ## The five beliefs Behind every product decision are beliefs. Here are mine. **1. Markdown is the right primitive for AI-era knowledge.** Not Notion blocks. Not proprietary formats. Plain markdown — what LLMs speak natively, what humans read directly, what every tool can produce. It will outlast every tool currently fighting to capture knowledge. **2. URLs are the right interface.** Not SDKs. Not vendor lock-in. A URL is the simplest possible delivery mechanism — pastable, fetchable, openable in any browser by any human or any AI. The simplest interface is the most durable. **3. The graph is the product.** Storing docs isn't enough. The relationships between docs — concepts, themes, typed edges — are what make a knowledge base navigable. Build the graph automatically, ship it in every URL response. **4. Delivery, not retrieval, is the new layer.** Most memory startups built retrieval systems — query the store, return chunks. memory.wiki builds delivery — pre-organize the graph and ship it in URLs. Any AI inherits the structure. That's the layer AI companies can't easily replicate. **5. Open by default.** Bundle Spec will be published openly. mdfy core engine had an open-source history. Self-hosting will be available. Trust requires users can leave with their data in formats other tools read. We build for that from the start. ## An open invitation If you've read this far, you probably care about one of these things: AI memory, knowledge graphs, open standards, markdown-as-primitive, or indie tools that don't lock you in. Here's what I'm asking. **If you use AI daily**, try memory.wiki at mdfy.app (rename coming). Install the Chrome extension. Capture a few good answers. Bundle them. Paste the bundle URL into your next AI conversation. See what changes. **If you build AI agents or AI-native tools**, look at the MCP server — 26 tools, the embeddings layer, the graph queries. If your product needs a memory layer, memory.wiki might be the right one, or might not be — I want to hear either way. **If you care about open standards**, the Bundle Spec is coming as an RFC before launch. I want feedback before it ships. The version that gets adopted will be better than the one I write alone. **If you've built an LLM Wiki** in the Karpathy style, memory.wiki is meant to complement what you have. Local wiki for query, cloud hub for delivery. Tell me what integration would look like for you. **If you work at an AI platform** — Anthropic, OpenAI, Cursor, Cognition, Continue — I'd like to talk about default integration. The vision is that any LLM can offer "connect memory.wiki" and the user's knowledge graph just shows up in every conversation. That's a partnership conversation. **If you're an investor**, I'm not raising right now. I will be when the metrics justify it. If this thesis resonates, the conversation worth having is at that point — and I want to be talking to investors who care about open infrastructure, not closed unicorns. **If you just like reading about this stuff**, thank you for reading this far. The conversation around AI knowledge layers is going to define a lot of the next decade. The more people thinking about it carefully, the better. ## A note on what's next I'm building in public. The next 16 weeks will be visible — every feature shipped, every decision made, every pivot when something doesn't work. Some of it will be ugly. Some of it will be wrong. All of it will be honest. The first public launch — capture enhancements, AI bundle generation, public hubs, direct LLM platform integration, Bundle Spec — is targeted for the end of August 2026. Until then: try the product, share what works, tell me what's missing. --- *memory.wiki is built by Hyunsang at Raymind.AI.* *Current home: mdfy.app (memory.wiki migration in progress).* *Bundle Spec will be published as an RFC before Phase 2 ships.* *Reach me at [hi@raymind.ai](mailto:hi@raymind.ai).*