Launch kit — Show HN + Reddit + dev.to (drafts, human fires)

1.1 Title — three A/B options

• A (data-ownership shape, mirrors the 1087-pt Obsidian title):
  Show HN: Trip2g – Self-hosted server that turns an Obsidian vault into a website and MCP server
• B (self-hosted + stack shape, mirrors OpenWorkers/Plausible):
  Show HN: Trip2g – Publish markdown notes to humans (web) and agents (MCP) – Go/SQLite/MIT
• C (benchmark-forward, riskier but the most differentiated):
  Show HN: Trip2g – MCP memory as plain markdown notes (15x fewer tokens than full-note reads)

Recommendation: A. It names the audience's noun (Obsidian vault) and the two outputs. B if the human wants the stack in the title; C only if launching primarily to the agent-infra crowd. HN allows one shot per project every few months — pick one, don't actually A/B.

1.2 Post body

HN Show HN submissions with a URL have no body; the body below goes in the text field only if submitting as a text post — otherwise fold it into the first comment. Plan for URL submission + first comment.

1.3 First comment (the maker comment — post within 5 minutes)

Hi HN, author here.

trip2g is a self-hosted Go server (single binary, SQLite, MIT) that serves one set of markdown notes two ways: to humans as a website, to AI agents over MCP. An Obsidian vault syncs into it two-way — edit locally, the page is live in about a second; edit through the API, it flows back to your vault. Every edit is versioned and mirrored to git, so the vault is also git clone-able over Smart HTTP.

The part I'd most like you to poke at is the retrieval economics. Search results carry a toc_path pointing at the exact section, so an agent reads ~200 tokens instead of the whole note. On the live docs vault that's a median 15× saving (up to 37× on long notes) versus loading the full note. It's measured against the public endpoint with a zero-dependency Python script you can run yourself in under a minute: https://trip2g.com/en/user/token-economy-bench — the script is on the page. To be fair about the baseline: 15× is against the naive whole-note dump, not against a tuned RAG pipeline. And the token saving turned out to be the easy half — deterministic section-picking failed on 8 of 9 real queries in our tests; landing on the right section is a navigation problem, which is why search returns a precise path instead of "somewhere in this file".

Stack: Go + FastHTTP, gqlgen, SQLite (+ Litestream for streaming backup), bleve for full-text, Goldmark for markdown, embeddings via any OpenAI-compatible API for semantic search. Hubs can federate: one MCP query fans out to peer hubs with HMAC-signed, depth-limited calls.

Honest limitations:

• Semantic search needs an external embeddings API (or any OpenAI-compatible endpoint you host). Full-text works fully offline.
• No graph view. If that's your favorite Obsidian feature, Obsidian Publish or Quartz will make you happier.
• The note-triggered agent runtime you'll see in the README table is on a branch, not main. The table marks shipped vs branch vs planned honestly — hold me to it.
• The frontend uses $mol, a framework you've probably never heard of. It works well for us; contributing to the admin UI has a learning curve.
• Young project, small community. You'd be an early adopter, with everything that implies.

It's docker compose up to self-host, or there's a free cloud instance if you don't want to run a server. Happy to answer anything about the sync protocol, the federation design, or the benchmark methodology.

