Logseq Meetup #2

Logseq’s refactor is reshaping the app around a smaller “logical core” and a plugin-driven architecture—moving file I/O and most string/character processing out of the center so new storage backends and features can be added without rewriting the engine. The immediate payoff is a simpler, more testable system: hundreds of lines were removed from the core, file corruption issues were addressed, and undo/redo was rebuilt with a focus on stability.

Under the new design, writing and reading file content shifts into plugins, leaving the logical core to concentrate on core operations and data flow. The team also introduces a clearer separation of responsibilities: the outliner—the critical component inside the logical core—gets its ordering and byte/string calculations streamlined, while civilization logic and block-related processing move into plugins. That modularity is meant to unlock multiple persistent storage options (for example, markdown files, org-mode files, sci-doc files, or sqlite and other backends) simply by swapping in different “civilization” adapters.

A key structural change is how Logseq models documents. The logical document is treated as a tree, with relationships represented through node identifiers such as id, parent id, and left id. In this model, operations on the tree become simpler, and the system can better manage block relationships. The refactor also changes how pages map to storage: a “page” becomes a special block type rather than a separate file in the same way as before. The whole graph is described as a large tree of logs, where pages act as roots and blocks live beneath them.

To bridge the outliner and plugins, the team adds a middle layer called “hooks.” Hooks sit between the outliner and plugin system, allowing plugins to plug into the lifecycle of outliner operations—supporting use cases like wikis and custom input/output transformations. The goal is to let plugins connect to arbitrary persistent stores, not just markdown-based workflows.

Alongside the architectural refactor, the meetup demonstrates a prototype plugin system in the desktop app. Developers enable it via a developer mode and a plugin entry in the toolbar. The plugin principles emphasized are security/privacy (plugins run in isolated environments such as sandboxed contexts like iframes or web workers) and developer friendliness. A set of sample plugins illustrates what’s already possible: a “hello world” message plugin, a theme/sim plugin with persistent light/dark switching, a community calendar plugin that queries journal data through a plugin API, editor-focused plugins for font customization, a slash-command plugin that currently routes commands through a handler with APIs still under development, and a page/block mapping plugin that displays block levels.

Q&A sharpened timelines and tradeoffs. A refactored desktop testing version is expected in about a week, with remaining plugin APIs and documentation potentially taking around a month. Mobile is on the roadmap but tied to encrypted storage and future real-time collaboration, with no firm date. Undo/redo is acknowledged as tested mainly within Logseq itself, with plans for broader robustness checks. Additional roadmap items include publishing improvements (exporting static pages), faster graph loading for large imports, and UX refinements like sidebar/contents navigation—some of which could be handled via plugins.

Overall, the meetup frames the refactor as a foundation for stability and extensibility: a smaller core, clearer data modeling, and a plugin ecosystem designed to support new storage, UI behaviors, and integrations without destabilizing the engine.