nimmo/nixos-config

Watch

Fork 0

Evaluate Logseq (DB version) as a Trilium replacement #81

New issue

Open

opened 2026-07-20 22:28:38 +01:00 by nimmo · 1 comment

nimmo commented

2026-07-20 22:28:38 +01:00

Owner

Goal

Investigate Logseq's database version as a
potential replacement for Trilium as the personal knowledge base / note store.

Why

Trilium currently serves as the local note store, but Logseq's DB edition
looks promising on the dimensions that matter most here. This is exploratory —
no commitment to migrate yet.

Must-haves (evaluation criteria)

Self-hostable sync infrastructure — I must be able to own and run any
synchronisation/backend infrastructure myself (no mandatory third-party
cloud). Confirm what the DB version ships for sync and whether it can be
self-hosted.
LLM / agent access — ideally an MCP server so it plugs directly into
the AI workflow (OpenCode / Paseo / agents). At minimum it needs an API
(HTTP/GraphQL/local file or DB access) that scripts or agents can talk to
programmatically to read and write notes.

Nice-to-have

Feasibility of exporting from Trilium and importing into Logseq. Not
critical for the decision, but worth a quick spike to gauge effort and note
fidelity (attributes, hierarchy, attachments).

Open questions

What does the DB version use under the hood (SQLite / Datascript / something
else) and does that change self-hosting or backup story vs Trilium's SQLite?
Is there an existing, maintained MCP server for Logseq, or would one need
building? What does the API surface actually expose?
How does sync compare to Trilium's built-in sync server in terms of
self-hosting simplicity?

Decision criteria

Adopt only if (1) sync can be fully self-hosted and (2) there is a credible
MCP/API path for agents. Migration of existing Trilium notes is a secondary
concern.

## Goal Investigate [Logseq's database version](https://github.com/logseq/logseq) as a potential replacement for Trilium as the personal knowledge base / note store. ## Why Trilium currently serves as the local note store, but Logseq's DB edition looks promising on the dimensions that matter most here. This is exploratory — no commitment to migrate yet. ## Must-haves (evaluation criteria) 1. **Self-hostable sync infrastructure** — I must be able to own and run any synchronisation/backend infrastructure myself (no mandatory third-party cloud). Confirm what the DB version ships for sync and whether it can be self-hosted. 2. **LLM / agent access** — ideally an **MCP server** so it plugs directly into the AI workflow (OpenCode / Paseo / agents). At minimum it needs an **API** (HTTP/GraphQL/local file or DB access) that scripts or agents can talk to programmatically to read and write notes. ## Nice-to-have - Feasibility of **exporting from Trilium and importing into Logseq**. Not critical for the decision, but worth a quick spike to gauge effort and note fidelity (attributes, hierarchy, attachments). ## Open questions - What does the DB version use under the hood (SQLite / Datascript / something else) and does that change self-hosting or backup story vs Trilium's SQLite? - Is there an existing, maintained MCP server for Logseq, or would one need building? What does the API surface actually expose? - How does sync compare to Trilium's built-in sync server in terms of self-hosting simplicity? ## Decision criteria Adopt only if (1) sync can be fully self-hosted and (2) there is a credible MCP/API path for agents. Migration of existing Trilium notes is a secondary concern.

nimmo added this to the Miscellaneous Ideas milestone

2026-07-20 22:28:38 +01:00

nimmo commented

2026-07-21 06:14:25 +01:00

Author

Owner

Research findings

I did an initial reconnaissance pass — here's what I found about the evaluation criteria.

MCP server situation ✅ (with caveat)

Two MCP servers exist:

dailydaniel/logseq-mcp (Python, PyPI mcp-server-logseq, 38★) — the serious one. Supports both stdio and Streamable HTTP transports, so it can run as a daemon like the current Trilium MCP. Has namespace-scoped writes, audit trail in the daily journal, and configurable verified Datalog queries. Caveat: README explicitly says it targets the file/Markdown version — "the newer DB version changed the underlying schema; some methods may behave differently there."
joelhooks/logseq-mcp-tools (TypeScript, 70★) — simpler, also talks to Logseq's local HTTP API. Less featureful, more of a POC.

Both talk to Logseq's local HTTP API (port 12315) — they don't have direct data-layer access. Need a running Logseq instance (desktop or headless) with the API enabled.

The Streamable HTTP support matters: with it, we can run the MCP on Lyra (or both Lyra + Vega) and proxy over Nebula like the current Trilium setup. If DB version breaks the MCP, building or forking a compatible one is the critical path.

Desktop app in nixpkgs ✅

logseq version 0.10.15 exists in nixpkgs. But: that's the classic file-based version. The DB version (2.0.1 beta) shipped July 13, 2026 and isn't in nixpkgs yet. Classic version is on Electron 27 (outdated/insecure — needs overriding per NixOS Wiki).

Self-hosted sync for DB version ✅ exists, with friction

