Components

Three pieces of Liminis are published on their own. All MIT, all independent of the application and of each other.

Liminis Context Graph

Rust · MIT · source · documentation

A local-first context graph engine: one binary that turns a stream of text into a queryable graph of entities, relationships, and episodes. Property graph storage, HNSW vector indices, and full-text search live together in a single embedded database, so there is no database server, no separate vector store, and no search cluster — one process, and files under your workspace.

The write-ahead log is the source of truth, and it is plain JSONL. Every mutation is appended to .lcg/wal/ before it touches the database; the database is a derived index, and deleting it costs you nothing but the time to rebuild. Each graph owns its own WAL stream, which makes a single graph independently replayable, independently disposable, and — because a stream is just a directory of JSON lines — versionable with git and replayable somewhere else.

Embedding and inference are reached through narrow adapters over the OpenAI-compatible API shapes, out of process. Embedding runs fully local on macOS out of the box.

It speaks JSON-RPC over a Unix socket, or runs as a native Model Context Protocol server over stdio — which points any MCP client straight at the graph with no application in between.

Liminis Editor

TypeScript · MIT · documentation · demo · source · npm

pnpm add @liminis/editor

A Lexical-based markdown WYSIWYG editor that round-trips through mdast. Tables, task lists, footnotes, definition lists, callouts, toggles, code blocks with syntax highlighting, images, LaTeX, Mermaid and C4 diagrams, YAML frontmatter, and wiki-links.

The markdown pipeline — parseMarkdown, stringifyMarkdown, and the mdast ↔ Lexical mappers — is usable with no editor mounted, which makes it as much a markdown library as an editing surface.

It also carries an annotation mechanism: range-anchored markers over document text that survive edits, configured per kind. Comments and corrections are not separate features but two configurations of one mechanism, and it is entirely opt-in — configure no kinds and none of it loads.

Every service the editor needs from its environment is an injected function with a safe default, so it renders in a host that supplies nothing at all. That seam is why it can sit in an Electron app, a browser app, or anything else that can pass messages.

Liminis Diagrams

TypeScript · MIT · documentation · demo · source · npm

pnpm add @liminis/diagrams

C4 architecture diagrams for JavaScript: parse C4-PlantUML macro syntax, lay it out with dagre, render to SVG, with optional drag-to-reposition editing.

Most C4 tooling in this space either round-trips through a PlantUML server or speaks a Mermaid dialect. This hands back the parsed syntax tree and the computed layout as data, which is what you need in order to build tooling on top rather than only emit a picture.

Three entry points. /core parses and lays out with no React involved and @dagrejs/dagre as its only dependency, so it runs in a CLI or a CI job. /react adds the renderer and dragging. /server turns source into SVG in a single call.

The interactive renderer is controlled — positions in, changes back out — so the host decides how they are stored. The editor keeps them in the code fence's own meta string, which leaves a hand-arranged diagram sitting in plain, diffable text.

Its documentation renders itself with the library: the diagrams on those pages are not images but live instances of the renderer, drawn in the reader's browser from C4 source held in the page's own markdown — and on the playground, editable in place, redrawing as you type.

It is the newest of the three, and moving quickly.