(Human should rewrite the first line in their own voice and add one sentence of personal backstory — why they built it. The 416-pt sync-server post shows the personal motive is worth real points; an AI can't write it for them.)

1.4 FAQ crib sheet for the thread

Prepared answers — the human rephrases, never pastes verbatim (HN notices):

2.1 r/ObsidianMD — angle: two-way sync

Rules/etiquette notes: showcase-type flair for tools/plugins; self-promo is tolerated when the post is genuinely useful to Obsidian users and the author engages; the community is allergic to "yet another AI thing" framing — lead with the vault workflow, mention MCP once. The plugin is not yet in the community-plugin directory (growth-plan Step 5) — say so plainly or the first comment will.

Title:
I built a self-hosted server with true two-way sync: edit in Obsidian → live on your site in ~1s, edit on the site → flows back to your vault

Body:

My vault is the source of truth for everything I publish, and I got tired of the export→build→deploy loop (and of Publish's template limits). So I built trip2g: a self-hosted server (Go, SQLite, MIT) your vault syncs into, two-way.

What it does with the vault:

• Edit a note in Obsidian, the web page updates in about a second. Edit through the site/API, the change lands back in your local vault.
• Wikilinks work natively (Goldmark), frontmatter drives routing, layouts, forms.
• Every edit is versioned; the whole vault is also served over git Smart HTTP, so git clone is your backup.
• Notes can publish to a Telegram channel with links kept intact, and there's an MCP endpoint if you want AI tools to search the same notes.
• Paywalls/subscriptions if you publish paid content.

Honest caveats: no graph view; you run a server (or use the free cloud instance); the sync plugin is side-loaded for now — it's not in the community plugin directory yet, that review is pending. If you want zero-ops publishing, Obsidian Publish or Quartz are the right answers and I say so in the docs comparison pages.

Repo: https://github.com/trip2g/trip2g · docs run on it (dogfood): https://trip2g.com

Author here, happy to answer anything about the sync protocol.

2.2 r/selfhosted — angle: docker compose, SQLite, MIT, no external deps

Rules/etiquette notes: the sub's canonical questions are always: license? docker compose? external dependencies? phone-home? resource footprint? Answer all five in the post. Self-promo posts by authors are accepted when flaired as such and the project is actually self-hostable. Expect "why not just use [existing wiki]" — the comparison table link is the answer.

Title:
trip2g – markdown publishing hub: Obsidian vault in; website, MCP, RSS, Telegram out. One Go binary + SQLite, MIT

Body:

Author post. trip2g is a self-hosted server for markdown notes: an Obsidian vault (or plain files over git) syncs in, and the same notes come out as a website, an RSS feed, Telegram channel posts, and an MCP endpoint for AI agents.

The r/selfhosted checklist up front:

• License: MIT, no open-core gating on main.
• Install: docker compose up. One process.
• Storage: SQLite only — no Postgres/Redis/vector-DB stack. Litestream for streaming backup. Assets go to any S3-compatible store (MinIO works).
• External dependencies: none required. Full-text search works fully offline. Semantic search is optional and needs an embeddings API (OpenAI-compatible — a local endpoint works).
• Phone-home: none.
• Footprint: runs multi-tenant on a small VM in production (that's how the public instance runs).

Extras that tend to matter here: multi-domain routing per note frontmatter, magic-link/OAuth/OIDC auth, encrypted secrets (AES-256-GCM), the whole knowledge base clonable over git Smart HTTP, and hub-to-hub federation (HMAC-signed, depth-limited) if you and friends each run one.

Caveats: young project; the fancy note-triggered agent runtime in the README is on a branch, not main (the README marks shipped vs branch honestly); web admin UI is functional, not gorgeous.

Repo: https://github.com/trip2g/trip2g · live instance (the docs run on it): https://trip2g.com

2.3 r/LocalLLaMA — angle: self-hosted MCP memory + the benchmark

Rules/etiquette notes: the sub respects benchmarks with methodology and code, and is hostile to cloud-tethered tools — lead with self-hosted + the offline story, and be upfront that semantic search wants an embeddings endpoint (point at local OpenAI-compatible servers). Posts that read as ads get buried; posts that read as measurements get discussed. Lead with the numbers, not the product.

Title:
Measured: agents reading a focused section vs the whole note — median 15× fewer tokens (up to 37×). Reproducible script, self-hosted MCP memory backed by plain markdown

Body:

I run my agents' memory as plain markdown notes on a self-hosted hub (Go + SQLite, MIT) and measured what section-level retrieval actually saves over MCP.

Setup: search results carry a toc_path pointing at the exact heading, so the agent does search → note_html(toc_path) and reads ~200 tokens instead of the full note. Eight real queries against the live docs vault:

method	tokens to answer	calls
MCP, focused section	~200	2
MCP, whole note	~2,700	2
naive grep files + read	~4,600	3

Median saving 15.4×, best case 37× (long notes), worst 3.7× (a note that was already short). Honest baseline note: this is vs the naive whole-note dump, not vs a tuned RAG pipeline — with good chunk retrieval the gap shrinks. And token saving turned out to be the easy half: deterministic section-picking failed 8/9 queries; the real work is landing on the right section, which is why search returns a precise path and there's an expand tool for tree navigation.

Reproduce it: 50-line stdlib-only Python script on the page, hits the public endpoint anonymously — https://trip2g.com/en/user/token-economy-bench. Point ENDPOINT at your own instance to measure your vault.

Why this shape of memory at all: the notes are human-readable, editable in Obsidian, versioned in git, and the same notes are a browsable website. It's deliberate memory, not automatic conversation capture — if you want auto-extraction, Mem0/Letta do that and I'm not claiming a LongMemEval score. Local story: full-text search is fully offline; semantic search takes any OpenAI-compatible embeddings endpoint, including a local one.

Repo: https://github.com/trip2g/trip2g. Author, happy to defend the methodology.

Gate (hard rule — do not fire before all are true)

• Step 1 content batch live on trip2g.com (at minimum: bench page current, publish-obsidian-vault-as-website, claude-code-persistent-memory, one vs-page per lane) — launch traffic that lands on missing pages is spent once and wasted.
• Step 2 engine fixes deployed (meta-description fallback, robots sitemap pointer, og_image — the share cards in §4 need it to render on social).
• Step 3 README converts in 10 seconds: GIF above the fold, plain two-line promise, repo topics set, CONTRIBUTING + good-first-issues up.
• python3 te_check.py against production returns the table (someone on HN will run it within the hour — if prod is mid-deploy or rate-limits, the whole hook inverts).
• Prod box headroom checked (one small VM hosts everything; HN front page is a load event — schedule no deploys that day, warm the page cache).
• Free-cloud-instance signup path tested end-to-end.
• Each subreddit's current rules re-read on the day; flair chosen.

Timing

One platform per day, HN first. If HN flops (< ~20 points by hour 3), that's fine and expected — the Reddit posts are independent shots, and a second Show HN of the same repo is acceptable months later with new substance.

The ~2-hour human runbook (launch day, HN)

1. T–30 min: re-run te_check.py against prod; open the README, bench page, cloud signup in incognito — all render, GIF loads. Coffee.
2. T=0: submit repo URL with the chosen title (§1.1). Immediately post the first comment (§1.3), rewritten in own voice with the personal backstory line added.
3. T+0…90 min (the decisive window): reply to every comment — fast, technical, zero defensiveness; concede valid criticisms explicitly ("fair — that's on the roadmap / that's a real limitation"). Use the FAQ crib (§1.4) as notes, never paste. Do not ask anyone to upvote; do not have friends comment.
4. T+90…120 min: keep replying at lower cadence; note recurring questions → they become docs FAQ entries and the next day's tweet material. Snapshot star count (star-history.com) for the growth-plan measurement log.
5. Rest of day: check the thread hourly; a slow answer to a hostile technical question at hour 5 costs more than one at hour 1.
6. Day 2: write the "what we learned from the thread" note (feeds Step-5 recurring presence), fix anything embarrassing that surfaced, then schedule the first Reddit post.

Expected outcomes — candid

• If HN lands (front page): ~100–300 stars in 48h at ~1.4 stars/upvote (arxiv 2511.04453) plus a durable traffic step; most impact is day-1.
• Base rate honesty: most Show HN posts get <10 points; the tag itself confers no advantage after controls (Show HN by the numbers). What moves the needle is a runnable claim + author presence — which is why the benchmark leads and the human owns the thread.
• Reddit posts individually smaller (tens of upvotes each is a win in these subs) but they compound: comment threads there rank in Google for the exact Step-1 queries.
• None of this replaces Steps 1–3; the launch spends attention that the content and README must convert.