Logseq 2.0 ships a deps/db-sync Node adapter that can be self-hosted. Docker wrapper at yshalsager/logseq-selfhost (56★, AGPL-3.0, active). Custom sync server URL support was merged in PR #12459.

Friction points:

Auth requires AWS Cognito for JWT tokens — no built-in alternative. This is the biggest self-hosting blocker if we want to avoid AWS dependency.
Building the sync server from source requires Java 21 + Node + Clojure toolchain
Still marked as beta
The self-hosted sync server was only recently made possible (PRs from early 2026)

What this means for the evaluation

The must-haves are partially satisfied:

✅ Self-hosted sync infra: yes, but requires Cognito (acceptable if we treat Cognito as infrastructure we own, or if an alternative emerges)
✅ MCP/API for agents: exists for file version, unknown for DB version — this is the single biggest open question

The nice-to-have (export path) and open questions are unchanged.

Recommended checklist additions

Test dailydaniel/logseq-mcp against Logseq 2.0 DB — spin up a DB graph, enable HTTP API, point the MCP at it, see what breaks.
Evaluate the Cognito requirement — is AWS Cognito acceptable for personal use (free tier covers 50K MAU)? Or can we replace it with something self-hosted (Keycloak, Zitadel, or a simple static token override)?
Check if Logseq 2.0 can be run headless (no GUI) for server-side MCP access — the CLI tool might fill this role.
Nixpkgs packaging: if the DB version isn't in nixpkgs, gauge the effort to add it (Electron app, Clojure build chain).

## Research findings I did an initial reconnaissance pass — here's what I found about the evaluation criteria. ### MCP server situation ✅ (with caveat) Two MCP servers exist: 1. **[dailydaniel/logseq-mcp](https://github.com/dailydaniel/logseq-mcp)** (Python, PyPI `mcp-server-logseq`, 38★) — the serious one. Supports both **stdio** and **Streamable HTTP** transports, so it can run as a daemon like the current Trilium MCP. Has namespace-scoped writes, audit trail in the daily journal, and configurable verified Datalog queries. **Caveat**: README explicitly says it targets the file/Markdown version — "the newer DB version changed the underlying schema; some methods may behave differently there." 2. **[joelhooks/logseq-mcp-tools](https://github.com/joelhooks/logseq-mcp-tools)** (TypeScript, 70★) — simpler, also talks to Logseq's local HTTP API. Less featureful, more of a POC. Both talk to Logseq's **local HTTP API** (port 12315) — they don't have direct data-layer access. Need a running Logseq instance (desktop or headless) with the API enabled. The Streamable HTTP support matters: with it, we can run the MCP on Lyra (or both Lyra + Vega) and proxy over Nebula like the current Trilium setup. If DB version breaks the MCP, **building or forking a compatible one is the critical path.** ### Desktop app in nixpkgs ✅ `logseq` version 0.10.15 exists in nixpkgs. **But**: that's the classic file-based version. The DB version (2.0.1 beta) shipped July 13, 2026 and isn't in nixpkgs yet. Classic version is on Electron 27 (outdated/insecure — needs overriding per NixOS Wiki). ### Self-hosted sync for DB version ✅ exists, with friction Logseq 2.0 ships a `deps/db-sync` Node adapter that can be self-hosted. Docker wrapper at [yshalsager/logseq-selfhost](https://github.com/yshalsager/logseq-selfhost) (56★, AGPL-3.0, active). Custom sync server URL support was merged in PR #12459. **Friction points:** - Auth requires **AWS Cognito** for JWT tokens — no built-in alternative. This is the biggest self-hosting blocker if we want to avoid AWS dependency. - Building the sync server from source requires Java 21 + Node + Clojure toolchain - Still marked as beta - The self-hosted sync server was only recently made possible (PRs from early 2026) ### What this means for the evaluation The **must-haves** are partially satisfied: - ✅ Self-hosted sync infra: **yes, but requires Cognito** (acceptable if we treat Cognito as infrastructure we own, or if an alternative emerges) - ✅ MCP/API for agents: **exists for file version, unknown for DB version** — this is the single biggest open question The **nice-to-have** (export path) and **open questions** are unchanged. ### Recommended checklist additions 1. **Test `dailydaniel/logseq-mcp` against Logseq 2.0 DB** — spin up a DB graph, enable HTTP API, point the MCP at it, see what breaks. 2. **Evaluate the Cognito requirement** — is AWS Cognito acceptable for personal use (free tier covers 50K MAU)? Or can we replace it with something self-hosted (Keycloak, Zitadel, or a simple static token override)? 3. **Check if Logseq 2.0 can be run headless** (no GUI) for server-side MCP access — the CLI tool might fill this role. 4. **Nixpkgs packaging**: if the DB version isn't in nixpkgs, gauge the effort to add it (Electron app, Clojure build chain).

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

nimmo/nixos-config#81

No description provided.

Rows
Columns