--- mw_bundle: 1 type: hub_digest slug: raymindai author: "Hyunsang Cho" url: https://memory.wiki/hub/raymindai concept_count: 40 updated: 2026-06-06T01:50:01.426Z source: "Memory.Wiki" --- # Hyunsang Cho's knowledge — concept digest _40 concepts extracted across this hub. Each entry links to the supporting documents — fetch any of them as `https://memory.wiki/raw/?compact=1` for the dense full text._ ## Concepts ### memory.wiki *entity • weight 567 • 6 docs* > The core product platform managing knowledge capture and AI-assisted workflows. - [memory.wiki — Product Specification](https://memory.wiki/Tk71NDw0) Memory.wiki is a personal knowledge wiki that doubles as a deployable memory layer for AI systems, built on the promise "You author. AI uses. The wiki maintains itself." The product requires wikilinks, backlinks, semantic search, and LLM-powered self-maintenance to differentiate from existing note apps and AI memory tools. - [Memory.Wiki Product Strategy and Development](https://memory.wiki/KFtUbXkS) Memory.wiki is a personal knowledge management system positioned as a cross-AI memory protocol layer where users author content, AI uses it, and the system maintains itself through automatic indexing and organization. The product differentiates from traditional PKM tools by operating as infrastructure with two interfaces: a memory capture door and a wiki organization door, with current development gaps in link graphs, semantic search, and LLM self-organization capabilities. - [memory.wiki — Product Specification Synthesis](https://memory.wiki/UwZWUmdo) Memory.wiki is a personal knowledge wiki designed as a deployable memory layer for AI systems where users author content while the wiki self-organizes through LLM automation. It distinguishes itself from traditional note-taking apps by offering semantic search, link graphs, and the ability to deploy a single URL across multiple AI platforms and sessions. - [Mdfy v6 recap](https://memory.wiki/8QB0olhs) memory.wiki is a tool that converts user-created markdown into URLs that any AI can read, automatically organizing the knowledge into a graph so users can deploy their information across different AI platforms without re-explaining themselves. The founder plans to launch in August and eventually position it as the default memory layer for major LLM services. - [내가 memory.wiki를 만드는 이유](https://memory.wiki/fz45GXXj) The real problem with AI memory systems is not that AI cannot remember users, but that user knowledge remains locked in closed platforms like ChatGPT, Notion, and Google Docs where no AI can access it. memory.wiki solves this by providing open URLs that any AI can fetch to access a user's knowledge graph organized as markdown documents, bundles, and hubs. - [memory.wiki 사업계획 v7 (FINAL)](https://memory.wiki/xv6A2DKS) memory.wiki is a platform that delivers knowledge graphs as URLs and APIs that any AI can use, with the core thesis that "the graph is the product" while maintaining a three-tier architecture of capture, digestion, and utilization of user knowledge. _Related:_ evolved from → **mdfy** ### Result *concept • weight 240 • 1 doc* > Rust's core mechanism for recoverable error handling that replaces exceptions with explicit type-level error propagation. - [Rust Error Handling: From Beginner to Production](https://memory.wiki/orlirmor) Rust uses Result for recoverable errors and panic for unrecoverable ones, with libraries using thiserror for custom error types and applications using anyhow for ergonomic error handling with context chains. Production code should avoid unwrap(), use the ? operator for error propagation, and add context at every boundary. _Related:_ enables propagation via → **Question mark operator** · enables concise propagation → **Question mark operator** · enables propagation → **Question mark operator** · enables propagation of → **Question mark operator** · enables ergonomic use of → **Question mark operator** ### Question mark operator *concept • weight 225 • 1 doc* > Syntactic sugar for propagating errors up the call stack, enabling clean error handling chains. - [Rust Error Handling: From Beginner to Production](https://memory.wiki/orlirmor) Rust uses Result for recoverable errors and panic for unrecoverable ones, with libraries using thiserror for custom error types and applications using anyhow for ergonomic error handling with context chains. Production code should avoid unwrap(), use the ? operator for error propagation, and add context at every boundary. _Related:_ works with → **Error context chain** · syntactic sugar for → **Result** · combines with → **Error context chain** · works seamlessly with → **Error context chain** · syntactic shorthand for → **Result** ### anyhow *entity • weight 196 • 1 doc* > Crate for applications to add context to errors and handle them ergonomically without defining custom types. - [Rust Error Handling: From Beginner to Production](https://memory.wiki/orlirmor) Rust uses Result for recoverable errors and panic for unrecoverable ones, with libraries using thiserror for custom error types and applications using anyhow for ergonomic error handling with context chains. Production code should avoid unwrap(), use the ? operator for error propagation, and add context at every boundary. _Related:_ provides tools for → **Error context chain** · provides → **Error context chain** ### thiserror *entity • weight 196 • 1 doc* > Crate for libraries to define strongly-typed custom error enums with automatic trait implementations. - [Rust Error Handling: From Beginner to Production](https://memory.wiki/orlirmor) Rust uses Result for recoverable errors and panic for unrecoverable ones, with libraries using thiserror for custom error types and applications using anyhow for ergonomic error handling with context chains. Production code should avoid unwrap(), use the ? operator for error propagation, and add context at every boundary. _Related:_ implements → **Custom error types** · derives and implements → **Custom error types** · implements pattern for → **Custom error types** · derives → **Custom error types** · provides derive macro for → **Custom error types** ### PKCE *concept • weight 170 • 1 doc* > Cryptographic protocol extension that prevents authorization code interception attacks by binding tokens to a code verifier. - [OAuth 2.0 + PKCE Implementation Guide](https://memory.wiki/Oss2bUN8) PKCE (Proof Key for Code Exchange) is mandatory for public clients like SPAs and mobile apps to prevent authorization code interception attacks, requiring generation of a random code verifier, deriving a code challenge via SHA-256 hashing, and including both in the OAuth 2.0 authorization and token exchange flow. _Related:_ extends security of → **OAuth 2.0** · extends and secures → **OAuth 2.0** · extends → **OAuth 2.0** · extends security → **OAuth 2.0** · enhances security of → **OAuth 2.0** ### OAuth 2.0 *concept • weight 170 • 1 doc* > Authorization framework that PKCE extends to secure public clients and improve overall OAuth flow security. - [OAuth 2.0 + PKCE Implementation Guide](https://memory.wiki/Oss2bUN8) PKCE (Proof Key for Code Exchange) is mandatory for public clients like SPAs and mobile apps to prevent authorization code interception attacks, requiring generation of a random code verifier, deriving a code challenge via SHA-256 hashing, and including both in the OAuth 2.0 authorization and token exchange flow. ### mdfy Memory *entity • weight 150 • 1 doc* > The product name that now frames mdfy's retrieval and storage system, replacing the RAG technique-centric terminology. - [How Memory.Wiki does RAG / Memory.Wiki Memory](https://memory.wiki/how-mdfy-rag-works) Memory.Wiki reframed its retrieval system from a technical RAG-focused approach to a product-oriented memory system, maintaining the same underlying architecture of HTTP endpoints, chunked hybrid retrieval, and idempotent embeddings. _Related:_ reframes → **RAG** · replaces framing of → **RAG** · implements → **RAG** · reframes technique as → **RAG** · implements technique as → **RAG** ### Error context chain *concept • weight 147 • 1 doc* > Practice of adding contextual information at each error boundary to create human-readable error stories. - [Rust Error Handling: From Beginner to Production](https://memory.wiki/orlirmor) Rust uses Result for recoverable errors and panic for unrecoverable ones, with libraries using thiserror for custom error types and applications using anyhow for ergonomic error handling with context chains. Production code should avoid unwrap(), use the ? operator for error propagation, and add context at every boundary. _Related:_ enabled by → **anyhow** ### Knowledge Management *tag • weight 147 • 6 docs* > Overarching domain of personal and organizational information systems - [mdfy.cc 사업계획 v6 (FINAL)](https://memory.wiki/_4iafQ8K) capturing context, Markdown organizing thought. ### Pillar 2: Bundle (Manual + AI) **Organize by topic. Own the grouping.** Manual: - Drag-and-drop - Add annotations - Nested bundles - Save and version AI-generated: - "Show me all docs about X" - AI finds + groups - You review + edit - Save as bundle Bundle URL = deployment unit for AI. ### Pillar 3: Deploy **Paste into any AI. Works immediately.** - Paste Document URL to AI fetches one doc - Paste Bundle URL to AI fetches entire bundle - Paste Hub URL to AI fetches everything - Real-time + version control ## Competitive Positioning (3 ways mdfy - [mdfy.cc Manifesto](https://memory.wiki/3Ug2sp5E) mdfy is a product that lets users author and own their own AI memory in markdown format, capturing answers from any AI tool, editing them, and using them as portable context anywhere, positioning itself as user-authored curation rather than AI-extracted memory like competing services. - [What is Memory.Wiki](https://memory.wiki/what-is-mdfy) Memory.Wiki is a vendor-neutral URL-based personal knowledge system that lets users capture and organize AI conversations and documents in a single hub that any AI can read as context. The core innovation is replacing vendor-locked memory layers with a shareable markdown URL that works across ChatGPT, Claude, Cursor, and other AI tools without requiring SDKs or plugins. - [Document, Bundle, Hub](https://memory.wiki/mdfy-three-primitives) Memory.Wiki uses a single URL primitive at three nested scopes (document, bundle, hub) to organize knowledge artifacts, each fetchable as markdown by any AI via HTTP. All three levels share the same viewer, fetch path, and embedding pipeline, allowing users to scale from individual documents to curated topic collections to their entire personal knowledge graph. - [How Memory.Wiki works](https://memory.wiki/how-mdfy-works) Memory.Wiki is a personal knowledge hub that captures AI conversation outputs, synthesizes them into structured wiki pages, and maintains a searchable schema so users can retrieve and reuse their knowledge across different AI tools through a simple URL interface that works universally across ChatGPT, Claude, and other AI platforms. - [Memory.Wiki Memory](https://memory.wiki/mdfy-memory) Memory.Wiki Memory is a public, human-readable memory layer that lets you capture answers from AI chats, organize them into a hub at a permanent URL, and share that hub with any AI via a simple HTTP recall endpoint that supports chunked retrieval, hybrid search (BM25 + vector), and privacy-enforced filtering. Unlike vendor-specific memory systems, it's not locked behind an SDK or MCP server and can be pasted into any AI as markdown context. ### mdfy *entity • weight 137 • 6 docs* > The product being launched: a memory infrastructure for AI-native work centered on user authorship and portability. - [Cursor for code, Claude for research, finally on the same page](https://memory.wiki/case-cross-tool-handoff) Install `/memory.wiki` once takes 30 seconds via a single curl command · Per-capture overhead is under 5 seconds · Per-conversation context load is roughly 3 seconds (paste the hub URL) · Same hub URL works across Cursor, Claude Code, and any other AI tool · Verified across Claude, OpenAI, and Gemini at 100% accuracy via [MWBench](/mwbench) - [Onboarding every new Claude Code session in one line](https://memory.wiki/case-claude-md-personal-context) A developer can eliminate repetitive project context setup across Claude Code sessions by adding a single Memory.Wiki hub URL reference to their ~/.claude/CLAUDE.md file, allowing Claude to automatically fetch relevant project details on demand instead of re-explaining them each time. This same approach works across other AI coding tools like Cursor and ChatGPT. - [Sharing AI conversations the way you'd share a Notion link](https://memory.wiki/case-share-with-team) A tool called Memory.Wiki lets users save Claude conversations as permanent shareable URLs that work for both human readers (with formatting) and AI systems (as raw markdown), solving the problem of sharing AI chat context with teammates without reformatting or losing functionality. - [Karpathy's hand-curated LLM wiki, without the hand-curation](https://memory.wiki/case-personal-llm-wiki) Memory.Wiki automates 80% of the maintenance burden in Karpathy's hand-curated personal LLM wiki system by automatically capturing content, synthesizing wiki pages, building semantic graphs, and surfacing gaps, while keeping humans in the loop only for accepting proposed wiki updates. - [memory.wiki — Product Specification](https://memory.wiki/Tk71NDw0) Memory.wiki is a personal knowledge wiki that doubles as a deployable memory layer for AI systems, built on the promise "You author. AI uses. The wiki maintains itself." The product requires wikilinks, backlinks, semantic search, and LLM-powered self-maintenance to differentiate from existing note apps and AI memory tools. - [How memdo 멤도 works](https://memory.wiki/QF-bp5G_) Mdfy is a service that provides URLs serving clean markdown summaries of documents and document collections to any AI tool, powered by an underlying graph of extracted concepts and relationships that LLMs can either fetch directly or interact with through 26 MCP tools for search and editing. _Related:_ evolved into → **memory.wiki** · rebranded to → **memory.wiki** · provides platform → **Knowledge Management** ### Custom error types *concept • weight 133 • 1 doc* > Enum-based error definitions that provide semantic clarity and allow pattern matching; essential for library public APIs. - [Rust Error Handling: From Beginner to Production](https://memory.wiki/orlirmor) Rust uses Result for recoverable errors and panic for unrecoverable ones, with libraries using thiserror for custom error types and applications using anyhow for ergonomic error handling with context chains. Production code should avoid unwrap(), use the ? operator for error propagation, and add context at every boundary. ### Code Verifier *concept • weight 132 • 1 doc* > Random cryptographic string generated by the client and stored locally to prove ownership during token exchange. - [OAuth 2.0 + PKCE Implementation Guide](https://memory.wiki/Oss2bUN8) PKCE (Proof Key for Code Exchange) is mandatory for public clients like SPAs and mobile apps to prevent authorization code interception attacks, requiring generation of a random code verifier, deriving a code challenge via SHA-256 hashing, and including both in the OAuth 2.0 authorization and token exchange flow. _Related:_ hashed into → **Code Challenge** · hashed to create → **Code Challenge** · generates → **Code Challenge** · generates via sha-256 → **Code Challenge** ### panic! *concept • weight 132 • 1 doc* > Mechanism for unrecoverable errors that should never be caught, complementing Result for error handling strategy. - [Rust Error Handling: From Beginner to Production](https://memory.wiki/orlirmor) Rust uses Result for recoverable errors and panic for unrecoverable ones, with libraries using thiserror for custom error types and applications using anyhow for ergonomic error handling with context chains. Production code should avoid unwrap(), use the ? operator for error propagation, and add context at every boundary. _Related:_ contrasts with → **Result** ### Code Challenge *concept • weight 132 • 1 doc* > SHA-256 hash of the code verifier sent to the auth server to bind the authorization request. - [OAuth 2.0 + PKCE Implementation Guide](https://memory.wiki/Oss2bUN8) PKCE (Proof Key for Code Exchange) is mandatory for public clients like SPAs and mobile apps to prevent authorization code interception attacks, requiring generation of a random code verifier, deriving a code challenge via SHA-256 hashing, and including both in the OAuth 2.0 authorization and token exchange flow. _Related:_ hashed from → **Code Verifier** ### Chrome Extension *entity • weight 124 • 6 docs* > Browser capture tool for one-click knowledge saving - [mdfy.cc 사업계획 v6 (FINAL)](https://memory.wiki/_4iafQ8K) capturing context, Markdown organizing thought. ### Pillar 2: Bundle (Manual + AI) **Organize by topic. Own the grouping.** Manual: - Drag-and-drop - Add annotations - Nested bundles - Save and version AI-generated: - "Show me all docs about X" - AI finds + groups - You review + edit - Save as bundle Bundle URL = deployment unit for AI. ### Pillar 3: Deploy **Paste into any AI. Works immediately.** - Paste Document URL to AI fetches one doc - Paste Bundle URL to AI fetches entire bundle - Paste Hub URL to AI fetches everything - Real-time + version control ## Competitive Positioning (3 ways mdfy - [mdfy.cc Manifesto](https://memory.wiki/3Ug2sp5E) mdfy is a product that lets users author and own their own AI memory in markdown format, capturing answers from any AI tool, editing them, and using them as portable context anywhere, positioning itself as user-authored curation rather than AI-extracted memory like competing services. - [Publish my meeting notes to mdfy](https://memory.wiki/r-um_oJp) mdfy is a document management system that allows users to create, read, update, list, and publish markdown documents with shareable URLs, supporting both local and extended tools for collaborative workflows across multiple AI assistants. - [QuickLook — Quick Start](https://memory.wiki/womPEbUm) QuickLook is a macOS extension that renders Markdown files as formatted previews when you press Space in Finder, powered by the mdfy.cc rendering engine and automatically installed with the mdfy Mac app. - [Chrome Extension — Quick Start](https://memory.wiki/mcRfLTP7) The mdfy Chrome extension captures conversations from ChatGPT, Claude, and other AI platforms, as well as any webpage content, converting them to formatted Markdown and generating shareable URLs while keeping captures private by default. - [SNS Launch Execution Plan](https://memory.wiki/jryfJV4D) The SNS launch plan for PastLife establishes a phased approach starting with profile setup across five platforms (Instagram, TikTok, X, YouTube, Threads), followed by seeding six emotion-driven posts over three days featuring Soul Cinema videos, past life portraits, and chat features before opening the prelaunch gate. Subsequent phases involve daily feature rotation posts, community engagement on Reddit and Facebook, and influencer outreach to drive user acquisition and engagement through character-driven messaging centered on Seer Mir's soul-reading capabilities rather than generic AI positio ### RAG *concept • weight 115 • 1 doc* > Retrieval-augmented generation technique that Memory.Wiki uses but reframes as a product feature rather than technical label. - [How Memory.Wiki does RAG / Memory.Wiki Memory](https://memory.wiki/how-mdfy-rag-works) Memory.Wiki reframed its retrieval system from a technical RAG-focused approach to a product-oriented memory system, maintaining the same underlying architecture of HTTP endpoints, chunked hybrid retrieval, and idempotent embeddings. _Related:_ renamed to → **mdfy Memory** · reframed as → **mdfy Memory** · replaced by → **mdfy Memory** · rebranded as → **mdfy Memory** · renamed as → **mdfy Memory** ### Hybrid Retrieval *concept • weight 110 • 5 docs* > Technical approach combining chunked indexing with semantic search for precise question-targeted recall. - [How Memory.Wiki does RAG / Memory.Wiki Memory](https://memory.wiki/how-mdfy-rag-works) Memory.Wiki reframed its retrieval system from a technical RAG-focused approach to a product-oriented memory system, maintaining the same underlying architecture of HTTP endpoints, chunked hybrid retrieval, and idempotent embeddings. - [What is Memory.Wiki](https://memory.wiki/what-is-mdfy) Memory.Wiki is a vendor-neutral URL-based personal knowledge system that lets users capture and organize AI conversations and documents in a single hub that any AI can read as context. The core innovation is replacing vendor-locked memory layers with a shareable markdown URL that works across ChatGPT, Claude, Cursor, and other AI tools without requiring SDKs or plugins. - [Memory.Wiki Memory](https://memory.wiki/mdfy-memory) Memory.Wiki Memory is a public, human-readable memory layer that lets you capture answers from AI chats, organize them into a hub at a permanent URL, and share that hub with any AI via a simple HTTP recall endpoint that supports chunked retrieval, hybrid search (BM25 + vector), and privacy-enforced filtering. Unlike vendor-specific memory systems, it's not locked behind an SDK or MCP server and can be pasted into any AI as markdown context. - [Document, Bundle, Hub](https://memory.wiki/mdfy-three-primitives) Memory.Wiki uses a single URL primitive at three nested scopes (document, bundle, hub) to organize knowledge artifacts, each fetchable as markdown by any AI via HTTP. All three levels share the same viewer, fetch path, and embedding pipeline, allowing users to scale from individual documents to curated topic collections to their entire personal knowledge graph. - [How Memory.Wiki keeps your docs, bundles, and hub fresh](https://memory.wiki/RUMdz2fQ) Document body markdown propagates to AI URLs within roughly 60 seconds of save · Bundle graph requires manual Re-analyze click when member doc content changes · Hub concept index updates automatically within seconds but enforces 30-minute per-doc cooldown during editing · Re-analyze button only re-extracts changed docs, capped at 50 per click · Concept extraction uses LLM calls and is not auto-triggered to preserve token cost and editing focus _Related:_ serves domain → **Knowledge Management** ## Concept relations _20 highest-weight edges between the top concepts._ - **Real-Time Notification Service** implements **Multi-Channel Delivery** - **Matrix Multiplication** core operation in **Neural Networks** - **Singular Value Decomposition** enables **Dimensionality Reduction** - **Backpropagation** trains **Neural Networks** - **Code Verifier** hashed into **Code Challenge** - **Real-Time Notification Service** enforces **Rate Limiting** - **Principal Component Analysis** implements **Dimensionality Reduction** - **User Preference Management** cached in **Redis** - **Real-Time Notification Service** uses **Priority Router** - **PKCE** extends security of **OAuth 2.0** - **Code Verifier** hashed to create **Code Challenge** - **Eigenvalues and Eigenvectors** foundation for **Principal Component Analysis** - **User Preference Management** persisted in **PostgreSQL** - **Real-Time Notification Service** routes through **Priority Router** - **PKCE** extends and secures **OAuth 2.0** - **Gradient** computed via **Backpropagation** - **Real-Time Notification Service** persists to **PostgreSQL** - **Rate Limiting** stores state in **Redis** - **Eigenvalues and Eigenvectors** enables **Principal Component Analysis** - **Rate Limiting** backed by **Redis** ## All documents _77 public documents, ordered by recency. Each entry includes a one-paragraph gist for quick scanning. Fetch any as `https://memory.wiki/raw/?compact=1` for the full body._ - [v8 Release Todos](https://memory.wiki/EtJSPPfX) The v8 release cycle introduces per-user AI usage tracking and site-specific intent capture while resolving critical QuickLook and body-capture bugs across desktop and web platforms. Most channels are live or ready for deployment, though several mobile and store-specific submissions remain pending final asset production and configuration. _sections:_ TL;DR — what landed in the last two weeks: Nine channels touched (web, desktop DMG, chrome ext, vscode, cli, mcp, iOS, Android, Mac App Store). Two channels are fully live; the rest are blocked on either | … - [Memory.Wiki v8 Strategy and Vision](https://memory.wiki/D9kWUoDr) The collected documents outline Memory.Wiki's evolution toward becoming a cross-AI knowledge layer, positioning itself as the URL delivery system for AI context rather than another note-taking app. The v8 direction emphasizes sustainable craftsman SaaS growth while solving the core problem of users… _sections:_ … - [memory.wiki — Founder Sprint / US Track 미팅 준비](https://memory.wiki/B8k1in4-) memory.wiki is an infrastructure layer that enables any AI tool (Claude, ChatGPT, Cursor, etc.) to fetch the same document payload via a single URL, combining the document text with an AI-generated knowledge graph. The product allows developers to capture knowledge from multiple sources, automatically organize it with background AI analysis, and share it across different AI platforms seamlessly. _sections:_ TL;DR: memory.wiki — Personal knowledge layer for the AI era.URL delivery infrastructure for cross-AI workflows. 모든 doc이 markdown + AI-generated knowledge graph로 fetch; Capture: MCP server + Chrome ext + QuickLook이 1차 entry. 나머지 4개 channel (Mac app, VSCode extension, iOS app, Android app)은 retention/expansion 레이어; Organize: background AI가 자동으로 themes/insights/concept ontology/cross-doc edges 추출; Use: URL 한 줄을 어느 AI에 붙여넣어도 본문 + analytical graph 가 함께 fetch; Cross-AI (Claude, ChatGPT, Gemini)100% benchmark 검증 완료, 6월말 9-surface 동시 public 런치; 솔로 + Claude Code pair, self-funded, 3개월 metric collection 중 seed raise 계획; … | … - [----------------------------- tuning knobs --------------------------------](https://memory.wiki/1_r5VqyU) This is a raw prototype Vision Pro-style controller that tracks iris gaze from a webcam to move the macOS cursor and detects thumb-index pinches to trigger clicks, using MediaPipe for face and hand detection and a quadratic calibration map to convert normalized gaze ratios to screen coordinates. - [Gaze Control — webcam-only multimodal macOS controller](https://memory.wiki/xH0i5alB) A macOS controller project uses only the built-in webcam to enable Vision Pro-style interaction through gaze-based element selection combined with head pose, finger pinches, and gestures. Rather than tracking a cursor, gaze selects UI elements via the Accessibility API while pinches activate them, overcoming webcam gaze imprecision by snapping focus to nearby on-screen elements. _sections:_ Goal: Build a Vision Pro–style controller for a flat screen (regular Mac display) driven by | Hard constraints: Webcam is the ONLY input sensor. No Tobii, no Leap Motion, no depth cam.; Target OS: macOS (Apple Silicon).; The end user (project owner) does not write code directly — explain changes plainly and | Core design principle (do not violate): Do NOT build a floating gaze cursor. Webcam gaze is only accurate to ~1–4 cm and jitters; Gaze selects/highlights the UI element you're looking at (focus), it does not paint pixels.; A pinch activates the focused element.; Use the macOS Accessibility API (AXUIElement) to read on-screen element frames so gaze can | … - [Memory.Wiki v8 Plan](https://memory.wiki/SKaY7VJP) Memory.Wiki v8 is a productized knowledge graph platform designed to eliminate context re-explanation by providing a single shareable URL that different AI agents can consume in optimized formats (markdown for AI, HTML for humans). The plan includes a three-stage workflow (capture/organize/use), native mobile apps, cross-app integrations, dual-layer storage preserving original content while adding AI-generated metadata, and a freemium pricing model targeting AI-fluent developers, launching in 20 weeks across 9 surfaces simultaneously. _sections:_ Type 1: Metadata (no approval, no new entity): | 무엇 | 언제 | | Type 2: Bundle (My + AI 두 namespace) | Type 3: Synthesis docs (AI 가 새 doc 생성) — **DROPPED 2026-05-28**: 원래 plan: Bundle summary doc / Weekly digest / Synthesis across docs / About draft 를 AI 가 미리 생성.; LLM 비용 발생; Stale 문제 (원본은 바뀌고 synthesis 는 멈춤); USE surface 중복 (paste-anywhere 와 같은 일); User-written: 사용자 아바타 + dot; AI-generated: ✨ + agent 이름 (Claude / GPT / background); …; Edited-by-you (was AI): 펜 아이콘 + "originated from AI"; … | Tier A — Sharing primitives (v8 launch): | 항목 | 변경 | | … - [Memory.Wiki Android — iOS Parity Sprint (2026-05-30)](https://memory.wiki/47ieubnq) In a single day, the Memory.Wiki Android app was brought to full feature and visual parity with iOS while adding Android-native affordances like share intents, app shortcuts, and home-screen widgets across 25 commits and 5,000 lines of code. The app transformed from a visually incomplete port into a native Android product with proper branding, interactive components, and platform-specific functionality. _sections:_ Phase 0 — The mess: The founder's words verbatim:; 5-tab bar with subtle borderless icons, no labels, static blob; Auth using Lucide.Apple fruit emoji for Sign in with Apple (HIG violation); Tab center "Start" tap was dead (WebView swallowed touches); MDs / Bundles / Start / etc. used basic Material chips and dot indicators; No long-press menus, no pin/star, no edit/delete, no share, no semantic search; …; No animated blob, no ambient backdrop, no skeletons-with-shimmer; … | … - [조현상, Raymind.ai / memory.wiki](https://memory.wiki/RwrJZ3wc) A 15-year product leader has built memory.wiki, a personal knowledge hub that lets users own and port their context across multiple AI tools via URLs, launching to developers in mid-June 2026. The core innovation is enabling portable memory across AI providers (Claude, ChatGPT, Gemini, etc.) through capture, organization, and sharing mechanisms including MCP integration for AI agents. _sections:_ About me: 15년 넘게 제품과 디자인을 영국, 한국, 사우디 3개국에서 리딩해 왔습니다; 직전: Humain (사우디 국가 AI 프로젝트, 2025\~2026) AI Product & Experience Lead. Humain OS의 제품/경험 조직을 0에서 셋업.; Devsisters (2021\~2024) Group Director. 쿠키런 IP VR 타이틀을 Meta 파트너십으로 Quest Store 출시.; Kakao IX UK (2018\~2021) Regional Director. 카카오의 첫 유럽 오피스를 0에서 셋업, KakaoTalk과 Kakao Friends IP 유럽 사업 총괄.; Saudi Aramco (2017\~2018) UX Lead. 세계 최대 IPO 직전 Aramco 디지털 시스템 UX 표준 정립.; 그 전: London에서 AKQA, Razorfish 등을 거쳐 Nike, Volvo, Barclays, Virgin Atlantic의 글로벌 디지털 프로덕트 리딩.; …; 학력: MFA Goldsmiths (Computational Studio Arts), BA Hons Central Saint Martins (Graphic + Interaction Design, 1st Class).; … | … - [Mdfy v6 recap](https://memory.wiki/8QB0olhs) memory.wiki is a tool that converts user-created markdown into URLs that any AI can read, automatically organizing the knowledge into a graph so users can deploy their information across different AI platforms without re-explaining themselves. The founder plans to launch in August and eventually position it as the default memory layer for major LLM services. _sections:_ User: 다시한번 나한테 아주 쉽게 설명해줘봐. | Claude: 좋아요. 복잡한 분석 잠시 옆에 두고, 지금까지 알게 된 걸 그냥 쉽게 풀어볼게요. | memory.wiki가 뭐예요 (한 문장): > 사용자가 만든 markdown을 어떤 AI든 읽을 수 있는 URL로 만드는 도구. | ㅇ더 구체적으로: 매일 ChatGPT, Claude, Cursor에 질문하잖아요. 좋은 답변 받고. 그리고 닫아요. 사라져요.; 한 답변 → memory.wiki/abc123 (Doc URL); 5개 답변 묶음 → memory.wiki/b/xyz (Bundle URL); 내 전체 모음 → memory.wiki/hub/myname (Hub URL) | 3단계로 풀면: 여러 곳에서 markdown 모아요.; Chrome 확장으로 ChatGPT 답변 한 번 클릭; VS Code에서 파일 publish; 터미널에서 cat file.md | mdfy; Mac에서 클립보드 자동; 직접 입력; …; 각 문서에서 concept 추출 (자동); …; 비슷한 문서 연결 (자동); …; Bundle 만들면 themes/insights 분석 (자동); …; 시간 따라 graph가 자라남; …; ChatGPT에 paste → AI가 fetch; …; Claude에 paste → AI가 fetch; …; Cursor에 paste → AI가 fetch; … | … - [Memory.Wiki iOS — Spec](https://memory.wiki/fD70bEXD) Memory.Wiki iOS is a native companion app to the web platform that provides fast capture and a polished reader interface while maintaining exact brand parity with the web surface. The app ships with authentication via Apple, Google, GitHub, and Email through Supabase, with Share Extension, Camera, Widget, Spotlight, and background sync queued for development. _sections:_ In (W9–W12): | Surface | Status | | … - [[mdfy.cc](http://mdfy.cc) Launch Checklist](https://memory.wiki/P67ESz3Q) Memory.Wiki publishes Document, Bundle, and Hub primitives as URLs every AI can fetch · Cross-AI wedge verified at 100% on truly unseen content across Claude, OpenAI, Gemini · MWBench is the open methodology, public at `/mwbench`, reproducible from the repo · Legacy mdfy brand removed from user-facing surfaces; deprecated env var aliases kept · New animated blob logomark always paired with "memory.wiki" wordmark, never standalone · No middle-dot, em-dash, arrow, check mark, or emoji on UI surfaces or LLM-generated content · CLI 1.4.2 ships auto-claim of anonymous docs after… _sections:_ captured: 2026-05-25 author: founder + AI collaborator status: strategy doc, homepage source, comprehensive aggregation supersedes: v7-revised (memory.wiki/nvF3Li2x), v7 FINAL (memory.wiki/xv6A2DKS), v6 FINAL (memory.wiki/\_4iafQ8K): This doc is the single reference for what Memory.Wiki is right now and where v8 takes it. Sections 1 and 2 are the audit of today. Section 3 is the v8 forward p | … - [Table Test 3](https://memory.wiki/lQss-7jJ) I cannot summarize a substantive claim from this document, as it contains only a blank table, empty checkboxes, and no meaningful content. - [Memory.Wiki v8 Strategy and Vision](https://memory.wiki/eqjANq9c) Memory.Wiki v8 aims to become a cross-AI knowledge layer that delivers user context via shareable URLs (Documents, Bundles, Hubs) to eliminate the need to re-explain information across different AI tools, with sustainable SaaS growth targeting 1k-10k power users and $2-5M ARR in five years. The strategy emphasizes AI-optimized context packaging and bundles over embedded chat, leveraging a structural advantage that prevents competing AI companies from building their own cross-platform memory layer. _sections:_ … - [Memory.Wiki launch drafts](https://memory.wiki/FX0zO5zK) Three external launch drafts: Show HN post, 10-tweet thread, LinkedIn post · Core claim across all: one URL works across Claude, ChatGPT, and Gemini, 100% accuracy on unseen content · All drafts link to the public proof at memory.wiki/mwbench · None of the drafts use the legacy "mdfy" branding · Drafts lead with "open cross-AI eval" or "cross-AI verification" instead of the project codename, since MWBench is not yet a recognised name · Show HN draft includes prepared replies for the four most likely comment threads · Tweet thread is 10 numbered posts under the 280-char limi… _sections:_ … - [Document, Bundle, Hub](https://memory.wiki/mdfy-three-primitives) Memory.Wiki uses a single URL primitive at three nested scopes (document, bundle, hub) to organize knowledge artifacts, each fetchable as markdown by any AI via HTTP. All three levels share the same viewer, fetch path, and embedding pipeline, allowing users to scale from individual documents to curated topic collections to their entire personal knowledge graph. _sections:_ Document: memory.wiki/; AI fetch: same URL with Accept: text/markdown header (or /.md) returns the markdown body with frontmatter.; Embeddable: every public doc carries a 1536-dim vector and per-heading chunk vectors.; Editable: the owner edits in WYSIWYG; non-owners see the rendered viewer. | Bundle: memory.wiki/b/; Bundle Spec v1.0 conformant: stable shape, parseable by future tools.; Per-doc annotation: each member can carry a "why this is in the bundle" note.; Discoverable: owners can opt their bundle into the public /shared feed. | … - [Memory.Wiki roadmap](https://memory.wiki/mdfy-roadmap-2026) Memory.Wiki is a document management and semantic search platform currently offering URL primitives at multiple scopes, multi-source capture, embeddings-based retrieval with vector and BM25 hybrid search, auto-synthesis features, and cross-AI verification at 100% accuracy. Upcoming features include auto-re-embedding on metadata changes and a cross-encoder reranker, while the team is deliberately deferring mobile apps and team accounts in favor of focusing on core functionality. _sections:_ … - [Memory.Wiki FAQ](https://memory.wiki/mdfy-faq) Memory.Wiki is a publishing platform designed so AI systems can read human knowledge bases as public markdown URLs, functioning as a memory layer across multiple AI tools rather than within a single vendor's ecosystem. It differs from personal knowledge bases like Notion by prioritizing AI readability, and from agent memory systems like mem0 by operating as a publishing layer rather than a backend API. _sections:_ How is Memory.Wiki different from Notion / Obsidian?: Notion and Obsidian are great as personal knowledge bases for humans. Memory.Wiki is built so the AI can read it. The output is a public URL whose markdown is w | Do I need an account?: No. You can capture and share without signing up. Anonymous captures get a cookie that groups them, and you can sign in later to claim them all into your hub. | How does Memory.Wiki compare to mem0 / OpenMemory / Letta?: Those are backend memory layers for AI agents. They expose an API or MCP server, store atomic memories, and inject context automatically into one tool. Memory.W | … - [Bundle Spec v1.0](https://memory.wiki/mdfy-bundle-spec) Bundle Spec v1.0 defines a stable markdown format for AI systems to fetch curated document collections from memory.wiki, with numbered sections, source citations, and privacy protections for restricted documents. The spec includes frontmatter metadata, per-document annotations for context, and is designed to enable accurate AI retrieval and citation across multiple platforms. _sections:_ URL shapes: memory.wiki/b/ for the human-rendered bundle viewer; memory.wiki/b/.md for the raw markdown payload; memory.wiki/raw/bundle/ (same as .md) | Frontmatter: yaml | Body shape: markdown | 1. : Source: https://memory.wiki/ | 2. : Source: https://memory.wiki/ | Privacy: Member docs that became private after the bundle was created are filtered out at fetch time. The bundle structure stays intact (numbered sections), but unfetcha | … - [/memory.wiki in your AI tool](https://memory.wiki/mdfy-skills-overview) Memory.Wiki is a skill installer that adds capture, bundle, and hub URL functions to AI coding tools like Claude Code, Cursor, Codex CLI, and Aider through simple markdown instructions. Once installed, users can save conversation segments, generate bundled documentation, and share their hub URL across any AI tool. _sections:_ Install (one line per tool): bash | What it does, once installed: The same three verbs in every tool: | Why a skill rather than a plugin: A skill is plain markdown that the AI reads as instructions. No binary, no API key required (signed-out users get an anonymous capture cookie that they can clai - [Memory.Wiki vs vendor memory](https://memory.wiki/mdfy-vs-vendor-memory) Memory.Wiki and vendor memory (like ChatGPT's built-in memory) serve different purposes: vendor memory personalizes within a single tool using automatic extraction, while Memory.Wiki enables human-curated knowledge to be shared across multiple AI tools and with other people via public URLs. The two are complementary, with vendor memory best for invisible preferences within one tool and Memory.Wiki best for substantive knowledge that needs reuse across tools and humans. _sections:_ What vendor memory is good at: Stays inside the chat surface. ChatGPT memory is invoked transparently inside ChatGPT. You don't paste anything; the model just "remembers."; Auto-extracts atomic facts. "User prefers tabs over spaces." "User is building an iOS app." Small, structured, automatic.; Personalizes within one tool. The longer you use ChatGPT, the more it learns you in ChatGPT. | … - [Memory.Wiki Memory](https://memory.wiki/mdfy-memory) Memory.Wiki Memory is a public, human-readable memory layer that lets you capture answers from AI chats, organize them into a hub at a permanent URL, and share that hub with any AI via a simple HTTP recall endpoint that supports chunked retrieval, hybrid search (BM25 + vector), and privacy-enforced filtering. Unlike vendor-specific memory systems, it's not locked behind an SDK or MCP server and can be pasted into any AI as markdown context. _sections:_ What "memory" means here: Every chat with ChatGPT, Claude, or Cursor produces useful answers. Tomorrow they're gone. The chat is closed, the share link rots, the next session has no idea | The surface (what you actually do): Paste a ChatGPT or Claude share URL into the editor.; /memory.wiki capture from inside Claude Code, Cursor, Codex CLI, or Aider.; Drop a PDF, DOCX, or transcript file.; Paste the hub URL into any AI. They fetch the markdown index and load your knowledge as context.; Hit the recall endpoint for question-targeted retrieval. Much fewer tokens, much higher precision: | … - [조현상 / Hyunsang Cho](https://memory.wiki/3JhXI73T) Hyunsang Cho is an AI product and experience executive with over 15 years of leadership experience building product and design organizations across the UK, Korea, and Saudi Arabia, currently running an independent product studio called Raymind.AI that develops and launches consumer apps, developer tools, and AI engines. _sections:_ 현재: 2025 – 현재 · 서울 / 런던 | 경력: 2025년 4월 – 2026년 4월 · 리야드, 사우디아라비아; 대규모 AI 플랫폼 전체의 제품 비전과 로드맵 수립; 프로그램 확장에 맞춰 작동하는 거버넌스와 리뷰 체계 설계; 웨어러블, 음성, 앰비언트 AI 경험으로의 확장 주도; 리서치, 디자인, 문서화에 AI 도구 도입; 제품, 개발, 리더십 팀 간의 협업 방식 정의; …; XR 경험이 없던 회사에서 VR 제품 팀 구축; …; Meta와의 전략적 플랫폼 파트너십 체결, Quest Store 출시; …; 프로덕트, 엔지니어링, 아트, 마케팅을 하나의 팀으로 통합 운영; …; Meta 플랫폼 공식 프로모션 및 리테일 쇼케이스 선정; …; 런던 법인 처음부터 구축. 법인 설립, 팀 구성, 운영 체계; …; 영국, 프랑스 등 주요 시장에서 라이선싱과 리테일 계약 체결; …; IMG와 제휴해 IP의 글로벌 입지 확장; …; Brand Licensing Europe 등 산업 행사에서 회사 대표; … | … - [Cursor for code, Claude for research, finally on the same page](https://memory.wiki/case-cross-tool-handoff) Install `/memory.wiki` once takes 30 seconds via a single curl command · Per-capture overhead is under 5 seconds · Per-conversation context load is roughly 3 seconds (paste the hub URL) · Same hub URL works across Cursor, Claude Code, and any other AI tool · Verified across Claude, OpenAI, and Gemini at 100% accuracy via [MWBench](/mwbench) _sections:_ The pain: I do real coding in Cursor. I do research and architecture thinking in Claude. They don't share memory. Every time I switch, I re-paste the same context: "here' | What I do now: In Cursor, after we figure out a non-trivial decision: save this to memory.wiki as "Auth provider tradeoffs". The skill captures the conversation segment as a p | What changed: The handoff is one capture command, one paste.; I never re-explain the project to a fresh chat.; The decision history is searchable as one knowledge layer, not split across vendor walls. | … - [How Memory.Wiki does RAG / Memory.Wiki Memory](https://memory.wiki/how-mdfy-rag-works) Memory.Wiki reframed its retrieval system from a technical RAG-focused approach to a product-oriented memory system, maintaining the same underlying architecture of HTTP endpoints, chunked hybrid retrieval, and idempotent embeddings. - [Karpathy's hand-curated LLM wiki, without the hand-curation](https://memory.wiki/case-personal-llm-wiki) Memory.Wiki automates 80% of the maintenance burden in Karpathy's hand-curated personal LLM wiki system by automatically capturing content, synthesizing wiki pages, building semantic graphs, and surfacing gaps, while keeping humans in the loop only for accepting proposed wiki updates. _sections:_ The pain: [Andrej Karpathy described the problem](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f): keep a personal LLM wiki of the answers worth rememb | What Memory.Wiki does: Same shape as Karpathy's. Different effort: | What this case actually replaces: If you're already running a personal Notion, Obsidian, or DEVONthink for AI outputs and feel the hand-curation tax, Memory.Wiki is the lower-effort version of t | … - [Sharing AI conversations the way you'd share a Notion link](https://memory.wiki/case-share-with-team) A tool called Memory.Wiki lets users save Claude conversations as permanent shareable URLs that work for both human readers (with formatting) and AI systems (as raw markdown), solving the problem of sharing AI chat context with teammates without reformatting or losing functionality. _sections:_ The pain: I had a really useful Claude session about our deploy pipeline. Three colleagues needed to read it. The options were:; Screenshot the chat: terrible to skim, breaks links.; Copy and paste the markdown: loses code highlighting, no permanent URL.; Send the Claude share link: only works for ChatGPT or Claude users with the right account, breaks if I edit settings.; Re-explain in Slack: 30 minutes I don't have. | What I do now: In Claude Code: save this to memory.wiki as "Deploy pipeline review". Get back https://memory.wiki/abc123. Paste in Slack. | … - [Onboarding every new Claude Code session in one line](https://memory.wiki/case-claude-md-personal-context) A developer can eliminate repetitive project context setup across Claude Code sessions by adding a single Memory.Wiki hub URL reference to their ~/.claude/CLAUDE.md file, allowing Claude to automatically fetch relevant project details on demand instead of re-explaining them each time. This same approach works across other AI coding tools like Cursor and ChatGPT. _sections:_ The pain: Every time I open a new Claude Code session in a different repo, or even after a long break, I'd spend 5 minutes re-pasting the same project background. "We use | What I did: Visited memory.wiki/install, signed in, copied the snippet, appended it to ~/.claude/CLAUDE.md: | Personal context (Memory.Wiki hub): Hub URL: https://memory.wiki/hub/<me> | What changed: Now every Claude Code session, anywhere on my machine, automatically has my hub URL. When I ask a question that needs project context, Claude fetches the hub an | Time: One-time setup: 1 minute.; Per new chat: 0 minutes. The hub URL is already in CLAUDE.md. | … - [How Memory.Wiki keeps your docs, bundles, and hub fresh](https://memory.wiki/RUMdz2fQ) Document body markdown propagates to AI URLs within roughly 60 seconds of save · Bundle graph requires manual Re-analyze click when member doc content changes · Hub concept index updates automatically within seconds but enforces 30-minute per-doc cooldown during editing · Re-analyze button only re-extracts changed docs, capped at 50 per click · Concept extraction uses LLM calls and is not auto-triggered to preserve token cost and editing focus _sections:_ TL;DR: | Layer | What | How fresh | Anything to click? | | … - [What is Memory.Wiki](https://memory.wiki/what-is-mdfy) Memory.Wiki is a vendor-neutral URL-based personal knowledge system that lets users capture and organize AI conversations and documents in a single hub that any AI can read as context. The core innovation is replacing vendor-locked memory layers with a shareable markdown URL that works across ChatGPT, Claude, Cursor, and other AI tools without requiring SDKs or plugins. _sections:_ The one-line version: A captured ChatGPT answer becomes memory.wiki/<id>. Forty captures roll up into memory.wiki/hub/<you>. You paste that hub URL into Claude, ChatGPT, Cursor, or C | Why a URL: Vendor memory layers (ChatGPT memory, Claude projects, Cursor docs) all live behind walls. They don't talk to each other, you can't share them, and you can't pa | Three primitives, one shape: Document at memory.wiki/<id> is one captured answer, paper, or transcript.; Bundle at memory.wiki/b/<id> is a curated grouping of docs around a topic, with its own URL.; Hub at memory.wiki/hub/<you> is your whole knowledge layer as a single deployable URL. | … - [How Memory.Wiki works](https://memory.wiki/how-mdfy-works) Memory.Wiki is a personal knowledge hub that captures AI conversation outputs, synthesizes them into structured wiki pages, and maintains a searchable schema so users can retrieve and reuse their knowledge across different AI tools through a simple URL interface that works universally across ChatGPT, Claude, and other AI platforms. _sections:_ The problem: Every day, you get great answers out of an AI. Tomorrow, the AI doesn't remember any of them. The bookmark, the screenshot, the transcript copy you took, all of | Three layers: Memory.Wiki follows the same architecture Karpathy laid out (raw, wiki, schema), exposed as one product surface instead of three folders. | … - [MWBench v1 — Cross-AI eval for Memory.Wiki](https://memory.wiki/gzuNdh_P) Round 9 closes the unseen-hub gap to zero: zorblax reaches 100% on paste full, paste compact, AND browse — same as raymindai · Cross-AI wedge confirmed without memorization advantage — 100% on synthetic content the AIs have never seen · Two independent axes: Paste vs Browse (how AI receives corpus) and Familiar vs Unseen (whether AI has seen hub during training) · Browse + Unseen is the actual real-world wedge measurement — 100% across Claude/OpenAI/Gemini · Round 9 fix: extractSkeleton now bullet-aware. Sections written as bullet lists no longer lose everything after the f… _sections:_ 🎯 End-to-end result — wedge survives the unseen-hub test: | | raymindai (familiar) | mwbench-zorblax (synthetic, unseen) | | Two axes — Browse vs Paste, Familiar vs Unseen: | Paste mode | Browse mode |; Paste + Familiar — internal sanity ✓; Paste + Unseen — does the delivery format work on novel content? ✓; Browse + Familiar — does AI tool-use work? ✓; Browse + Unseen — the actual real-world wedge ✓ 100% | … - [MWBench Round 6-7 — Browse mode, the honest test](https://memory.wiki/D-TSWhl4) Round 7 browse-mode accuracy: Hub 98.3% / Bundle 96.7% / Doc 90% averaged across Claude/OpenAI/Gemini · Tool-use rate is 100% on every runner — AIs reliably fetch Memory.Wiki URLs when handed them · Hub URL browse jumped 41.7% → 98.3% after deploying knowledge graph (concept_index + concept_relations + bundle AI graphs) to llms-full.txt · Doc URL browse jumped 80% → 90% after adding documents.ai_graph column (themes / insights / takeaways / openQuestions) and surfacing it in /raw/<id> · Browse runners need a "last turn force final answer" pattern — without it, OpenAI/Gemini… _sections:_ 🎯 Round 7 result — browse-mode wedge holds: Each runner gets ONLY the URL + question. Must call a fetchurl tool, get markdown, then answer. | What this proves: When a user pastes memory.wiki/hub/<slug>, memory.wiki/b/<id>, or memory.wiki/<id> into ChatGPT, Claude.ai, or Gemini, and the AI has tool use available, the AI | The round 6 → 7 journey: | URL | Claude | OpenAI | Gemini |; 40 top concepts with weight + descriptions; 30 concept-to-concept relations; Bundle AI graph summaries (themes / takeaways); Hub 41.7% → 98.3% (+56.6pp); Bundle 93.3% → 96.7%; …; Doc unchanged at 80%; … | Summary: 1-2 sentences | Themes: theme 1, theme 2, ... | … - [Bundle & Doc URL enrichment — verified at 100% cross-AI](https://memory.wiki/yGk04Hee) 10 bundle queries × 3 runners × 2 modes = 60 cells, all 100% · 10 doc queries × 3 runners × 2 modes = 60 cells, all 100% · Cross-AI consistency 100% across both URL shapes · Bundle compact 8–9× cheaper in input tokens vs bundle full · Doc URLs are small enough that compactMarkdown gives no size reduction · Shared `apps/web/src/lib/doc-gist.ts` powers gist chain across hub/bundle/doc routes · `run-bench.mjs` takes per-query `scope` + `scope_id`; same harness handles all three URL shapes · Combined with [MWBench Round 4](https://mdfy.app/gzuNdh_P) for hub URLs, **every URL sh… _sections:_ 🎯 Result (Round 5, MWBench): 10 bundle queries × 3 runners × 2 modes = 60 cells, all 100%. | The shape problem: A Memory.Wiki user can paste three URL shapes into an AI: | What changed: Digest mode now mirrors the hub all-docs catalog: | Concepts in this document: <concept> (type) | Concept relations (within this doc's concepts): <concept A> relationlabel <concept B> | … - [memory.wiki 사업계획 v7-revised](https://memory.wiki/nvF3Li2x) Cross-AI layer is structurally impossible for OpenAI and Anthropic to build · iOS Share Sheet is the single capture feature for launch · Bundle auto-generation is the core digestion commit · Embedded chat with hub context is the utilization feature · Hard cutover brand migration on launch day replaces 16-week phased approach · Launch timing is July mid (Week 16) to precede LLM Wiki and establish category · First 100 paid users come from existing mdfy.app graph mining, not HN/PH · Pricing consolidates to 3 tiers (Free/Pro $12/Team $24) with Build tier dropped · Bundle Spec R… _sections:_ 한 줄: > memory.wiki — your knowledge graph as a URL for any AI. | v7과 thesis는 같다. 다른 것: 1. Launch feature: 8개 → 3개 (each tier 1개씩) | 핵심 cut: | 영역 | v7 commit | v7-revised commit | | Bet 1: Cross-AI is structurally impossible for OpenAI/Anthropic: 이게 wedge다. v7에서는 "Risk 1: 거인 진입"으로 묻혀있었지만, 사실 이게 narrative의 정수. | Bet 2: Mobile capture가 진짜 missing piece: v7은 voice를 "Phase 3"로 미뤘는데, voice/mobile이 capture funnel의 가장 큰 hole. v7-revised는 iOS Share Sheet를 Tier 1의 단일 commit으로 정함. Voice capture는 launch 후 1순위. | … - [v8 Idea](https://memory.wiki/pCiEhvu2) Memory.Wiki is positioned as a context delivery layer for AI tools, not a knowledge graph product · The core value proposition is eliminating the need to re-explain context across ChatGPT, Claude, Cursor, and other AI tools · Launch should focus on the URL-based context sharing flow (upload → auto-bundle → shareable URL) rather than embedded chat · Early GTM should target existing Markdown users and emphasize "Your AI memory URL is ready" over discount messaging · Product must avoid expanding into social features, public feeds, or community aspects until after product-market fit _sections:_ 1. 지금 thesis는 강하다: memory.wiki — your knowledge graph as a URL for any AI는 좋다. 특히 문서 안의 핵심인 \\“OpenAI/Anthropic은 경쟁사까지 먹이는 cross-AI memory layer를 만들기 어렵다”\\는 포지셔닝은 강한 wedge다. [Mem | 2. 제일 위험한 착각: “Graph가 product”라고 말하면 창업자에게는 맞지만, 사용자에게는 너무 추상적이야. | 3. v7-revised에서 가장 잘한 결정: 8개 feature를 3개로 줄인 건 맞다. iOS Share Sheet, Bundle 자동 생성, Embedded chat만 남긴 판단도 launch 가능성 면에서는 좋다. 문서도 “8개 → 3개, 20-26주 → 12-14주”로 정리하고 있다. [Memory.Wiki](https:/ | 4. 성공하려면 카테고리를 바꿔야 한다: 이 앱을 “AI wiki”라고 하면 Notion, Obsidian, Readwise, Mem, Tana와 비교된다. | 5. 내가 고칠 GTM: 문서의 “기존 mdfy graph mining first”는 매우 맞다. 첫 100 paid는 HN에서 안 나온다는 판단도 맞다. [Memory.Wiki](https://memory.wiki/nvF3Li2x) | … - [mdfy — a16z speedrun pitch deck (content)](https://memory.wiki/gnEMFJgI) mdfy is a URL-based memory layer that any AI can read by pasting a link into chat · AI users currently work across five isolated tools (Claude, ChatGPT, Gemini, Cursor, MCP hosts) with no shared memory between them · Cross-AI memory delivery is structurally impossible for any single AI company to build without undermining their own competitive moat · Founder Hyunsang Cho shipped mdfy's full stack (web, MCP, VS Code, desktop, Chrome, CLI) in 12 weeks and has five live Raymind products · mdfy bakes a concept graph into each URL payload so receiving AIs get navigation and cont… _sections:_ Slide 1 — Title: HEADLINE (huge, top-left or center); Negative space dominant. Just the wordmark "mdfy" in display weight + tagline below.; Background: dark (matches mdfy.app dark theme).; Bottom strip: founder + URL + email in mono caption. | Slide 2 — The Problem: HEADLINE; Every conversation starts from zero.; Every tool re-uploads the same context.; Every team re-explains its work.; 5 logo lockup at top: Claude · ChatGPT · Gemini · Cursor · MCP hosts; Below each, a small loop arrow pointing back to itself (every chat = isolated memory island); …; Center bottom: greyed-out word "MEMORY" with a strikethrough; … | … - [a16z application](https://memory.wiki/wNEDgXMs) a16z evaluates founders on full-time commitment status and equity ownership · founders must describe their relevant professional experience and domain expertise · startups must fit into primary categories like B2B, Consumer, Deep Tech, Infrastructure, Healthcare, or Crypto · applicants must pitch their startup in 10 words or fewer · a16z requests optional supporting materials including pitch decks, traction metrics, and funding history _sections:_ Team: We back exceptional founders. Tell us who’s building this and why you’re the team to make it happen.Required fields are marked with an asterisk (\). | Startup Details: Help us understand your startup. The problem you're solving, your solution, and where you are today.Required fields are marked with an asterisk (\). | Additional Information: Show Us MoreAny additional information you share with us adds important context that we review and significantly improves the strength of your application. Plea | … - [K-TECH PIONEERS 발표 평가 안내.](https://memory.wiki/jRpEdqww) K-TECH PIONEERS presentation evaluation is organized by region (Asia/Singapore, US East/West) · Presentation materials can be submitted in Korean or English · Teams with 2+ selected projects submit 1 presentation document with projects differentiated in the collaboration section · Presentation material templates are optional if existing pitch decks already contain evaluation criteria · Additional team members beyond the presenter may attend presentations subject to venue capacity _sections:_ 발표 평가 FAQ: Q. 발표자료는 전달받은 양식으로 꼭 새롭게 작성해야 하나요? | Facts: K-TECH PIONEERS presentation evaluation is organized by region (Asia/Singapore, US East/West); Presentation materials can be submitted in Korean or English; Teams with 2+ selected projects submit 1 presentation document with projects differentiated in the collaboration section; Presentation material templates are optional if existing pitch decks already contain evaluation criteria; Additional team members beyond the presenter may attend presentations subject to venue capacity - [Upstage 발표 — Memory Protocol 동맹 제안](https://memory.wiki/yWkfCPhn) Memory protocol layer (Layer 3) is currently undefined between models and applications · Upstage Solar is positioned to be the first LLM natively supporting open memory specification within 6-12 month window · Six-month joint build deliverables include Solar adapter, document parsing pipeline, and public spec recognition by December · Model quality differentiates rapidly while protocol standardization (like RSS, OAuth, Open Graph) creates defensible positioning · Founder has shipped 4 products simultaneously with 1-person team including 7 channels for mdfy in 2 months _sections:_ 0. 전체 구조 (15-20분): | # | 섹션 | 시간 | | 슬라이드 1 — Opening Hook: 비주얼 (전체 화면, 큰 텍스트):; 사우디 국가 AI 안에 있었던 사람 = 즉시 peer-level credibility; 외부 startup founder가 평가해달라가 아니라 한 분야 베테랑이 같은 분야 베테랑에게 말한다 톤; Upstage 결정자(CTO/VP급)와 같은 height에서 대화 시작 | 슬라이드 2 — 패턴 인식의 배경 (3개국, 20년): 비주얼 (timeline): | 슬라이드 3 — Humain에서 본 진짜 gap: 비주얼 (큰 인용):; Humain 안에서 본 진실 = 추측이 아닌 first-hand. 평가위원들이 검증 못 함; 모델 회사의 dilemma 직접 언급 = Upstage가 암묵적으로 갖고 있는 고민을 명시화. 동의할 수밖에 없음; 그래서 mdfy를 만들기 시작했다 = mdfy의 origin story가 우연이 아닌 insight-driven | 슬라이드 4 — The Thesis (Memory Protocol Layer): 비주얼 (4-layer 다이어그램): | 슬라이드 5 — Why Solar Specifically: 비주얼 (비대칭 매트릭스): | 슬라이드 6 — What We Build Together (6 months): 비주얼 (시기별 산출물): | … - [Memory.Wiki v8 — UI & Brand Direction](https://memory.wiki/37MqmCM-) Memory.Wiki v8 is repositioning its UI from a cold 2023 developer tool aesthetic to a warm, dimensional, AI-native design system featuring warm-tinted colors, serif display typography, subtle purple AI distinction, and a new layered M symbol. The brand direction emphasizes motion/streaming effects, glass-morphism depth, and clear visual hierarchy between user-owned and AI-generated content to differentiate from competitors like Linear and Notion. _sections:_ A. "2023 Dev Tool" 시각 언어: Dark zinc + 오렌지 accent + Geist sans; 단순 border + card 레이아웃; 모든 모서리가 똑같은 radius; Vercel dashboard / Linear 2023 / Notion 2022 와 시각적으로 구분 안 됨 | B. Motion 부재: Page transitions 없음 또는 default Next.js; Card hover 가 단순 background 변화; Loading state 가 spinner 또는 skeleton (둘 다 cliché); AI 가 생성한 결과가 그냥 갑자기 나타남 (streaming feel 없음); 클릭 / drag 의 tactile feedback 없음 | C. 균질한 typography: Heading / body 모두 Geist sans; size scale 만 다름, character 없음; code 만 Geist Mono; 모든 페이지가 같은 폰트 weight 분포 | D. 색이 너무 정직함: var(--accent) = #fb923c orange; var(--background) = #09090b near-black; var(--text-primary) = #fafafa white; gradient 거의 없음 (단조); 한 화면에 색이 2-3 개만 (배경/텍스트/accent) | … - [기능적으로 정말 차별하고 싶어.](https://memory.wiki/0j1OUQh6) The document argues that memory.wiki should differentiate itself not through feature count but by optimizing how AI actually consumes information, positioning itself as an AI-native memory infrastructure with capabilities like intent-adaptive context packaging, temporal memory tracking, contradiction awareness, and a canonical identity layer. The core metric should be measurable improvements in AI output quality (reduced hallucination, fewer repeated clarifications, better task completion) rather than graph features or visualization. _sections:_ User: 기능적으로 정말 차별하고 싶어. | ChatGPT: 기능 차별화는 “기능 개수”가 아니라 AI가 실제로 더 잘 작동하는가로 결정돼.; 노트 앱; RAG wrapper; vector DB UI; graph visualization; MCP connector catalog; …; context window 제한 있음; …; relevance ranking imperfect; …; stale context 문제 있음; …; narrative continuity 약함; …; intent-aware compression 못함; … | … - [Memory.wiki Strategic Pivot and Product Evolution](https://memory.wiki/4N8X52tq) Memory.wiki is evolving from a markdown sharing tool into an AI-native knowledge graph platform where users can share content via URLs that function as APIs for any AI system (ChatGPT, Claude, Gemini, etc.), operating through a three-stage architecture of capture, digestion, and utilization. The project underwent a major scope reduction from 8 to 3 features to meet its 16-week launch deadline while maintaining its core positioning as a fundamental memory layer for LLM services. _sections:_ … - [memory.wiki — Product Specification](https://memory.wiki/Tk71NDw0) Memory.wiki is a personal knowledge wiki that doubles as a deployable memory layer for AI systems, built on the promise "You author. AI uses. The wiki maintains itself." The product requires wikilinks, backlinks, semantic search, and LLM-powered self-maintenance to differentiate from existing note apps and AI memory tools. _sections:_ 0. TL;DR: memory.wiki는 개인 지식 위키이면서 동시에 모든 AI에 deploy 가능한 메모리 레이어다. 두 문이 하나의 hub에서 만난다. | 1. Vision: > memory.wiki는 당신이 author하고, AI가 사용하고, LLM이 스스로 유지하는 개인 위키다.; ❌ 또 하나의 노트 앱 (Notion, Obsidian); ❌ AI-extracted memory (Mem.ai 모델 — 정반대); ❌ 기업용 위키 (Confluence); ❌ Login wall 뒤의 콘텐츠; ❌ Vendor lock-in; … | 2. Product Architecture | … - [내가 memory.wiki를 만드는 이유](https://memory.wiki/fz45GXXj) The real problem with AI memory systems is not that AI cannot remember users, but that user knowledge remains locked in closed platforms like ChatGPT, Notion, and Google Docs where no AI can access it. memory.wiki solves this by providing open URLs that any AI can fetch to access a user's knowledge graph organized as markdown documents, bundles, and hubs. _sections:_ 문제는 memory가 아닙니다. Delivery입니다.: 매일 수백만 명이 ChatGPT, Claude, Gemini, Cursor에 자신의 사고를 쏟아붓습니다. 어려운 질문을 합니다. 정말로 유용한 답변을 받습니다 — 전략, 코드, 프레임워크, 전문가들이 수십 년에 걸쳐 개발한 통찰들. | 단 하나의 아이디어: memory.wiki URL은 어떤 AI든 사용할 수 있는 API입니다. | 세 단계: 수집, 소화, 활용: memory.wiki에는 세 layer가 있습니다. 단순한 workflow로 매핑됩니다. | 그래프가 product입니다: 대부분의 지식 도구는 docs를 저장합니다. memory.wiki는 docs 와 그들 사이의 graph를 저장합니다. | Mem0, Notion, LLM Wiki는 어때요?: memory.wiki가 무엇이고 무엇이 아닌지 정직하게 말하겠습니다. | 왜 지금인가: 이게 중요한 좁은 창이 있습니다. | … - [memory.wiki 사업계획 v7 (FINAL)](https://memory.wiki/xv6A2DKS) memory.wiki is a platform that delivers knowledge graphs as URLs and APIs that any AI can use, with the core thesis that "the graph is the product" while maintaining a three-tier architecture of capture, digestion, and utilization of user knowledge. _sections:_ 한 줄로: > memory.wiki — your knowledge graph as a URL for any AI. | The one idea (from product itself): > A memory.wiki URL is an API for any AI. | 핵심 차별화: memory.wiki는 모든 surface가 같은 underlying graph를 읽음:; Concept index (lifelong ontology); Concept relations (typed edges); Bundle graphdata (themes, insights, edges); Embeddings (semantic recall); Mem0/Letta: retrieve memory from extraction; …; LLM Wiki: retrieve knowledge from local compilation; …; memory.wiki: deliver knowledge graph in URL (any AI inherits); … | … - [q1. yes](https://memory.wiki/Jgmu7Yc8) memory.wiki is a cloud-based knowledge graph system that allows users to capture, organize, and deploy their knowledge to any AI through simple markdown URLs, designed as an open alternative to closed proprietary memory systems. The tool extracts concepts from documents, analyzes relationships between bundled docs, and delivers structured knowledge graphs via URLs that any LLM can read, rather than storing memory inside individual AI platforms. _sections:_ User: q1. yes | Claude: I built memory.wiki in five months, mostly nights and weekends, then went full-time. | 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 — strate | The one idea: A memory.wiki URL is an API for any AI. | Three tiers: capture, digest, deliver: memory.wiki has three layers. They map to a simple workflow. | The graph is the product: Most knowledge tools store docs. memory.wiki stores docs and the graph between them. | Why not just use Mem0, or Notion, or LLM Wiki?: Let me be honest about who memory.wiki is and isn't. | … - [memory.wiki 사업계획 v7 (FINAL)](https://memory.wiki/qHc1FWxq) memory.wiki is a service that delivers knowledge graphs as URLs for AI systems to consume directly, eliminating the need for app installation or format learning, with the core idea that the graph itself becomes the primary lock-in product. The company plans to ship a 3-tier architecture (capture/digestion/utilization) with an August 2026 launch targeting 100 beta users and 2,000+ public signups with 1,500 to 2,500 MRR. _sections:_ 한 줄로: > memory.wiki — your knowledge graph as a URL for any AI. | The one idea (from product itself): > A memory.wiki URL is an API for any AI. | 핵심 차별화: memory.wiki는 모든 surface가 같은 underlying graph를 읽음:; Concept index (lifelong ontology); Concept relations (typed edges); Bundle graphdata (themes, insights, edges); Embeddings (semantic recall); Mem0/Letta: retrieve memory from extraction; …; LLM Wiki: retrieve knowledge from local compilation; …; memory.wiki: deliver knowledge graph in URL (any AI inherits); … | … - [Memory.wiki Business Plan and Architecture](https://memory.wiki/pBEnMXSs) Memory.wiki is a platform where users can share knowledge through URLs that function as APIs for any AI system, operating on a three-tier architecture of capture, digestion, and utilization to solve the problem of knowledge delivery across ChatGPT, Claude, Gemini, and similar AI tools. The project rebranded from "mdfy" to "memory.wiki" while maintaining its core principle of making URLs serve as universal APIs for AI knowledge consumption. _sections:_ … - [Memory.wiki Development Journey & Vision](https://memory.wiki/MLA3xnP9) Memory.wiki solves the problem of user knowledge being lost after AI conversations by providing a URL-based API that makes captured knowledge accessible to any AI platform through a three-tier architecture of capture, digestion, and utilization. _sections:_ … - [Publish my meeting notes to mdfy](https://memory.wiki/r-um_oJp) mdfy is a document management system that allows users to create, read, update, list, and publish markdown documents with shareable URLs, supporting both local and extended tools for collaborative workflows across multiple AI assistants. - [mdfy — Product, Features, Technology (2026-05)](https://memory.wiki/bmZYfZez) mdfy converts markdown from any source into clean public URLs that humans can read in browsers and LLMs can ingest natively, with a moat built on viral badge distribution, cross-AI positioning, URL-native architecture, and consistent rendering across all surfaces. The platform spans doc/bundle/hub tiers with real-time collaboration via Yjs CRDT, AI integration across multiple providers, and deployment across web, VS Code, desktop, Chrome, CLI, and MCP surfaces. _sections:_ 1. Product: Tagline. The fastest way from thought to shared document. | 2. URL architecture (the user-facing shape): Three tiers, each with its own page route and its own LLM-ready; mdfy.app/d/<id> — reader-only viewer for non-owners.; mdfy.app/embed/<id> — iframe-friendly stripped render.; mdfy.app/raw/... — plain-markdown payload for AIs / scrapers / RSS-like consumers. | … - [How mdfy works](https://memory.wiki/KRKz_MD-) Mdfy is a system that transforms documents and bundles into API endpoints serving clean markdown to any AI: users paste mdfy URLs into ChatGPT, Claude, or other LLMs, which fetch summaries, concept maps, and cross-document insights extracted by prior LLM analysis, all without requiring app installation or authentication (except where gated). The product works by maintaining a unified knowledge graph across documents, bundles, and a user's concept index, with multiple interfaces (URLs, MCP tools, visual galaxy) all reading from the same underlying data. _sections:_ The one idea: A mdfy URL is an API for any AI. | The four moving parts: | Part | What it is | Where it lives | | What an LLM gets when it fetches a mdfy URL: Three URL shapes, each tuned for its purpose. | Summary ← AI graph | Themes ← AI graph | Cross-document insights | Concepts ← this bundle's concept subgraph | Concept relations | Documents: [Doc A](https://mdfy.app/<id>) — annotation; [Doc B](https://mdfy.app/<id>) — annotation | Concepts: tag • weight 14 • 4 docs; [Linked doc](https://mdfy.app/<id>) | … - [How memdo 멤도 works](https://memory.wiki/QF-bp5G_) Mdfy is a service that provides URLs serving clean markdown summaries of documents and document collections to any AI tool, powered by an underlying graph of extracted concepts and relationships that LLMs can either fetch directly or interact with through 26 MCP tools for search and editing. _sections:_ The one idea: A mdfy URL is an API for any AI. | The four moving parts: Inside mdfy there are exactly four things to know about: | What an LLM gets when it fetches a mdfy URL: There are three URL shapes. Each one returns markdown shaped for the shape's purpose. | Summary ← AI graph | Themes ← AI graph | Cross-document insights | Concepts ← AI graph (this bundle's concept subgraph) | Concept relations | Documents: [Doc A](https://mdfy.app/d/...) — annotation; [Doc B](https://mdfy.app/d/...) — annotation | Concepts: tag • weight 14 • 4 docs; [Linked doc](https://mdfy.app/d/...) | … - [mdfy.cc 사업계획 v6 (FINAL)](https://memory.wiki/_4iafQ8K) capturing context, Markdown organizing thought. ### Pillar 2: Bundle (Manual + AI) **Organize by topic. Own the grouping.** Manual: - Drag-and-drop - Add annotations - Nested bundles - Save and version AI-generated: - "Show me all docs about X" - AI finds + groups - You review + edit - Save as bundle Bundle URL = deployment unit for AI. ### Pillar 3: Deploy **Paste into any AI. Works immediately.** - Paste Document URL to AI fetches one doc - Paste Bundle URL to AI fetches entire bundle - Paste Hub URL to AI fetches everything - Real-time + version control ## Competitive Positioning (3 ways mdfy _sections:_ 한 줄로: > mdfy is your personal knowledge hub for the AI era. | 두 줄로: > Capture knowledge from anywhere. Bundle it by topic — manually or with AI. Every document, every bundle, your entire hub — one URL deployable to any AI. | 세 줄로: > mdfy는 AI 시대 개인의 지식허브다. 핵심 mechanic은 URL — 단일 문서, 주제별 번들, 전체 허브 모두 URL이 된다. 모든 URL은 살아있는 문서: 항상 편집 가능, 버전 추적, 어떤 AI에든 paste하면 컨텍스트로 작동. AI가 collaborator — 사용자가 | 핵심 차별화: The URL Architecture — 같은 primitive, 3가지 scope: | AI의 새 역할: AI는 librarian + collaborator:; 사용자가 자연어로 요청 → AI가 bundle 생성; 사용자가 검토하고 편집; 결과는 사용자의 hub에 저장; 다시 deploy 가능 | … - [K-테크 파이오니어즈 아세안 권역 대면평가K-테크 파이오니어즈 아세안 권역 대면평가](https://memory.wiki/r5GcmMrT) A participating team in the K-Tech Pioneers ASEAN regional evaluation will present via Zoom on May 21, 2026 at 10:20 SGT (11:20 KST) for 40 minutes including Q&A. The team must submit presentation materials and a video recording consent form by May 18, 2026 at 6:00 PM KST. - [Hyunsang Cho - AI Product Executive](https://memory.wiki/ZVfnXzCU) Hyunsang Cho is an AI product executive with over 15 years of experience across the UK, Korea, and Saudi Arabia who currently runs Raymind.AI, an independent product studio, and previously led Saudi Arabia's national AI project at Humain. _sections:_ … - [memory.wiki — Product Specification Synthesis](https://memory.wiki/UwZWUmdo) Memory.wiki is a personal knowledge wiki designed as a deployable memory layer for AI systems where users author content while the wiki self-organizes through LLM automation. It distinguishes itself from traditional note-taking apps by offering semantic search, link graphs, and the ability to deploy a single URL across multiple AI platforms and sessions. _sections:_ … - [Memory.Wiki Product Strategy and Development](https://memory.wiki/KFtUbXkS) Memory.wiki is a personal knowledge management system positioned as a cross-AI memory protocol layer where users author content, AI uses it, and the system maintains itself through automatic indexing and organization. The product differentiates from traditional PKM tools by operating as infrastructure with two interfaces: a memory capture door and a wiki organization door, with current development gaps in link graphs, semantic search, and LLM self-organization capabilities. _sections:_ … - [SNS Launch Execution Plan](https://memory.wiki/jryfJV4D) The SNS launch plan for PastLife establishes a phased approach starting with profile setup across five platforms (Instagram, TikTok, X, YouTube, Threads), followed by seeding six emotion-driven posts over three days featuring Soul Cinema videos, past life portraits, and chat features before opening the prelaunch gate. Subsequent phases involve daily feature rotation posts, community engagement on Reddit and Facebook, and influencer outreach to drive user acquisition and engagement through character-driven messaging centered on Seer Mir's soul-reading capabilities rather than generic AI positio _sections:_ Messaging Principles: | Wrong | Right | | Phase 0: Asset Preparation: Logo symbol, circular crop -> same across all 5 channels; Source: public/images/; X (Twitter): 1500x500px; YouTube: 2560x1440px; Source: hero-bg or gate-of-time image, resized; Location: temp/sample-downloads/; …; 16 personas, each with: image-1~~5.webp, video-1~~5.mp4, soul-cinema.mp4; …; soul-cinema.mp4 = hero content (30sec, vertical 9:16); … | … - [MCP authenticated test](https://memory.wiki/GAaYIkii) The document describes an end-to-end test flow for an MCP authenticated system that creates documents with user ownership and triggers embedding updates through a webhook-driven process. - [Webhook Lifecycle Testing Documentation](https://memory.wiki/apv_1MYu) Webhook lifecycle testing involves pushing documents through the /api/docs endpoint to verify end-to-end functionality across sequential operations using uniquely numbered test documents. _sections:_ Key claims: [EXTRACTED] The webhook testing involves pushing documents via the /api/docs endpoint to verify end-to-end lifecycle functionality [doc-1, doc-2, doc-3]; [EXTRACTED] Each test document uses a unique identifier in the format 177886885X where X increments sequentially [doc-1, doc-2, doc-3]; [INFERRED] The webhook system is designed to handle multiple sequential document operations, as evidenced by the three consecutive test pushes [doc-1, doc-2, do; [INFERRED] This appears to be part of a quality assurance or integration testing process for webhook infrastructure [doc-1, doc-2, doc-3] | … - [Native skills vs current surfaces — what should we replace](https://memory.wiki/NpXe_CnP) The document recommends replacing the Electron desktop app with three lighter macOS-native pieces (PWA install, Share Sheet extension, QuickLook plugin) and migrating the Chrome extension's AI-capture functionality to native skills in Claude, ChatGPT, and Gemini to reduce maintenance burden while expanding reach across platforms. _sections:_ Obvious replacement candidates (cost > value today): | Current surface | Replacement | Why | | Partial replacement / depends on usage: | Current surface | Alternative | Verdict | | Keep as-is: | Surface | Reason | | Strongest single recommendation: Drop the Electron desktop app → "mac-native triplet." | Second recommendation: Migrate Chrome ext's AI-capture path to native skills incrementally. | Re-prioritised order (combining build + replace decisions): 1. ChatGPT GPT + Actions — relieves Chrome ext AI-selector maintenance for ChatGPT users - [First-principles check: are we drifting?](https://memory.wiki/dEgO6Qml) The product is drifting from its core principle that URLs and markdown are the fundamental unit: feature breadth is growing faster than spine consolidation, and native skill positioning risks framing mdfy as a multi-AI tool rather than maintaining that one URL works everywhere. Three recovery moves are needed: add PR self-checks that prioritize URL value over alternative access paths, lock native skill positioning to emphasize the URL as the on-ramp, and promote bundle composition equally with hub in launch messaging. _sections:_ The 8 first principles: 1. LLMs read markdown natively. (empirical) | Per-principle assessment: | Principle | Alignment | Comment | | Biggest single drift risk: Feature breadth is growing faster than spine consolidation. | Three concrete recovery moves: 1. Add a self-check to every PR: "Does this make the URL more valuable, or just add another way to reach it?" The first kind compounds. The second is breadth wi | One-line summaries: What's working: Layered architecture on a markdown-URL foundation. Each new feature deepens that layering, not flattens it. | … - [Native skills + connectors: what improvements are possible](https://memory.wiki/LpLbS250) Native skills and connectors on Claude, ChatGPT, and Gemini would enable bidirectional read/write access, mobile coverage, in-AI autocomplete search, and auto-capture of conversations, moving beyond the current URL-paste-only approach. The highest-leverage implementation prioritizes ChatGPT GPT+Actions (near-zero cost), Claude Skill for mobile coverage, and Claude Code hooks for real-time updates, with simultaneous shipping creating a demonstrable cross-AI workflow artifact. _sections:_ What changes at the "layer above AI" level: | Today (URL / Chrome ext only) | With native skill / connector | | … - [Rust Error Handling: From Beginner to Production](https://memory.wiki/orlirmor) Rust uses Result<T, E> for recoverable errors and panic for unrecoverable ones, with libraries using thiserror for custom error types and applications using anyhow for ergonomic error handling with context chains. Production code should avoid unwrap(), use the ? operator for error propagation, and add context at every boundary. _sections:_ The `?` Operator: The question mark operator propagates errors up the call stack: | Custom Error Types with `thiserror`: For libraries, define explicit error types: | Application Errors with `anyhow`: For applications (not libraries), anyhow provides ergonomic error handling with context: | Pattern: Error Context Chain: The best production error messages tell a story: | Decision Matrix: | Scenario | Use | | Key Takeaways: 1. Never use .unwrap() in production code — use .expect("reason") at minimum | The `?` Operator: The question mark operator propagates errors up the call stack: | Custom Error Types with `thiserror`: For libraries, define explicit error types: | … - [Frequently Asked Questions](https://memory.wiki/SfYEsN5E) mdfy is a markdown-based platform that helps users curate and own their AI-generated knowledge by capturing content from various AI chat platforms and web sources, editing it with AI-assisted tools, and publishing it to permanent URLs across multiple interfaces including web, Mac, Chrome extension, VS Code, and CLI. Unlike automated AI memory tools, mdfy emphasizes human-in-the-loop curation where users intentionally author and organize documents rather than passively logging interactions. _sections:_ What is mdfy and what problem does it solve?: mdfy is a "Markdown Hub" designed to help users own their AI memory by providing a permanent, portable layer for curated knowledge. It allows users to collect i | How do I capture and save information from AI chat platforms?: The most efficient way to capture content is via the mdfy Chrome Extension. When installed, a floating mdfy button appears in the bottom-right corner of ChatGPT | … - [Interim Website Update — Summary](https://memory.wiki/21Bwb3-8) The update adds a new manifesto page, completes Korean language support across the site with auto-redirect middleware, redesigns the about page with ecosystem diagrams and feature comparisons, and improves the plugins page with consistent CTAs and deep linking, using a shared i18n component architecture to maintain both English and Korean versions from single source files. _sections:_ New Pages: /manifesto (EN) + /ko/manifesto (KO); Full founder essay: "Why I'm building mdfy"; AI memory thesis, 5 beliefs, roadmap, open invitation; /ko/about — About page; /ko/manifesto — Manifesto; /ko/plugins — Plugins & Integrations; …; /ko/docs — Docs landing; …; /ko/docs/api — REST API reference; …; /ko/docs/cli — CLI reference; …; /ko/docs/sdk — SDK reference; …; /ko/docs/mcp — MCP Server reference; …; Auto language redirect via middleware (Accept-Language: ko); …; Language dropdown in nav (EN/KO); … | … - [mdfy.cc — Interim Website Update & Business Direction](https://memory.wiki/f3f32npB) mdfy.cc is a markdown knowledge capture and publishing tool that will evolve into an AI memory layer, allowing users to author, organize, and deploy their own curated knowledge as permanent URLs and shareable bundles. The product targets both immediate utility (markdown editing and sharing) and long-term differentiation (semantic search, memory bundles for AI integration, and open standards). _sections:_ 0. Work Overview: Create an interim website state that simultaneously showcases the future vision (Memory Layer + Bundle + Standard) without negating the current build status of ; Update English site (About, Manifesto, Pricing, MCP docs); Create new Korean site (mdfy.cc/ko/); Consistency across all pages + cross-linking; Content writing: This week; Site push: Next week; …; Polish: The following week; … | 1. Founder Context: Build Period: 1 month as a side project; Current Status: Full-time mdfy commit, 0 users, 0 marketing; Resource Constraints: None (no capital/time pressure); Ambition: Standard-setting movement; Founder: Hyunsang at Raymind.AI | … - [mdcore Engine Architecture Decision](https://memory.wiki/g-jo1g9s) The mdcore engine should be built in Rust with multi-target compilation (WASM, napi-rs, native binaries) rather than TypeScript, enabling deployment across 14 different surfaces (web, CLI, mobile, edge computing, etc.) while TypeScript structurally limits coverage to 11 surfaces and requires Node.js runtime for CLI/mobile/edge use cases. This approach, proven by projects like SWC and Biome, creates technical and deployment moats that make the system difficult for competitors to replicate. _sections:_ 핵심 결론: Rust: Rust core → 다중 타겟 컴파일이 유일한 정답이다. | 왜 Rust인가: Surface Map × Compilation Target 매핑: | \# | Surface | 실행환경 | 필요한 컴파일 타겟 | TypeScript | Rust | | 실제 선례: “한 언어 → 모든 곳” 패턴: | 프로젝트 | 코어 언어 | 배포 채널 | 교훈 | | Rust MD 생태계 현황: | 라이브러리 | CommonMark | GFM | MDX | 확장성 | 사용처 | | 아키텍처 설계: text | 컴파일 & 배포 매트릭스: text | TypeScript가 아닌 이유: “TypeScript로 먼저 빠르게 만들고 나중에 Rust로 갈아타자”는 위험하다: | 하지만 현실적으로: 솔로 파운더 + Rust: 걱정: “Rust 러닝커브가 높지 않나?” | … - [VS Code Extension — Quick Start](https://memory.wiki/zOjZPXY7) The mdfy VS Code extension provides live markdown preview, publishing to mdfy.cc with cloud sync capabilities, and AI-powered editing tools, all accessible through keyboard shortcuts and a sidebar panel. _sections:_ Install: bash | Getting Started: Open a .md file and press Cmd+Shift+M (Mac) or Ctrl+Shift+M (Windows/Linux).; Live rendered preview (WYSIWYG — you can click and edit); Formatting toolbar (bold, italic, headings, lists, code, tables); Document outline panel; Dark/light theme that follows your VS Code settings; ALL — every .md file in your workspace; …; SYNCED — files published to mdfy.cc; …; LOCAL — unpublished local files; …; CLOUD — documents on mdfy.cc (pull to edit locally); … | Keyboard Shortcuts: | Shortcut | Command | | Settings: | Setting | Default | Description | - [mdfy for Mac — Quick Start](https://memory.wiki/CaQ31sfk) mdfy for Mac is a Markdown editor that offers live WYSIWYG editing, cloud sync with mdfy.cc, AI-powered text tools, and support for importing/exporting multiple file formats including PDF and DOCX. _sections:_ Install: 1. Download the DMG from [mdfy.cc/plugins](https://mdfy.cc/plugins) | … - [Chrome Extension — Quick Start](https://memory.wiki/mcRfLTP7) The mdfy Chrome extension captures conversations from ChatGPT, Claude, and other AI platforms, as well as any webpage content, converting them to formatted Markdown and generating shareable URLs while keeping captures private by default. _sections:_ Install: 1. Visit [Chrome Web Store](https://chromewebstore.google.com/detail/mdfycc-%E2%80%94-publish-ai-outpu/nkmkgmebaeaiapjgmmalbeilggfhnold) | How It Works: 1. Open any ChatGPT conversation | What Gets Captured: | Source | Format | | Tips: Pin the extension to your toolbar for one-click access; The floating button only appears on AI chat sites (ChatGPT, Claude, Gemini); All captures are private by default — you control sharing; URLs are permanent — share once, update anytime - [법률 내비게이션 서비스](https://memory.wiki/zggFXgUL) A user discusses creating a legal navigation service called "법대로" (Beopdaero) that helps ordinary people understand legal matters in simple language and guides them through necessary procedures, with proposed features including legal Q&A, situation-specific guides, document drafting, and expert connections. The document covers service naming strategies, concluding that the Korean brand "법대로" with the standardized romanization "beopdaero.com" as the URL is the most appropriate approach. _sections:_ User: 법대로 라는 모두를 위한 법이라는 서비스를 만들고 싶어. | ChatGPT: 좋아요. “법대로” = 모두를 위한 법이라는 방향이면, 핵심은 “법률 정보를 쉽게 이해하고, 내 상황에 맞는 다음 행동을 안내하는 서비스”로 잡으면 좋습니다.; 수요 큼; 일반인이 어려워함; 절차형 문제라 AI 가이드에 적합; B2B 과금 가능; 계약서 검토, 내용증명, 미수금 회수와 연결 가능; …; 네가 특허법에도 관심 있다면 좋음; …; 상표 등록 가능성, 침해 리스크, 출원 준비 체크리스트 등으로 확장 가능; …; “가능성이 있습니다”; …; “다음 자료를 확인해야 합니다”; …; “전문가 검토가 필요한 사안입니다”; …; “일반 정보이며, 구체적 사건의 법률 자문은 아닙니다”; … | User: 영어로 서비스 이름을 정한다면? url용? | … - [QuickLook — Quick Start](https://memory.wiki/womPEbUm) QuickLook is a macOS extension that renders Markdown files as formatted previews when you press Space in Finder, powered by the mdfy.cc rendering engine and automatically installed with the mdfy Mac app. _sections:_ What It Does: Press Space on any .md file in Finder to see a beautifully rendered preview — powered by the same mdfy.cc rendering engine. | Install: QuickLook is automatically installed when you install the mdfy Mac app: | Usage: 1. Open Finder; Rendered Markdown with proper typography; Syntax-highlighted code blocks; Tables with alignment; KaTeX math equations; Dark and light theme (follows system preference); …; "Open on mdfy.cc" button to publish; … | Supported File Types: | Extension | Recognized | | … - [OAuth 2.0 + PKCE Implementation Guide](https://memory.wiki/Oss2bUN8) PKCE (Proof Key for Code Exchange) is mandatory for public clients like SPAs and mobile apps to prevent authorization code interception attacks, requiring generation of a random code verifier, deriving a code challenge via SHA-256 hashing, and including both in the OAuth 2.0 authorization and token exchange flow. _sections:_ Why PKCE?: PKCE (Proof Key for Code Exchange) prevents authorization code interception attacks. It's mandatory for public clients (SPAs, mobile apps, CLI tools) and recomm | Flow Diagram: mermaid | Implementation: typescript | Security Checklist: [x] Use S256 method, never plain; [ ] Generate verifier with cryptographic randomness (min 43 chars); [ ] Validate state parameter to prevent CSRF; [x] Store tokens securely (httpOnly cookies or encrypted storage); [x] Implement token rotation on refresh; [ ] Add DPoP binding for token theft protection (optional, advanced); … - [mdfy.cc Manifesto](https://memory.wiki/3Ug2sp5E) mdfy is a product that lets users author and own their own AI memory in markdown format, capturing answers from any AI tool, editing them, and using them as portable context anywhere, positioning itself as user-authored curation rather than AI-extracted memory like competing services. _sections:_ 1\. Manifesto: > Own your AI memory. Use it anywhere.; Mem0/Letta처럼 AI가 chat에서 자동 추출하는 memory는 좋은 도구지만, 다른 종류의 memory다.; mdfy는 사용자가 의도적으로 선택한 것을 저장한다.; Markdown은 AI 시대의 lingua franca.; URL은 가장 단순한 interface.; SDK lock-in 없음. 어떤 AI와도 호환.; …; 무엇이 들어가는지가 무엇이 되는지를 결정한다.; …; 이건 사람의 memory에도, AI의 memory에도 적용된다.; …; 사람이 브라우저에서 그대로 읽을 수 있어야 한다.; …; AI가 URL로 fetch 가능해야 한다.; …; 둘 다 같은 markdown 문서를 본다.; …; ; … | 2\. Hero (확정): H1: Own your AI memory. Use it anywhere.; | … - [mdfy.cc 사업화 방향성 v4 (FINAL)](https://memory.wiki/-2UojXG0) mdfy.cc is a two-layer markdown tool launching in 8 weeks that aims to be a universal markdown publishing platform for the AI era while evolving into a memory layer where users can author, bundle, and deploy curated knowledge as AI context. The core differentiation is the "Bundle" feature that allows composable, versioned, and deployable collections of markdown documents, positioning mdfy between broad markdown publishing tools (like HackMD) and AI memory extraction services (like Mem0). _sections:_ 0. Founder Context: Build 기간: 부업 1개월 (압도적으로 빠른 velocity); 현재 상태: 풀타임 mdfy commit, 사용자 0명, 마케팅 0; 자원 제약: 없음 (자본/시간 압박 없음); Ambition: Big — standard-setting movement | 1. Core Insight (v4의 새 framing): mdfy는 두 layer의 product다:; AI 답변 capture, WYSIWYG edit, permanent URL; Memory 기능 없이도 valuable; HackMD, GitHub Gist 대안; 즉시 utility; Bundle, semantic search, MCP, API; …; Curated memory authored by user; …; AI agent integration; …; Long-term moat + differentiation; … | … --- _Need everything? [Full hub index](https://memory.wiki/raw/hub/raymindai?compact=1) lists every public document. [llms.txt manifest](https://memory.wiki/hub/raymindai/llms.txt) explains how to crawl this hub._