trip2g

Publish your Obsidian vault as a website. Self-hosted MCP memory for AI agents.

Write in Obsidian, press Sync, your notes are live. The same self-hosted hub serves readers a website and serves agents an MCP endpoint, publishes to Telegram, and gates paid content. Under the hood it is a Markdown Operating System: every note is a file, and one note is both a web page for a human and a tool call for an agent.

Why trip2g

• Your notes work twice. One markdown file renders as a page for readers and answers search / note_html calls from any MCP client. No export step, no copy of your knowledge locked in a vector store you can't read.
• Your data stays yours. Plain markdown, a git-cloneable vault, every edit a readable diff. No SaaS in the middle, and you can move out any time with git clone.
• One process to run. A single Go binary on SQLite. It starts the same on a laptop, a small VM, or a container. MIT licensed.

Quickstart

See it work in 30 seconds. Add the public knowledge hub to any MCP client and ask it a question. It searches all connected bases and answers with sources:

{
  "mcpServers": {
    "trip2g": {
      "url": "https://trip2g.com/_system/mcp"
    }
  }
}

Run your own hub:

git clone https://github.com/trip2g/trip2g && cd trip2g/quickstart
docker compose up

Open http://localhost:8081, sign in with owner@example.com and code 111111, and download the preconfigured Obsidian vault from the home page. One container, files on local disk, full-text search — no other services needed.

Prefer no terminal? Get a free cloud instance. All the options (single binary, Docker Compose behind TLS, fly.io) are in the self-host guide.

Docs · Getting started · MCP tools · Self-host · Contributing

Everything is a note

Unix made everything a file. trip2g makes everything a note.

One global namespace, path-addressed, shared by humans and agents. A note is a markdown file: the frontmatter is its metadata, the body is its content. The same note is served as a web page (the display server) and over MCP (the agent's syscall surface), and every edit is snapshotted into note_versions and mirrored to git. So the history is a readable diff, not a binary blob.

   human A           human B           human C
      │                 │                 │
      ▼                 ▼                 ▼
   agent A           agent B           agent C
      │                 │                 │
      ▼                 ▼                 ▼
  ┌────────┐  MCP  ┌────────┐  MCP  ┌────────┐
  │ hub A  │ ◄───► │ hub B  │ ◄───► │ hub C  │
  └────────┘       └────────┘       └────────┘
       ▲                 ▲                 ▲
       └─── humans browse · agents query ──┘

The same hub serves the human (a website with subscriptions, RSS, Telegram) and the agent (MCP). Your data stays in plain markdown you can move out any time.

The map

trip2g borrows the operating-system vocabulary because the primitives line up. Each row is tagged by how real it is: shipped is running code on main, branch is running code on feat/agent-runtime, planned is a design doc.

Syscalls: the MCP server

Built into every hub. An agent never touches the database directly. It calls a small set of tools over MCP, and access is scoped to the caller's subscription.

Custom tools can be defined in note frontmatter (mcp_method:).

Network stack: federation

graph LR
    O[Obsidian vault] --> H[your hub]
    T[Telegram]       --> H
    H <-->|MCP federation| H2[peer hub]
    H2 --> B[their bases]
    H -->|/_system/mcp| A[agent]
    H2 -->|/_system/mcp| A

Peer hubs with trusted people or orgs. Each hub controls access per base. One agent question reaches the union of all connected knowledge. Loops are bounded the way IP packets are: each hub enforces max_depth against a per-hop counter (the X-MCP-Federation-Depth header), and every call carries a short-expiry, HMAC-signed token.

Each hub is itself a Markdown OS, so the network is a mesh between operating systems, the way the internet is a network between computers. The rows below are common shapes, not the only ones. The protocol does not assume a topology, so you can build any of them.

Process dispatch & scheduler: webhook agents

The kernel-side mechanism that runs an agent. Shipped on main.

• Change webhooks. A note create/update/remove POSTs to an agent, and the agent writes notes back via the API. Glob filtering picks which notes fire it, HMAC signs the delivery, and max_depth stops recursion.
• Cron webhooks. Run an agent on a schedule (0 9 * * *). A next_run_at column plus a per-minute system cron drive it, and goqite worker pools give per-queue concurrency and priority. Sync or async, with optional instruction context.

The agent itself can live anywhere. These webhooks just deliver the event and accept note writes back.

Userland: the agent fleet

In development on feat/agent-runtime, not yet on main.

The core idea: a note edit spawns a scoped, server-side agent run. Unlike a local editor or a static builder, the agent runs on the hub, scoped to the note's glob patterns, not on your laptop.

An agent is a note. Its frontmatter is the config: model, tools, read_patterns/write_patterns, trigger_on, for_each, max_depth, timeout_seconds. Its body is the instruction, a Jet template that can reference the changed note(s). A fleet daemon watches an agents folder, parses each role note, and registers it as a change webhook pointed back at itself. Drop a note to install an agent, remove the note to uninstall it.