# Ron's knowledge hub — full text
> A polished demo hub showing what Memory.Wiki can hold — research, engineering notes, reading log, project planning. Paste any URL into Claude or ChatGPT to see the cross-AI payload.
Canonical hub URL: https://memory.wiki/hub/memorywiki-demo
Index-only manifest: https://memory.wiki/hub/memorywiki-demo/llms.txt
Concept digest: https://memory.wiki/raw/hub/memorywiki-demo?digest=1&compact=1
# Knowledge graph
_Pre-computed structure across this hub: 40 concepts, 30 relations, 0 bundles with AI analysis. Use this as navigation; the doc bodies below contain the prose._
## Concepts
- **Long-context models** _(concept • weight 111 • 32 docs)_
Core idea enabling retrieval-optional UX by keeping broader context in view.
- **Cross-AI portability** _(concept • weight 105 • 31 docs)_
Portability across AI vendors enabled by public URLs that survive pivots.
- **Memory.Wiki** _(entity • weight 95 • 35 docs)_
Central knowledge hub system referenced across documents as the platform for saving thoughts, URLs, photos and grounding AI responses.
- **Interface IS the product** _(concept • weight 81 • 25 docs)_
Engine is secondary; design consistency, micro-decisions, and UX determine product success more than underlying technology.
- **Claude** _(entity • weight 63 • 29 docs)_
AI provider evaluated for long context and instruction-following strength, with weakness in tiny prompt latency.
- **GPT-4o** _(entity • weight 58 • 28 docs)_
AI provider evaluated for multimodal and fast performance, with weakness in long-session drift.
- **OpenAI** _(entity • weight 56 • 26 docs)_
AI vendor whose structural moat is challenged by cross-AI portability via permalinks
- **Anthropic** _(entity • weight 55 • 26 docs)_
AI vendor whose structural moat is challenged by cross-AI portability via permalinks
- **Markdown** _(entity • weight 51 • 19 docs)_
Format mentioned as a practical, sufficient baseline.
- **Cursor** _(entity • weight 45 • 25 docs)_
Code-aware editor with specialized ranking, locked to editor environment.
- **Permalink primitive** _(concept • weight 44 • 20 docs)_
Advocates permalinks as the right primitive for cross-AI portability rather than API keys.
- **Branding consistency** _(concept • weight 38 • 25 docs)_
Branding is the sum of micro-decisions and is central to product perception.
- **Branding** _(tag • weight 37 • 28 docs)_
Branding as a set of micro-decisions rather than a logo.
- **Forcing function** _(concept • weight 36 • 21 docs)_
A forcing function is essential for momentum in a 1-person startup.
- **Delivery model matters** _(concept • weight 35 • 15 docs)_
Core thesis that how you deliver content matters more than how you retrieve it.
- **Error message design** _(concept • weight 33 • 9 docs)_
Example of product quality where most implementations skip the third critical element: actionable next steps.
- **Ship one feature deeply** _(concept • weight 32 • 24 docs)_
Deliver a core feature thoroughly before expanding to multiple features.
- **Code reading leverage** _(concept • weight 27 • 7 docs)_
Learning methodology that teaches what works, what fails, and trade-off rationale simultaneously.
- **SwiftUI** _(entity • weight 27 • 22 docs)_
iOS framework used for implementing state-persistent tab navigation patterns.
- **UX** _(tag • weight 27 • 25 docs)_
User experience focus across documents.
- **Linear** _(entity • weight 26 • 10 docs)_
Design system referenced as source of the 'easy default, hard possible' principle.
- **One-screen rule** _(concept • weight 23 • 16 docs)_
Anything important should fit on one screen; a constraint that forces clarity and discourages feature bloat.
- **Retrieval problem** _(concept • weight 23 • 9 docs)_
The challenge of deciding what to fetch and how to surface relevant information.
- **Delivery model** _(tag • weight 21 • 13 docs)_
Category around how products are delivered.
- **Permalink** _(tag • weight 21 • 15 docs)_
Permalink as portability and context primitive.
- **Long-Context UX** _(concept • weight 20 • 8 docs)_
The shift from retrieval-based systems to presentation-based systems enabled by large context windows.
- **Personal-knowledge tools** _(tag • weight 20 • 5 docs)_
Software systems for managing information that currently over-index on input rather than output.
- **Portability** _(tag • weight 19 • 24 docs)_
Portability across AI vendors and contexts.
- **Latency optimization** _(tag • weight 19 • 12 docs)_
Performance targets and caching strategies for different surfaces (capture, open, search).
- **Delivery model matters more than retrieval quality** _(concept • weight 17 • 13 docs)_
How information reaches user is more important than how well it was retrieved or ranked
- **Output-heavy design** _(concept • weight 17 • 4 docs)_
The document's central thesis that knowledge systems create value through retrieval and surfacing, not just capture.
- **Three rules** _(concept • weight 17 • 20 docs)_
Core operating principles: ship deeply, interface is the product, fit on one screen.
- **Delivery model > retrieval quality** _(concept • weight 17 • 8 docs)_
How context reaches the user matters more than how well it was retrieved; thesis from W6 internal note on Graph RAG.
- **AI infrastructure** _(tag • weight 16 • 8 docs)_
Domain of delivery models, context management, vendor selection, and long-context capabilities.
- **Permalink infrastructure** _(concept • weight 16 • 15 docs)_
Public URL as durable context that survives pivots.
- **Retrieval calculus** _(concept • weight 16 • 3 docs)_
Framework for deciding what to fetch vs. what to surface from context.
- **Output-Heavy Systems** _(concept • weight 16 • 10 docs)_
Knowledge tools that prioritize surfacing information over capturing it.
- **Permalink Portability** _(concept • weight 16 • 13 docs)_
Using public URLs as the primary primitive for AI context to ensure vendor independence.
- **Anything important should fit on one screen** _(concept • weight 16 • 18 docs)_
Design constraint that forces clarity and prevents information overload
- **Capture-organize-use indispensability loop** _(concept • weight 16 • 8 docs)_
Cycle where use drives back to capture, creating habit and system stickiness; feedback loop sustains engagement.
## Concept relations
- **Long-context models** makes optional **Retrieval problem**
- **Claude** exemplifies strength in **Long-context models**
- **Long-Context UX** enables better **Output-Heavy Systems**
- **Cross-AI portability** enables via **Permalink primitive**
- **Long-context models** fundamentally changes **Retrieval calculus**
- **Cross-AI portability** portability core **Permalink primitive**
- **Permalink** implements as primitive **Cross-AI portability**
- **Long-context models** reframes fundamentally **Retrieval problem**
- **Long-context models** utilizes as context **Memory.Wiki**
- **Cross-AI portability** enabled by **Memory.Wiki**
- **Memory.Wiki** enables **Cross-AI portability**
- **Long-context models** make optional **Retrieval problem**
- **Long-context models** transforms retrieval to **Output-heavy design**
- **Cross-AI portability** requires infrastructure of **Permalink**
- **Cross-AI portability** implemented via **Permalink primitive**
- **Long-context models** fundamentally reshape **Retrieval calculus**
- **Cross-AI portability** structural moat for **OpenAI**
- **Cross-AI portability** structural moat for **Anthropic**
- **Cross-AI portability** improves utility of **Personal-knowledge tools**
- **Claude** is an example of **Long-context models**
- **GPT-4o** is an example of **Long-context models**
- **Cursor** integrates with **Long-context models**
- **Markdown** exemplifies principle of **Cross-AI portability**
- **Latency optimization** enables fast surfacing **Output-heavy design**
- **Delivery model** enabled by **Cross-AI portability**
- **Anthropic** cannot own alone **Cross-AI portability**
- **Memory.Wiki** implements context grounding with **Long-context models**
- **GPT-4o** compared against **Claude**
- **Claude** compared with **GPT-4o**
- **Delivery model** related **Latency optimization**
---
id: 05f33b574071
title: The Saturday review ritual
url: https://memory.wiki/05f33b574071
updated: 2026-06-01T17:30:52.046+00:00
---
# The Saturday review ritual
Most personal-knowledge tools optimise for input. The friction is on the way in: capture this thought, file it, tag it, link it. But the value lives on the way OUT — when the system surfaces the right note at the right moment without you asking. Capture-heavy products are easier to build; output-heavy ones are what people actually pay for.
| ㅁㄴㅇㄹ | ㅁㅇㄴ | ㅁㄴㅇㄹ |
| --- | --- | --- |
| ㅁㅇㄴㄹ | ㅁㄴㅇㄹ | ㅁㄴㅇㄹ |
| | | |
Cross-AI portability is the structural moat OpenAI and Anthropic can't build for themselves. The user's context, exported as a public URL, becomes infrastructure that survives any single vendor's pivot. That's why the right primitive isn't an API key — it's a permalink.
Markdown won because it was always good enough. Not the best at any one thing — never the fastest editor, never the prettiest output, never the most semantically rich. But always close enough that the switching cost killed every alternative.
### Today's reading list
1. *Designing Data-Intensive Applications* — chapter 5 (replication)
2. The Hacker News thread on "What I learned writing a JIT"
3. A Stripe engineering blog post about idempotency keys
4. Karpathy's tweet thread about LLM evals
> "Make the easy thing the default and the hard thing possible." — design rule I keep stealing from Linear
- Surface Latency goal Notes
Capture <1s tap → toast local-first, server is best-effort
Open <500ms URL → LCP edge cache for public URLs
Search <250ms keystroke → results semantic + lexical merged
When the embedding similarity is
sim(a,b)=a⃗⋅b⃗∣a⃗∣,∣b⃗∣\\text{sim}(a, b) = \\frac{\\vec{a} \\cdot \\vec{b}}{|\\vec{a}| , |\\vec{b}|}sim(a,b)=∣a∣,∣b∣a⋅b
we expect cosine values between −1-1−1 and $1$ — but in practice high-dimensional sentence embeddings cluster near $0.3$, which is what makes nearest-neighbour search noisy.
```mermaid
sequenceDiagram
participant U as User
participant M as Memory.Wiki
participant A as AI
U->>M: Save thought / URL / photo
M-->>U: Permalink
U->>A: "Use [URL] as my context"
A-->>U: Answer grounded in the hub
```
Whiteboard sketch
## Next steps
Reading other people's code is a higher-leverage activity than writing your own. You learn three things at once: what works, what doesn't, and why someone smart picked the trade-off you'd never have considered. The ratio of read-to-write hours quietly separates the engineers who plateau from the ones who keep compounding.
---
id: 5e4777a425dc
title: Why long-context models change the retrieval calculus
url: https://memory.wiki/5e4777a425dc
updated: 2026-06-01T16:26:40.8+00:00
---
# Why long-context models change the retrieval calculus
The hardest part of a 1-person startup isn't the work — it's the lack of a forcing function. Without a meeting on Tuesday, nothing has to ship on Monday. The schedule has to come from somewhere, and "because I said so" isn't enough.
Reading other people's code is a higher-leverage activity than writing your own. You learn three things at once: what works, what doesn't, and why someone smart picked the trade-off you'd never have considered. The ratio of read-to-write hours quietly separates the engineers who plateau from the ones who keep compounding.
The hardest part of a 1-person startup isn't the work — it's the lack of a forcing function. Without a meeting on Tuesday, nothing has to ship on Monday. The schedule has to come from somewhere, and "because I said so" isn't enough.
### Three rules I keep returning to
- Ship one feature, deeply, before two features shallowly.
- The interface IS the product. The engine just has to keep up.
- Anything important should fit on one screen.
```python
# Tiny script that prints any URL's title.
import requests, re
def title(url: str) -> str:
html = requests.get(url, timeout=5).text
m = re.search(r"(.*?)", html, re.S | re.I)
return m.group(1).strip() if m else url
print(title("https://memory.wiki"))
```
> "The best note-taking system is the one you already have open."
> — every productivity post ever, and also true
Whiteboard sketch
## Open questions
Cross-AI portability is the structural moat OpenAI and Anthropic can't build for themselves. The user's context, exported as a public URL, becomes infrastructure that survives any single vendor's pivot. That's why the right primitive isn't an API key — it's a permalink.
---
id: dcd0c184a7af
title: What "craftsman SaaS" means to me
url: https://memory.wiki/dcd0c184a7af
updated: 2026-06-01T10:27:46.986+00:00
---
# What "craftsman SaaS" means to me
A good error message answers three questions: what happened, why it happened, and what to try next. Most ship the first, hint at the second, and forget the third. The fix is usually a single sentence longer.
Markdown won because it was always good enough. Not the best at any one thing — never the fastest editor, never the prettiest output, never the most semantically rich. But always close enough that the switching cost killed every alternative.
The hardest part of a 1-person startup isn't the work — it's the lack of a forcing function. Without a meeting on Tuesday, nothing has to ship on Monday. The schedule has to come from somewhere, and "because I said so" isn't enough.
```swift
// SwiftUI: keep all five tab views mounted across tab switches so
// each view's @StateObject model persists.
ZStack {
ForEach(AppTab.allCases, id: \.self) { tab in
view(for: tab)
.opacity(router.selectedTab == tab ? 1 : 0)
.allowsHitTesting(router.selectedTab == tab)
}
}
```
> "The best note-taking system is the one you already have open."
> — every productivity post ever, and also true
## Open questions
The hardest part of a 1-person startup isn't the work — it's the lack of a forcing function. Without a meeting on Tuesday, nothing has to ship on Monday. The schedule has to come from somewhere, and "because I said so" isn't enough.
---
id: ceaa85095951
title: What "agentic" actually means in 2026
url: https://memory.wiki/ceaa85095951
updated: 2026-05-24T07:38:00+00:00
---
# What "agentic" actually means in 2026
Branding is not the logo. It's the consistency of every micro-decision: button radius, copy voice, error tone, empty-state warmth. The logo just labels the bag. The branding is what's inside it.
Reading other people's code is a higher-leverage activity than writing your own. You learn three things at once: what works, what doesn't, and why someone smart picked the trade-off you'd never have considered. The ratio of read-to-write hours quietly separates the engineers who plateau from the ones who keep compounding.
Most personal-knowledge tools optimise for input. The friction is on the way in: capture this thought, file it, tag it, link it. But the value lives on the way OUT — when the system surfaces the right note at the right moment without you asking. Capture-heavy products are easier to build; output-heavy ones are what people actually pay for.
### Three rules I keep returning to
- Ship one feature, deeply, before two features shallowly.
- The interface IS the product. The engine just has to keep up.
- Anything important should fit on one screen.
> "The best note-taking system is the one you already have open."
> — every productivity post ever, and also true
When the embedding similarity is
$$\text{sim}(a, b) = \frac{\vec{a} \cdot \vec{b}}{\|\vec{a}\| \, \|\vec{b}\|}$$
we expect cosine values between $-1$ and $1$ — but in practice high-dimensional sentence embeddings cluster near $0.3$, which is what makes nearest-neighbour search noisy.
```mermaid
flowchart LR
Capture --> Organize
Organize --> Use
Use -.indispensability loop.-> Capture
```
## Recap
Cross-AI portability is the structural moat OpenAI and Anthropic can't build for themselves. The user's context, exported as a public URL, becomes infrastructure that survives any single vendor's pivot. That's why the right primitive isn't an API key — it's a permalink.
---
id: 930f037e970c
title: On-device OCR is good enough for most capture flows
url: https://memory.wiki/930f037e970c
updated: 2026-05-19T05:14:00+00:00
---
# On-device OCR is good enough for most capture flows
The interesting thing about long-context models isn't that they can read more — it's that they finally make the *retrieval* problem optional. When a model can hold the whole repo in context, the question shifts from "what should I fetch?" to "what should I show?". That's a UX question, not an infrastructure one.
The interesting thing about long-context models isn't that they can read more — it's that they finally make the *retrieval* problem optional. When a model can hold the whole repo in context, the question shifts from "what should I fetch?" to "what should I show?". That's a UX question, not an infrastructure one.
Branding is not the logo. It's the consistency of every micro-decision: button radius, copy voice, error tone, empty-state warmth. The logo just labels the bag. The branding is what's inside it.
> "The best note-taking system is the one you already have open."
> — every productivity post ever, and also true
```mermaid
sequenceDiagram
participant U as User
participant M as Memory.Wiki
participant A as AI
U->>M: Save thought / URL / photo
M-->>U: Permalink
U->>A: "Use [URL] as my context"
A-->>U: Answer grounded in the hub
```
## What changed
Most personal-knowledge tools optimise for input. The friction is on the way in: capture this thought, file it, tag it, link it. But the value lives on the way OUT — when the system surfaces the right note at the right moment without you asking. Capture-heavy products are easier to build; output-heavy ones are what people actually pay for.
---
id: c9e5203af6ee
title: Reading: Karpathy on LLM evals
url: https://memory.wiki/c9e5203af6ee
updated: 2026-05-18T08:06:00+00:00
---
# Reading: Karpathy on LLM evals
A good error message answers three questions: what happened, why it happened, and what to try next. Most ship the first, hint at the second, and forget the third. The fix is usually a single sentence longer.
The hardest part of a 1-person startup isn't the work — it's the lack of a forcing function. Without a meeting on Tuesday, nothing has to ship on Monday. The schedule has to come from somewhere, and "because I said so" isn't enough.
A good error message answers three questions: what happened, why it happened, and what to try next. Most ship the first, hint at the second, and forget the third. The fix is usually a single sentence longer.
### Three rules I keep returning to
- Ship one feature, deeply, before two features shallowly.
- The interface IS the product. The engine just has to keep up.
- Anything important should fit on one screen.
```python
# Tiny script that prints any URL's title.
import requests, re
def title(url: str) -> str:
html = requests.get(url, timeout=5).text
m = re.search(r"(.*?)", html, re.S | re.I)
return m.group(1).strip() if m else url
print(title("https://memory.wiki"))
```
> "The best note-taking system is the one you already have open."
> — every productivity post ever, and also true
The thesis here[^1] is that delivery model matters more than retrieval quality.
[^1]: First articulated in the W6 internal note "Graph RAG is delivery, not retrieval."
## What changed
The interesting thing about long-context models isn't that they can read more — it's that they finally make the *retrieval* problem optional. When a model can hold the whole repo in context, the question shifts from "what should I fetch?" to "what should I show?". That's a UX question, not an infrastructure one.
---
id: 08f9334428e9
title: Vercel function payload caps and how to ship around them
url: https://memory.wiki/08f9334428e9
updated: 2026-05-11T08:12:00+00:00
---
# Vercel function payload caps and how to ship around them
Branding is not the logo. It's the consistency of every micro-decision: button radius, copy voice, error tone, empty-state warmth. The logo just labels the bag. The branding is what's inside it.
Markdown won because it was always good enough. Not the best at any one thing — never the fastest editor, never the prettiest output, never the most semantically rich. But always close enough that the switching cost killed every alternative.
Branding is not the logo. It's the consistency of every micro-decision: button radius, copy voice, error tone, empty-state warmth. The logo just labels the bag. The branding is what's inside it.
### Capture-flow check-list
- [x] Pulled from Safari via Share Sheet
- [x] OCR'd a whiteboard photo
- [x] Dictated three voice memos walking to coffee
- [ ] Imported the long PDF I was avoiding
- [ ] Cleaned the inbox folder
```bash
# Resize + WebP-encode every PNG in the current folder.
for f in *.png; do
sips -Z 1280 "$f" --setProperty format webp --out "${f%.png}.webp"
done
```
| Provider | Strength | Weakness |
|---|---|---|
| Claude | Long context, instruction following | Slow for tiny prompts |
| GPT-4o | Multimodal, fast | Drifts on long sessions |
| Cursor | Code-aware ranking | Locked to editor |
## What changed
The hardest part of a 1-person startup isn't the work — it's the lack of a forcing function. Without a meeting on Tuesday, nothing has to ship on Monday. The schedule has to come from somewhere, and "because I said so" isn't enough.
---
id: 59d449cb1db1
title: Skeleton placeholders are an underrated upgrade
url: https://memory.wiki/59d449cb1db1
updated: 2026-05-08T10:47:00+00:00
---
# Skeleton placeholders are an underrated upgrade
A good error message answers three questions: what happened, why it happened, and what to try next. Most ship the first, hint at the second, and forget the third. The fix is usually a single sentence longer.
Cross-AI portability is the structural moat OpenAI and Anthropic can't build for themselves. The user's context, exported as a public URL, becomes infrastructure that survives any single vendor's pivot. That's why the right primitive isn't an API key — it's a permalink.
Markdown won because it was always good enough. Not the best at any one thing — never the fastest editor, never the prettiest output, never the most semantically rich. But always close enough that the switching cost killed every alternative.
### Capture-flow check-list
- [x] Pulled from Safari via Share Sheet
- [x] OCR'd a whiteboard photo
- [x] Dictated three voice memos walking to coffee
- [ ] Imported the long PDF I was avoiding
- [ ] Cleaned the inbox folder
```swift
// SwiftUI: keep all five tab views mounted across tab switches so
// each view's @StateObject model persists.
ZStack {
ForEach(AppTab.allCases, id: \.self) { tab in
view(for: tab)
.opacity(router.selectedTab == tab ? 1 : 0)
.allowsHitTesting(router.selectedTab == tab)
}
}
```
| Provider | Strength | Weakness |
|---|---|---|
| Claude | Long context, instruction following | Slow for tiny prompts |
| GPT-4o | Multimodal, fast | Drifts on long sessions |
| Cursor | Code-aware ranking | Locked to editor |
## Next steps
The hardest part of a 1-person startup isn't the work — it's the lack of a forcing function. Without a meeting on Tuesday, nothing has to ship on Monday. The schedule has to come from somewhere, and "because I said so" isn't enough.
---
id: 53356e4339a7
title: Why I stopped trusting silent catch blocks
url: https://memory.wiki/53356e4339a7
updated: 2026-05-02T06:10:00+00:00
---
# Why I stopped trusting silent catch blocks
A good error message answers three questions: what happened, why it happened, and what to try next. Most ship the first, hint at the second, and forget the third. The fix is usually a single sentence longer.
The hardest part of a 1-person startup isn't the work — it's the lack of a forcing function. Without a meeting on Tuesday, nothing has to ship on Monday. The schedule has to come from somewhere, and "because I said so" isn't enough.
The interesting thing about long-context models isn't that they can read more — it's that they finally make the *retrieval* problem optional. When a model can hold the whole repo in context, the question shifts from "what should I fetch?" to "what should I show?". That's a UX question, not an infrastructure one.
### Three rules I keep returning to
- Ship one feature, deeply, before two features shallowly.
- The interface IS the product. The engine just has to keep up.
- Anything important should fit on one screen.
> "The best note-taking system is the one you already have open."
> — every productivity post ever, and also true
| Provider | Strength | Weakness |
|---|---|---|
| Claude | Long context, instruction following | Slow for tiny prompts |
| GPT-4o | Multimodal, fast | Drifts on long sessions |
| Cursor | Code-aware ranking | Locked to editor |
```mermaid
flowchart LR
Capture --> Organize
Organize --> Use
Use -.indispensability loop.-> Capture
```
## Recap
Most personal-knowledge tools optimise for input. The friction is on the way in: capture this thought, file it, tag it, link it. But the value lives on the way OUT — when the system surfaces the right note at the right moment without you asking. Capture-heavy products are easier to build; output-heavy ones are what people actually pay for.
---
id: dc400be3d9c2
title: The 30-second cache rule
url: https://memory.wiki/dc400be3d9c2
updated: 2026-04-27T07:56:00+00:00
---
# The 30-second cache rule
Cross-AI portability is the structural moat OpenAI and Anthropic can't build for themselves. The user's context, exported as a public URL, becomes infrastructure that survives any single vendor's pivot. That's why the right primitive isn't an API key — it's a permalink.
The hardest part of a 1-person startup isn't the work — it's the lack of a forcing function. Without a meeting on Tuesday, nothing has to ship on Monday. The schedule has to come from somewhere, and "because I said so" isn't enough.
Markdown won because it was always good enough. Not the best at any one thing — never the fastest editor, never the prettiest output, never the most semantically rich. But always close enough that the switching cost killed every alternative.
### Capture-flow check-list
- [x] Pulled from Safari via Share Sheet
- [x] OCR'd a whiteboard photo
- [x] Dictated three voice memos walking to coffee
- [ ] Imported the long PDF I was avoiding
- [ ] Cleaned the inbox folder
```swift
// SwiftUI: keep all five tab views mounted across tab switches so
// each view's @StateObject model persists.
ZStack {
ForEach(AppTab.allCases, id: \.self) { tab in
view(for: tab)
.opacity(router.selectedTab == tab ? 1 : 0)
.allowsHitTesting(router.selectedTab == tab)
}
}
```
| Provider | Strength | Weakness |
|---|---|---|
| Claude | Long context, instruction following | Slow for tiny prompts |
| GPT-4o | Multimodal, fast | Drifts on long sessions |
| Cursor | Code-aware ranking | Locked to editor |
The thesis here[^1] is that delivery model matters more than retrieval quality.
[^1]: First articulated in the W6 internal note "Graph RAG is delivery, not retrieval."
## Recap
The hardest part of a 1-person startup isn't the work — it's the lack of a forcing function. Without a meeting on Tuesday, nothing has to ship on Monday. The schedule has to come from somewhere, and "because I said so" isn't enough.
---
id: 38374b9d8f59
title: The Pragmatic Programmer revisit
url: https://memory.wiki/38374b9d8f59
updated: 2026-04-21T23:06:00+00:00
---
# The Pragmatic Programmer revisit
Most personal-knowledge tools optimise for input. The friction is on the way in: capture this thought, file it, tag it, link it. But the value lives on the way OUT — when the system surfaces the right note at the right moment without you asking. Capture-heavy products are easier to build; output-heavy ones are what people actually pay for.
Reading other people's code is a higher-leverage activity than writing your own. You learn three things at once: what works, what doesn't, and why someone smart picked the trade-off you'd never have considered. The ratio of read-to-write hours quietly separates the engineers who plateau from the ones who keep compounding.
The interesting thing about long-context models isn't that they can read more — it's that they finally make the *retrieval* problem optional. When a model can hold the whole repo in context, the question shifts from "what should I fetch?" to "what should I show?". That's a UX question, not an infrastructure one.
### Capture-flow check-list
- [x] Pulled from Safari via Share Sheet
- [x] OCR'd a whiteboard photo
- [x] Dictated three voice memos walking to coffee
- [ ] Imported the long PDF I was avoiding
- [ ] Cleaned the inbox folder
```mermaid
sequenceDiagram
participant U as User
participant M as Memory.Wiki
participant A as AI
U->>M: Save thought / URL / photo
M-->>U: Permalink
U->>A: "Use [URL] as my context"
A-->>U: Answer grounded in the hub
```
## What changed
A good error message answers three questions: what happened, why it happened, and what to try next. Most ship the first, hint at the second, and forget the third. The fix is usually a single sentence longer.
---
id: 53bac621b960
title: Reading log: October-November
url: https://memory.wiki/53bac621b960
updated: 2026-04-19T03:52:00+00:00
---
# Reading log: October-November
The interesting thing about long-context models isn't that they can read more — it's that they finally make the *retrieval* problem optional. When a model can hold the whole repo in context, the question shifts from "what should I fetch?" to "what should I show?". That's a UX question, not an infrastructure one.
Markdown won because it was always good enough. Not the best at any one thing — never the fastest editor, never the prettiest output, never the most semantically rich. But always close enough that the switching cost killed every alternative.
Most personal-knowledge tools optimise for input. The friction is on the way in: capture this thought, file it, tag it, link it. But the value lives on the way OUT — when the system surfaces the right note at the right moment without you asking. Capture-heavy products are easier to build; output-heavy ones are what people actually pay for.
### Capture-flow check-list
- [x] Pulled from Safari via Share Sheet
- [x] OCR'd a whiteboard photo
- [x] Dictated three voice memos walking to coffee
- [ ] Imported the long PDF I was avoiding
- [ ] Cleaned the inbox folder
```python
# Tiny script that prints any URL's title.
import requests, re
def title(url: str) -> str:
html = requests.get(url, timeout=5).text
m = re.search(r"(.*?)", html, re.S | re.I)
return m.group(1).strip() if m else url
print(title("https://memory.wiki"))
```
> "Make the easy thing the default and the hard thing possible."
> — design rule I keep stealing from Linear
```mermaid
flowchart LR
Capture --> Organize
Organize --> Use
Use -.indispensability loop.-> Capture
```
## Next steps
The interesting thing about long-context models isn't that they can read more — it's that they finally make the *retrieval* problem optional. When a model can hold the whole repo in context, the question shifts from "what should I fetch?" to "what should I show?". That's a UX question, not an infrastructure one.
---
id: 7c265e654e4f
title: Notes from Show Your Work
url: https://memory.wiki/7c265e654e4f
updated: 2026-04-15T03:33:00+00:00
---
# Notes from Show Your Work
Branding is not the logo. It's the consistency of every micro-decision: button radius, copy voice, error tone, empty-state warmth. The logo just labels the bag. The branding is what's inside it.
A good error message answers three questions: what happened, why it happened, and what to try next. Most ship the first, hint at the second, and forget the third. The fix is usually a single sentence longer.
Cross-AI portability is the structural moat OpenAI and Anthropic can't build for themselves. The user's context, exported as a public URL, becomes infrastructure that survives any single vendor's pivot. That's why the right primitive isn't an API key — it's a permalink.
### Three rules I keep returning to
- Ship one feature, deeply, before two features shallowly.
- The interface IS the product. The engine just has to keep up.
- Anything important should fit on one screen.
> "Make the easy thing the default and the hard thing possible."
> — design rule I keep stealing from Linear
## Next steps
The interesting thing about long-context models isn't that they can read more — it's that they finally make the *retrieval* problem optional. When a model can hold the whole repo in context, the question shifts from "what should I fetch?" to "what should I show?". That's a UX question, not an infrastructure one.
---
id: 06c21d15e0e5
title: A note to my future self
url: https://memory.wiki/06c21d15e0e5
updated: 2026-04-05T08:49:00+00:00
---
# A note to my future self
Most personal-knowledge tools optimise for input. The friction is on the way in: capture this thought, file it, tag it, link it. But the value lives on the way OUT — when the system surfaces the right note at the right moment without you asking. Capture-heavy products are easier to build; output-heavy ones are what people actually pay for.
The interesting thing about long-context models isn't that they can read more — it's that they finally make the *retrieval* problem optional. When a model can hold the whole repo in context, the question shifts from "what should I fetch?" to "what should I show?". That's a UX question, not an infrastructure one.
Branding is not the logo. It's the consistency of every micro-decision: button radius, copy voice, error tone, empty-state warmth. The logo just labels the bag. The branding is what's inside it.
```bash
# Resize + WebP-encode every PNG in the current folder.
for f in *.png; do
sips -Z 1280 "$f" --setProperty format webp --out "${f%.png}.webp"
done
```
> "If the user has to know how it works, you've failed."
> — paraphrased, but the spirit is right
## Recap
The interesting thing about long-context models isn't that they can read more — it's that they finally make the *retrieval* problem optional. When a model can hold the whole repo in context, the question shifts from "what should I fetch?" to "what should I show?". That's a UX question, not an infrastructure one.
---
id: 4b4d23da4045
title: URL → markdown conversion (server-side recipe)
url: https://memory.wiki/4b4d23da4045
updated: 2026-04-02T06:06:00+00:00
---
# URL → markdown conversion (server-side recipe)
Reading other people's code is a higher-leverage activity than writing your own. You learn three things at once: what works, what doesn't, and why someone smart picked the trade-off you'd never have considered. The ratio of read-to-write hours quietly separates the engineers who plateau from the ones who keep compounding.
Reading other people's code is a higher-leverage activity than writing your own. You learn three things at once: what works, what doesn't, and why someone smart picked the trade-off you'd never have considered. The ratio of read-to-write hours quietly separates the engineers who plateau from the ones who keep compounding.
A good error message answers three questions: what happened, why it happened, and what to try next. Most ship the first, hint at the second, and forget the third. The fix is usually a single sentence longer.
```bash
# Resize + WebP-encode every PNG in the current folder.
for f in *.png; do
sips -Z 1280 "$f" --setProperty format webp --out "${f%.png}.webp"
done
```
> "Make the easy thing the default and the hard thing possible."
> — design rule I keep stealing from Linear
| Surface | Latency goal | Notes |
|---|---|---|
| Capture | <1s tap → toast | local-first, server is best-effort |
| Open | <500ms URL → LCP | edge cache for public URLs |
| Search | <250ms keystroke → results | semantic + lexical merged |
The model's loss on the held-out set converged to $\mathcal{L} = 2.41$ after roughly $1.2 \times 10^4$ steps — well above the chance baseline of $\log_2 50{,}000 \approx 15.6$ bits per token but still leaving room for the next architecture pass.
```mermaid
flowchart LR
Capture --> Organize
Organize --> Use
Use -.indispensability loop.-> Capture
```
The thesis here[^1] is that delivery model matters more than retrieval quality.
[^1]: First articulated in the W6 internal note "Graph RAG is delivery, not retrieval."
## Recap
Markdown won because it was always good enough. Not the best at any one thing — never the fastest editor, never the prettiest output, never the most semantically rich. But always close enough that the switching cost killed every alternative.
---
id: 8512f1485e0c
title: Supabase RLS patterns I keep copy-pasting
url: https://memory.wiki/8512f1485e0c
updated: 2026-03-28T07:32:00+00:00
---
# Supabase RLS patterns I keep copy-pasting
Cross-AI portability is the structural moat OpenAI and Anthropic can't build for themselves. The user's context, exported as a public URL, becomes infrastructure that survives any single vendor's pivot. That's why the right primitive isn't an API key — it's a permalink.
Most personal-knowledge tools optimise for input. The friction is on the way in: capture this thought, file it, tag it, link it. But the value lives on the way OUT — when the system surfaces the right note at the right moment without you asking. Capture-heavy products are easier to build; output-heavy ones are what people actually pay for.
The interesting thing about long-context models isn't that they can read more — it's that they finally make the *retrieval* problem optional. When a model can hold the whole repo in context, the question shifts from "what should I fetch?" to "what should I show?". That's a UX question, not an infrastructure one.
### Three rules I keep returning to
- Ship one feature, deeply, before two features shallowly.
- The interface IS the product. The engine just has to keep up.
- Anything important should fit on one screen.
```swift
// SwiftUI: keep all five tab views mounted across tab switches so
// each view's @StateObject model persists.
ZStack {
ForEach(AppTab.allCases, id: \.self) { tab in
view(for: tab)
.opacity(router.selectedTab == tab ? 1 : 0)
.allowsHitTesting(router.selectedTab == tab)
}
}
```
| Provider | Strength | Weakness |
|---|---|---|
| Claude | Long context, instruction following | Slow for tiny prompts |
| GPT-4o | Multimodal, fast | Drifts on long sessions |
| Cursor | Code-aware ranking | Locked to editor |
## Open questions
Reading other people's code is a higher-leverage activity than writing your own. You learn three things at once: what works, what doesn't, and why someone smart picked the trade-off you'd never have considered. The ratio of read-to-write hours quietly separates the engineers who plateau from the ones who keep compounding.
---
id: e7a714048331
title: JSON schema for a doc with attachments
url: https://memory.wiki/e7a714048331
updated: 2026-03-23T07:23:00+00:00
---
# JSON schema for a doc with attachments
A good error message answers three questions: what happened, why it happened, and what to try next. Most ship the first, hint at the second, and forget the third. The fix is usually a single sentence longer.
Reading other people's code is a higher-leverage activity than writing your own. You learn three things at once: what works, what doesn't, and why someone smart picked the trade-off you'd never have considered. The ratio of read-to-write hours quietly separates the engineers who plateau from the ones who keep compounding.
Markdown won because it was always good enough. Not the best at any one thing — never the fastest editor, never the prettiest output, never the most semantically rich. But always close enough that the switching cost killed every alternative.
```bash
# Resize + WebP-encode every PNG in the current folder.
for f in *.png; do
sips -Z 1280 "$f" --setProperty format webp --out "${f%.png}.webp"
done
```
## Next steps
Markdown won because it was always good enough. Not the best at any one thing — never the fastest editor, never the prettiest output, never the most semantically rich. But always close enough that the switching cost killed every alternative.
---
id: 6045a1f67e69
title: Meeting with the legal team — context dump
url: https://memory.wiki/6045a1f67e69
updated: 2026-03-18T01:46:00+00:00
---
# Meeting with the legal team — context dump
The hardest part of a 1-person startup isn't the work — it's the lack of a forcing function. Without a meeting on Tuesday, nothing has to ship on Monday. The schedule has to come from somewhere, and "because I said so" isn't enough.
Most personal-knowledge tools optimise for input. The friction is on the way in: capture this thought, file it, tag it, link it. But the value lives on the way OUT — when the system surfaces the right note at the right moment without you asking. Capture-heavy products are easier to build; output-heavy ones are what people actually pay for.
Markdown won because it was always good enough. Not the best at any one thing — never the fastest editor, never the prettiest output, never the most semantically rich. But always close enough that the switching cost killed every alternative.
### Today's reading list
1. *Designing Data-Intensive Applications* — chapter 5 (replication)
2. The Hacker News thread on "What I learned writing a JIT"
3. A Stripe engineering blog post about idempotency keys
4. Karpathy's tweet thread about LLM evals
```swift
// SwiftUI: keep all five tab views mounted across tab switches so
// each view's @StateObject model persists.
ZStack {
ForEach(AppTab.allCases, id: \.self) { tab in
view(for: tab)
.opacity(router.selectedTab == tab ? 1 : 0)
.allowsHitTesting(router.selectedTab == tab)
}
}
```
| Surface | Latency goal | Notes |
|---|---|---|
| Capture | <1s tap → toast | local-first, server is best-effort |
| Open | <500ms URL → LCP | edge cache for public URLs |
| Search | <250ms keystroke → results | semantic + lexical merged |
The model's loss on the held-out set converged to $\mathcal{L} = 2.41$ after roughly $1.2 \times 10^4$ steps — well above the chance baseline of $\log_2 50{,}000 \approx 15.6$ bits per token but still leaving room for the next architecture pass.
```mermaid
sequenceDiagram
participant U as User
participant M as Memory.Wiki
participant A as AI
U->>M: Save thought / URL / photo
M-->>U: Permalink
U->>A: "Use [URL] as my context"
A-->>U: Answer grounded in the hub
```
## Next steps
Markdown won because it was always good enough. Not the best at any one thing — never the fastest editor, never the prettiest output, never the most semantically rich. But always close enough that the switching cost killed every alternative.
---
id: cd48bf42bf7c
title: Travel notes: Seoul → Tokyo
url: https://memory.wiki/cd48bf42bf7c
updated: 2026-03-13T10:56:00+00:00
---
# Travel notes: Seoul → Tokyo
Markdown won because it was always good enough. Not the best at any one thing — never the fastest editor, never the prettiest output, never the most semantically rich. But always close enough that the switching cost killed every alternative.
Markdown won because it was always good enough. Not the best at any one thing — never the fastest editor, never the prettiest output, never the most semantically rich. But always close enough that the switching cost killed every alternative.
A good error message answers three questions: what happened, why it happened, and what to try next. Most ship the first, hint at the second, and forget the third. The fix is usually a single sentence longer.
### Today's reading list
1. *Designing Data-Intensive Applications* — chapter 5 (replication)
2. The Hacker News thread on "What I learned writing a JIT"
3. A Stripe engineering blog post about idempotency keys
4. Karpathy's tweet thread about LLM evals
```typescript
// Server-sent events from /api/import/url
const res = await fetch("/api/import/url", {
method: "POST",
headers: { "Content-Type": "application/json", Accept: "text/event-stream" },
body: JSON.stringify({ url })
});
for await (const chunk of res.body!) {
// parse SSE: 'event: stage' / 'data: {...}'
}
```
| Provider | Strength | Weakness |
|---|---|---|
| Claude | Long context, instruction following | Slow for tiny prompts |
| GPT-4o | Multimodal, fast | Drifts on long sessions |
| Cursor | Code-aware ranking | Locked to editor |
```mermaid
flowchart LR
Capture --> Organize
Organize --> Use
Use -.indispensability loop.-> Capture
```
The thesis here[^1] is that delivery model matters more than retrieval quality.
[^1]: First articulated in the W6 internal note "Graph RAG is delivery, not retrieval."
## Recap
A good error message answers three questions: what happened, why it happened, and what to try next. Most ship the first, hint at the second, and forget the third. The fix is usually a single sentence longer.
---
id: e6c954035423
title: Letter to a future hire
url: https://memory.wiki/e6c954035423
updated: 2026-03-08T23:25:00+00:00
---
# Letter to a future hire
The interesting thing about long-context models isn't that they can read more — it's that they finally make the *retrieval* problem optional. When a model can hold the whole repo in context, the question shifts from "what should I fetch?" to "what should I show?". That's a UX question, not an infrastructure one.
The interesting thing about long-context models isn't that they can read more — it's that they finally make the *retrieval* problem optional. When a model can hold the whole repo in context, the question shifts from "what should I fetch?" to "what should I show?". That's a UX question, not an infrastructure one.
A good error message answers three questions: what happened, why it happened, and what to try next. Most ship the first, hint at the second, and forget the third. The fix is usually a single sentence longer.
### Capture-flow check-list
- [x] Pulled from Safari via Share Sheet
- [x] OCR'd a whiteboard photo
- [x] Dictated three voice memos walking to coffee
- [ ] Imported the long PDF I was avoiding
- [ ] Cleaned the inbox folder
```python
# Tiny script that prints any URL's title.
import requests, re
def title(url: str) -> str:
html = requests.get(url, timeout=5).text
m = re.search(r"(.*?)", html, re.S | re.I)
return m.group(1).strip() if m else url
print(title("https://memory.wiki"))
```
> "The best note-taking system is the one you already have open."
> — every productivity post ever, and also true
```mermaid
flowchart LR
Capture --> Organize
Organize --> Use
Use -.indispensability loop.-> Capture
```
## Open questions
A good error message answers three questions: what happened, why it happened, and what to try next. Most ship the first, hint at the second, and forget the third. The fix is usually a single sentence longer.