Why publish knowledge as a graph rather than a book. How AI changes the rules. Why subscription over one-time sales. Below are all the essays, newest first; for a curated, themed list see the sidebar.
Why a call is a dot on a long thread rather than a summary of its own, how a thread note with one line per call becomes a timeline, and why an agent proposes and a person checks on a screen instead of answering in a chat.
We shipped three optional query fields for MCP search and measured them in the hands of real Claude agents: which fields they fill, whether OR helps the short one, whether telling them to fill more helps, and whether showing the size of a note changes how they read it.
We ran a product documentation base through Claude Code the way a user does and found five defects that every earlier benchmark had walked past: a note body that never reached the model, instructions lost on the new protocol, a 25-second connect, full-text search that answered most queries with nothing, and query fields that were measured but never shipped.
ontoship by Valerii Kovalskii is a knowledge base made of three things: markdown files, a README.md index in every folder, and git. Its CLI, gitmark, builds a search index, an HTML graph and reports from the same files. On top of that sits an optional ontology, and it is the part worth borrowing: every document gets a type, and a linter checks that the base keeps its shape as it grows. This essay shows how much of it a trip2g vault does today, and where it stops.
The trip2g positioning wheel is a folder of ordinary markdown notes and one layout. How it works, what the engine made easy, and where it pushed back.
Ubuntu 24.04 LTS aarch64, VMware on a Mac, no desktop environment — dwm under bare X11, startx from TTY. Obsidian 1.12.7 (tested both Flatpak and AppImage).
This feature is in development. If it interests you — reach out on Telegram to discuss your use case.
This feature is in development. If it interests you — reach out on Telegram to discuss your use case.
This feature is in development. If it interests you — reach out on Telegram to discuss your use case.
trip2g is content infrastructure. People and AI agents work with the same content on equal footing. Content doesn't sit idle — it flows between participants and transforms at every step.
What we did: took apart how qmd expands a query, which I first got wrong. Proposed handing that work to the agent that is already connected over MCP: it passes three optional fields with the query. Chose the field names on three models and measured the gain on 236 queries: with a strong agent nDCG@5 rose on all four sets, and clearly so on the Russian base set, from 0.603 to 0.702. With a weak agent (gpt-5.4-mini) the gain almost disappears, and the description of a single field matters most. Read it if you run MCP search and are thinking about adding query rewriting.
In June trip2g served 4 000 pages a second. In October we measured it again on 10 000 notes with a profiler on every path. The cache holds the same numbers, search, MCP and the template had grown new bottlenecks, and the published sync number turned out to be measured on synthetic notes.
Why every knowledge base in trip2g has exactly one writer, and how a team space is assembled from federated bases instead of a permission matrix over one shared wiki. Notion and Confluence permissions, Federated Wiki, and where the idea falls short.
Zhamak Dehghani's four data mesh principles in plain words, mapped onto knowledge bases in trip2g: domain ownership, knowledge as a product, a self-serve platform, federated governance. Plus Backstage TechDocs, the known criticism, and where the analogy flatters.
Picture a team where every employee works with their own AI agent (ours is hermes), and every agent keeps its memory in its own trip2g base. The manager wants to know each morning what the team plans and each evening how the day went. Without a stand-up call, without a form to fill, and without anyone sending a report.
The AI Mindset team names the notes in its vaults by one pattern:
What this is about: in one week we found in trip2g's templates escaping that was switched off, a nil that isn't nil, anchors that no wikilink lands on, and a reference that said the opposite of the code in three places. A static site generator or a CMS does all of this for you, and you never find out. Read it if you write your own layouts for trip2g or are picking a template engine for your own product.
What we did: took a private knowledge base for a training course, connected to agents over MCP, and asked four Claude models the same questions, with the server instructions and without them. A blind judge scored the answers. The short version: a weak model needs instructions and fails without them; strong models find the instructions on their own. Read it if you are building a knowledge base for agents and wondering whether to write instructions for it.
What we did: built a bilingual set of 236 queries against Obsidian's help docs, ran trip2g, qmd and obsidian-hybrid-search on it and scored everything with one script, without trusting the numbers in other people's READMEs. We found two reasons trip2g was losing in Russian. We added alias search: in its own query category it lifted nDCG@5 from 0.81 to 0.98. The biggest gain came from fields an agent passes over MCP: plus 0.10 on the Russian base set and about 0.05 on the others. Read it if you run search over notes and want to see how it looks next to its neighbours.
What we did: took apart, from code and from a write-up, how search works in five other systems, and compared it with ours. For Hindsight we also checked on the live models what happens to Russian text. AnythingLLM is a popular self-hosted chat-with-your-documents app. qmd is Tobi Lütke's local search engine for markdown. Cerebras Knowledge is the company's internal knowledge base, answering 15,000 questions a day. Hindsight is memory for AI agents, built on a graph of facts. obsidian-hybrid-search is MCP search over an Obsidian vault, the closest to us in purpose. Each system gets its own section, with a summary table at the end. Read it if you are building search over notes and want to know which decisions everyone makes the same way and where there is a real choice.
What this is: the trip2g server refused an immunology abstract because it decided the abstract was a font. Here is why that happened, and why a check that looked sensible never suited notes in the first place. Read it if you validate uploads by looking at their content.
Your call recordings live at the recorder — mine at Krisp: its account, its rules, its search. trip2g pulls them out into a vault you own: the verbatim transcript, one note per call, search on top. What does the pulling is not a service and not a plugin. It is a markdown note. The frontmatter is the configuration, the body is a fenced python block, and that block is the job. You version it, edit it and sync it like any other note, and the recorder's token sits sealed in its own frontmatter.
One afternoon in September I asked a cheap AI assistant three questions about my own knowledge base, then read not its answers but everything it did on the way to them. I found six small defects in the service that the assistant talks to. Nobody had reported them, and I think I know why. A follow-up to the instructions A/B.
What this is: what a reranker is, why search wants one, and how ours spent six weeks in production returning an error to every single call. 61,354 failures out of 61,359 requests, and nobody saw one of them. Also why we ended up switching it off rather than fixing it. Read it if you run hybrid search and are weighing a second stage.
What this is about: Telegram's new Rich Messages — posts shaped like a document instead of a chat message — what they give someone publishing long-form content, and what trip2g is going to build to use them. The conclusions up front. Rich messages carry real headings, media sitting with the paragraphs it belongs to, and eight times the room: a document, not a message. A bot can send them today, free and ungated, into private chats and into channels alike — about 250 live API calls behind that sentence, and no chat-type gate anywhere in them. And they render: I have now opened the probe channel in a real client, and it all looks the way it was meant to. The build turns out far smaller than it looked: no library upgrade, no MTProto work, no new dependency, just a second renderer over the goldmark AST we already walk. The price is a per-chat opt-in, a verification step after every send, custom emoji we lose on the way, and one product decision — channels published through a user account stay classic.
What this is about: the same question as the first essay — what class trip2g belongs to and who its neighbors are — but after checking against the reality of July 2026. The short answer changed. trip2g is not "the empty middle of flat-file CMS": that middle has been claimed by Grav 2.0, which is more honestly flat-file and now ships the same AI story. The actual, narrow, and defensible niche is the intersection of two things that nobody else has: the authoring surface is your personal Obsidian vault with two-way sync, and the delivery is web + Telegram + agent (MCP) + federation between hubs, over canonical SQLite. Everything else — write-API, app-shell, MCP — has been table stakes since June 2026, not differentiators.
What this is about: what class trip2g belongs to, who its neighbors are, and what in the positioning is honest versus marketing. Short answer: it's a flat-file CMS — content in files, rendering at runtime, no separate database server. The niche has existed for fifteen years but stayed thin: the market split into two poles — static generators and database-backed CMSes — and almost nobody occupied the middle. trip2g stands in that middle, with two differences: the editing surface is a local Obsidian vault with sync, and under the hood it's not literal files but SQLite. A hybrid: you edit like files, the server works like a database.
I have been using this architectural approach in Go for 7+ years. It has no established name; it is a natural evolution of idiomatic Go applied to a real monolith.
Recording a clean video of a feature forces you to walk its entire happy path on the real product. The bugs that surface are the ones that otherwise wait for a live demo in front of a client.
Why we chose Obsidian as the foundation for trip2g. What Markdown and wikilinks are, and why they change how we think about knowledge.
AI is the single biggest shift making knowledge graphs relevant right now.
What this is: a measured A/B on two cheap models. I gave Claude Haiku and GPT-5.4-nano an MCP connection to the trip2g docs and asked each eight questions, once with a short instructions note in its context and once without. Same tools, same questions. The instructions note made Haiku search 26% faster with 41% fewer whole-note dumps. nano, already frugal on its own, barely needed it. Read it if you run a knowledge base over MCP and wonder whether the instructions note earns its keep.
What this is: we wrote alert-sink, a small open-source service that turns Alertmanager webhooks into incident notes in a trip2g instance. Every alert becomes a markdown note, the notes add up to a permanent searchable incident history, and the knowledge base can narrate incidents to a Telegram group on its own. Read it if your incident history currently lives in a chat scrollback.
Here is what we found when we actually measured trip2g's vector search.
What universal tools cost — to the people who build on them, and to the people who use them.
Features we built and deleted, or evaluated and refused — with the numbers that decided.
What this is: trip2g read as a literal operating system, notes as the filesystem, MCP as syscalls, federation as the network, agents as processes. Every row in the map is tagged by how real it is, so you can see where the metaphor is earned and where it is not. Read it if you want to judge whether "Markdown OS" is a real claim or just a label.
trip2g is a publishing platform: Obsidian vaults → websites with subscriptions and Telegram integration. Go monolith + $mol frontend + SQLite.
Why Obsidian is so hard to explain in one sentence, why trip2g has the same problem, and why that's a property of the tool, not a failure of marketing.
A language model is good at seeing where a conversation turns. It is bad at arithmetic on timestamps. My first attempt at splitting call transcripts into topics ignored that. I asked for [start–end] blocks, and the model couldn't keep the intervals straight. What fixed it wasn't a sharper prompt, and it wasn't a bigger model. It was a different question: ask where each topic starts (one real timestamp from the transcript) and let code work out the spans. The cheapest model then placed transitions 100% in order and 97% on real timestamps, and it beat the bigger model.
What this is: the story of a SQLITE_BUSY error I chased for half a year, blamed on SQLite, and finally found in my own connection pool. Part war story, part the case for running a database inside one process. Read it if you have ever seen "database is locked" and wondered whether SQLite was the wrong call.
After the page cache shipped, we profiled again. Rendering had disappeared from the hot path. A third of the CPU was now in SQLite's SQL parser.
The profiler said the plain documentation page was 30× more expensive than the custom-designed landing. We expected the opposite.
TL;DR. Vibe coding is building software by prompting an AI in natural language and accepting the output without reading, understanding, or reviewing the code. The same activity has two opposite reputations — democratizing miracle and silent bug factory — and the dividing line is not whether AI wrote the code, but whether a human understands what shipped.
Short version. A trip2g knowledge network (markdown vaults backed by SQLite) can run on preemptible nodes. They cost far less and can vanish at any moment. In a synthetic test the network survives it: a node dies, comes up on another machine, and restores its data in about 35 seconds, losing no more than 1 second of writes. What holds the data is not the local disk but a copy in object storage (Litestream). The rest is detail: what I tested, how it works, and where the limits are.
A vault is a folder of markdown notes you navigate as a linked graph. The same thing Obsidian users call a "vault." The one difference: ours is not tied to Obsidian.
We re-reviewed trip2g's Obsidian sync, expecting to tune a slow hashing path. Then we built a benchmark and measured. The slow part was somewhere else entirely — one missing flag that turned a 3-second push into a 4-minute one.
A bit over a month after the first federation commit, our public trip2g hub is live: one MCP endpoint that searches across several independent knowledge bases at once. The demo is the small part. The bet is the network — bases owned by different people, reachable through a single address, queryable by any agent with no central registry.
When you work with an agent all day, the team sees nothing. A commit might appear by evening — if it appears at all. What the agent was doing for six hours is a mystery. This skill closes that gap: after every turn, the agent automatically writes a short report and sends it to trip2g.
Every morning the agent reads what team members worked on yesterday and writes a daily note. Every Monday, a weekly summary. Nobody enters anything manually — the data comes from each member's trip2g instance via MCP.
Books, courses, and channels are familiar formats. But each comes with limitations that a knowledge graph removes.
An expert's knowledge is like an iceberg. What's visible is a small fraction of what's actually there.
A note is a node. A link between notes is an edge. Together they form a graph.
A new business model for experts: not selling knowledge, but renting access to a living system.
Concrete use cases for a knowledge graph.
Dogfooding is a development philosophy where the team uses its own product in real work. The term originated at Microsoft in the 80s: "eating your own dog food."
Your knowledge should belong to you. Not to a platform, not to a service — to you.
A CMS with no content inside. It sounds like a paradox, but that's the whole point.
You describe what you want, not how to get it. The system figures out the rest.
Every feature needs settings. A Telegram bot needs a token and group IDs. OAuth needs keys for Google and GitHub. Patreon needs an API token and subscription tiers.