Contributing to Eigenmesh: where we need help

Eigen Mesh is Apache 2.0 and developed in the open at github.com/hikaru90/eigen. The same codebase runs the managed service and self-hosted deployments — there is no "open source core" with a closed enterprise layer hidden somewhere. If you can read the repo, you can read the product.

That also means the things that need help are real things, not cosmetic. This post is an honest list of where contributions would actually move the needle, and where the bar is. No invented issue numbers, no fake roadmap. Just the areas we keep coming back to.

Docs and operator runbooks

The codebase moves faster than the docs. That's normal for a small project, but it means contributors who like writing — really writing, not "added a paragraph" — are wildly undervalued here.

Concrete gaps:

• Self-hosting runbooks for non-Docker setups. The canonical path is Docker Compose. People running on Kubernetes, Nomad, or bare systemd want to know what changes. We have notes; we don't have a clean runbook.
• MCP client configuration. Cursor and Claude Desktop are documented. Zed, Continue, OpenAI Agents SDK, and the long tail of MCP clients are not. Each one is a small, well-scoped PR.
• Troubleshooting expansions. The troubleshooting pages exist but are thin on edge cases — proxy headers, reverse-proxy TLS, IPv6-only hosts, slow LLM gateways. People hit these and we answer in issues; the answers should land in the docs.

The bar: the doc has to be true. If you're not sure, open a draft PR and we'll verify against the code together.

Eval harness for retrieval

This is the area with the highest leverage and the least glory.

Eigen Mesh uses hybrid retrieval — pgvector ANN, Postgres FTS, precomputed graph artifacts, and an LLM listwise rerank. Tuning that pipeline requires evals. Right now, evals are mostly ad hoc: a small set of hand-written queries, run manually, eyeballed. That doesn't scale to "I changed the rerank prompt, did I make things better or worse?"

What would help:

• A small, deterministic eval corpus — capture/retrieve pairs with known-good results.
• A runner that produces a score (recall@k, nDCG, something) instead of vibes.
• A way to diff two retrieval configurations against the same corpus.

This is unglamorous work, but it's the difference between "I think this is better" and "this is better by 12% on the eval set." Anyone who has built eval harnesses for RAG systems knows the shape; we just don't have one yet.

MCP client integrations and examples

The HTTP MCP surface is four tools. It's small on purpose. That means there's a long tail of "how do I wire this up in " that we haven't written.

Contributions that help:

• Client setup guides — for any MCP-compliant client we don't already cover. Each one is a docs PR plus, if needed, a small example repo.
• Bridge patterns for stdio-only clients — some clients still only speak stdio. A maintained, documented bridge would unblock a lot of self-hosters.
• Example agent loops — the "retrieve then compose" pattern for answer_question-style behavior. A reference implementation in TypeScript and one in Python would save every new integrator an afternoon.

The bar: it has to actually work against a running Eigen Mesh instance. We'll help you get one up.

Internationalization (i18n)

The product UI is English-first. The marketing site has localized copy. The in-app strings, error messages, and onboarding flows are not fully internationalized.

This matters more than it sounds. A second brain is a personal thing; people think in their first language. If the UI is English-only, we're quietly excluding everyone who doesn't.

What we need:

• String extraction and a translation framework. SvelteKit has good i18n primitives; we just haven't done the extraction pass across the whole UI.
• Initial translations — German, French, Spanish, Japanese are the obvious starting points given where users actually are.
• A glossary — "thought," "memory," "capture," "consolidation" all have specific meanings here. Translators need to know which sense is meant.

This is a great fit for contributors who want to make a real product difference without touching the retrieval pipeline.

Self-host UX and operator tooling

The self-host path works, but it's built by people who already know the stack. The rough edges show up when someone who isn't us tries it.

Areas where a contributor would help:

• A first-run health check. After docker compose up, did it actually come up healthy? A small script that checks DB connectivity, RLS, MCP endpoint, LLM gateway reachability, and prints a clear report.
• Better defaults for common environments. The install script handles a lot, but the matrix of "Coolify / bare VPS / Synology / home server behind Tailscale" is wider than we test.
• Backup and restore runbooks. The data is in Postgres; pg_dump works. But "works" and "tested, documented, and recoverable from" are different.

The bar: the change has to make self-hosting easier for someone who is not you. If it only helps people who already run Postgres in production, it's not the gap we're trying to close.

What we don't need right now

A few things come up a lot that aren't the bottleneck:

• A new vector database. pgvector is the choice. If you want to argue it, please bring benchmarks against a realistic memory workload, not a billion-vector benchmark.
• A second storage engine. Same answer — Postgres + AGE is the storage layer.
• A plugin system. The MCP surface is the extension point. We'd rather have more MCP clients than an internal plugin API.

If you're excited about one of these, the honest answer is "not yet," and we'd rather say so than have you spend a weekend on a PR that won't land.

How to start

• Read the repo map and the architecture overview before writing code. The codebase has a deliberate structure; a PR that doesn't fit it costs more review time than it saves.
• Open an issue before opening a big PR. For docs and small fixes, just open the PR.
• For evals and i18n, the work is substantial — talk to us first so we don't duplicate effort.
• The product is Apache 2.0. Contributions land under the same license.

Why this matters

Open source memory infrastructure only works if it's actually open — not just license-open, but contribution-open. The areas above are real gaps. If one of them is the kind of thing you enjoy, come find us. And if you'd rather just use the product and let someone else do the contributing, that's fine too — start on managed and the open-source work funds itself.