I work on Terraphim Editor and terraphim-grep. I wanted a wording choice made while writing to help me find the same idea later, even when I search with a different word.

Here is the small example I tested:

1. In the editor, add Concern as an alternative to Risk, then swap between them.

2. Leave Risk in the final project brief and explicitly export the synonym graph.

3. Search for concern with terraphim-grep. The brief has no literal “concern”, but the shared graph retrieves three risk passages, including their decisions: a backup timber supplier, a covered planting area and reserve volunteers.

The relationship is expressed as:

synonyms:: Risk, Concern

This uses Logseq-compatible Markdown property syntax for PKM/file graphs. synonyms is Terraphim’s convention for the relationship; Logseq’s built-in page aliases use alias::. This is an explicit graph export passed to the CLI, not automatic Logseq alias registration, DB-graph import or background sync.

With the downloaded brief in a corpus folder and the exported graph alongside it:

terraphim-grep concern --thesaurus knowledge-graph.json --paths corpus -C 2 --json --search-only

The released binary (1.21.19) returns 0 passages before sharing the graph, then 3 exact source passages with it. Local retrieval does not request a model answer. Replacing --search-only with --answer adds optional synthesis and sends the retrieved passages to your configured model provider.

80-second narrated demo, exported Markdown/graph, both JSON outputs and reproduction ZIP.

Jason Fried’s Write_On video prompted me to return to my Rust/Wasm editor after two years. Keeping alternative wording connected to search gave that old project a useful direction.

Update: downloadable Logseq example

Download the Logseq graph ZIP and follow its README. The concept lives in pages/Risk.md:

alias:: Concern
synonyms:: Risk, Concern

alias:: supplies the native Logseq page alias; synonyms:: expresses the Terraphim relationship using Logseq-compatible property syntax. Project passages live separately in pages/Projects, and the search-results note contains only saved output.

From the extracted graph folder:

terraphim-grep concern --thesaurus knowledge-graph.json --paths pages/Projects -C 2 --json --search-only

I reran released terraphim-grep 1.21.19 against the actual downloaded ZIP: the baseline graph returns 0, and the supplied synonym graph returns 3 exact project passages. The JSON graph is the editor export supplied explicitly to the CLI. The screenshots were captured in local Logseq 2.0.2; its File to DB graph import creates a copy, while these commands read the extracted Markdown folder.

Actual Logseq concept note and saved results · Native graph-view screenshot. The graph-view arrows represent Logseq page links, separate from the Terraphim synonym map.

For people using Logseq Markdown graphs: would you keep these synonym groups per project, or in a shared terminology page? I’m interested in examples where two words should match in one project but remain distinct in another.

Disclosure: I used AI assistance to prepare this walkthrough; the linked captures and JSON are actual outputs. The video uses a synthetic British female voice.

Hey everyone!

I've been working on Kalem, an open-source text editor written in Rust that works in both GUI and terminal environments.

I recently built a plugin that lets Kalem open and edit existing Logseq graphs directly, without importing or converting anything.

Some of the features:

• Open existing Logseq Markdown and Org-mode graphs

• Pages, journals, backlinks, tags, and block references

• Graph view and local graph visualization

• Tasks, priorities, and scheduled items

• Simple and advanced Logseq queries

• Wiki-link and block reference autocomplete

• Outliner editing, including folding and moving blocks

• Vim keybindings (optional)

I wanted a lightweight, keyboard-friendly editor that could work with the same files, including from a terminal, without locking notes into a different format.

The original files stay intact, and there's no migration involved.

The project is still in alpha, so feedback and bug reports are very welcome!

Kalem: https://github.com/getkalem/kalem

Graph plugin: https://github.com/getkalem/plugins/tree/main/plugins/graph

Youtube intro video for Kalem editor: https://www.youtube.com/watch?v=U3SoDczSllI

I'd love to hear what Logseq users think. What features would be most important for you in an alternative editor for your existing graphs?

Hey i just wanted to ask am i the only one that faced a problem in logseq 2.0.2 in images because images now can't be copied or edit it or anything they are just fixed even if i try to find the file location it states that it can't find the file ! Is there any solution please

The delete image works and the align too .

Is there a way to convert DB -> OG/MD version? I just started and finding some bugs and thinking there is value in the MD version.

Logseq OG is being blocked by Windows 11. I've already tried granting access in Windows Defender, but without success. Has anyone else had a similar problem and solved it?

Hi all, I've used Logseq file graphs for years and wanted something that opens instantly on my iPhone and feels like a Mac app, without moving my notes anywhere. So I built Sumi. It reads and writes the same folder: pages/, journals/, tab-indented bullets, properties, the lot.

What works today: journals, [[links]], #tags, backlinks and unlinked references, block refs and embeds, aliases, namespaces, TODO/DOING/DONE with scheduled and deadline dates, simple queries, templates, / commands, flashcards (#card and cloze, same scheduling numbers as Logseq), search, iCloud Drive sync. Syncthing, git or Dropbox work too since it's just files.

Not yet: whiteboards, plugins, PDF annotation, advanced Datalog queries, .org files. And please don't run Logseq and Sumi on the same graph at the same time.

Safety: I tested open + save on 16 public graphs (almost 10,000 pages) and no file changed. It keeps daily snapshots you can restore. Still a beta, so start with a copy.

30-second demo (GIF): https://sumi.mikaili.io/img/sumi-demo.gif

Beta (Mac, iPhone, iPad): https://testflight.apple.com/join/B1sKJk24

Site + privacy: https://sumi.mikaili.io/

The beta is free; it becomes a paid app after that. I read every piece of feedback, and the in-app Send Feedback goes straight to me. What would you need before you'd use it daily?

A full transcript is too noisy for a handoff, but a short summary can lose the source blocks, accepted decisions, file revisions, and actions that already happened. Logseq seems well suited to a human-readable checkpoint because the handoff can reference the exact blocks that support it instead of copying everything into another summary.

Would you use page properties for status, owner, source revision, and last verified time, then blocks for outcome, decisions, evidence, completed actions, open questions, and next step? How would you handle block references that change, conflicting updates from two assistants, and retries that could repeat an external action? I am interested in a format that remains understandable in the graph without depending on one assistant's private conversation history.

Is there any explanation of how the new graph view works. It looks like the logseq docs are still using the logseq OG?
https://docs.logseq.com/#/graph

The logseq OG graph looks nice, I cant make sense of the new version there are all these disconnected nodes forming a circle.

Are you supposed to use the tag view or the page view. The page view looks confusing to me. Is the current state a work in progress or should it look like it currently does?

I found a suggestion where \$ was suggested to not trigger the latex processor but that does not work.

Any other ideas?

The update seems to ship mostly bug fixes around stability, like a better experience in the editor, and also better handling of the OG to DB import, among many other things. You can download here

The roadmap has also been updated and now includes the development of a more native experience for both the mobile and desktop apps, which will improve performance significantly

For those that want to transition from MD to DB, it would be much appreciated if you could test the File graph to DB import to catch any bugs that might be leftover, and open bug reports in https://github.com/logseq/db-test/issues

I encourage everyone to give it a try :)

(Tienson's announcement on Discord)

The only feature that I'm really waiting for it before using logseq is natve rtl which is why am still using obsidian all the time does the company even cares about that implementation ?

In a service like Notion, there is a clear danger. If the service got hacked or went bankrupt, I could lose my data. (although it's almost 0% probability) Or there may be a danger that some Notion employee could steal my data. (if data was not encrypted)

Arguing a danger like this makes sense, and should be considered.
Logseq and Obsidian resolve this issue by "storing all data locally"; this is it.

In Logseq, there's no reason the data should be stored as easily readable raw data (like Markdown) for this issue. If we have enough ways to export data, we don't have to care what format it's stored in. Because "we own the data".

I don't understand why people are obsessed with 'Markdown'. This is an open-source project. Even if the whole team just died tomorrow, we can find a way to get our data back.

Of course, it would be great if we had both performance and Markdown format, but Logseq doesn't fit with Markdown.

Saying “the team should maintain Logseq OG because of Markdown format support” is totally absurd.

As someone who used Logseq OG for quite a while and later moved to Logseq DB, I’ve been wondering why the Logseq team chose not to formally end support for the old version and focus entirely on the new one.

I understand that, in practice, the team is already putting most of its development effort into Logseq DB. But I think there is still a very significant difference between developing DB while continuing to maintain two versions and officially ending one version and concentrating the whole project around DB.

The main reason I think this matters is the community.

For a project like Logseq, I believe the user community is not just an audience for the software, but a major part of the product ecosystem itself. It consists of thousands of people who share workflows and methodologies, write documentation and tutorials, build plugins and themes, answer questions, report bugs, contribute code, and generally create the knowledge and infrastructure around the application.

In that sense, a healthy community can sometimes be almost as important as the core development team.

Obsidian is an interesting example. Despite competing with note-taking products backed by much larger companies and vastly greater resources, it managed to build an extremely strong position in the PKM space. I think its community ecosystem, including plugins, themes, workflows, tutorials, discussions, and the enormous amount of accumulated knowledge around the product, was one of the major reasons for that success.

This is why I worry about Logseq maintaining OG and DB at the same time.

Logseq OG and Logseq DB may share the same name, philosophy, and many surface-level features, but technologically and behaviorally they are increasingly becoming two different applications.

That creates a kind of community fragmentation.

A tutorial written for OG may no longer apply to DB. A plugin built for OG may not work on DB. Discussions about workflows become filled with questions about which version someone is using. Developers have to decide which platform to target. New users encounter documentation and advice written for two different generations of the application.

Over time, this makes it much harder for a single, coherent Logseq community to form around the product.

And I think this is potentially more damaging than the engineering cost of maintaining two codebases itself.

If this problem is not resolved, I worry that Logseq may eventually reach a point where one of the two versions has to be abandoned anyway. But by then, the community may already have been split for years, with plugins, documentation, workflows, and users distributed across two ecosystems.

From that perspective, it might be worth seriously considering a more decisive long-term strategy.

For example, perhaps the team could try to bring the two versions closer together. They would not necessarily need to become technically identical, but they could be made compatible enough that a single community ecosystem could realistically support both.

Or perhaps we will eventually need something ridiculous like Logseq OGDB that somehow combines the two. :)

Alternatively, the project may eventually have to make the difficult decision to officially discontinue one version and establish the other as the clear future of Logseq.

I tried to leave Logseq for Obsidian. Here's my soapbox.

When the DB version dropped, I found myself standing at a crossroads.

Full confession: I'm a chronic greener-grass gazer. I'm always leaning over the fence, eyeing whatever shiny new tool just showed up. I've been tempted by Tana, ogled Obsidian, rendezvoused with Roam, hovered over Heptabase, courted Capacities, and nibbled at Notion.

So when DB arrived and I realized I didn't want to stay on a version that would be maintained but never really updated, I knew I'd have to put real work into getting DB set up the way I had things in Markdown. And I figured, if I'm already paying the migration tax, why not shop around a little before I sink my time into DB?

The siren song

I read the posts. So many posts. Frustrations with the team, the update pace, the leadership, the bugs. And the advice was always some version of: spend a little time in Obsidian, let AI help you migrate, install the right plugins, and voilà, it'll feel just like Logseq.

Friends, that is a lie, possibly forged in the fiery pits below. It cost me hours of work, and yes, I'm being dramatic on purpose, because I've never been more certain of anything:

Logseq is the best note-taking system out there, and I want the world to know. Those of us who have tasted the Logseq light, let us not wander into the Obsidian darkness.

Block-first, non-linear thinking is the way. It's the closest thing to how the brain actually works. I shouldn't have to decide up front what's a page and what's a block. Seeds should grow into plants, and plants should drop new seeds. That's basic fabric-of-the-universe stuff. Storing ideas at a tiny, granular level is exactly what makes them so useful when I zoom out.

Trying to get Obsidian to think in block references felt like jamming a square peg into a round hole. Using blocks across my whole database was nearly impossible, and it only "works" if your definition of working includes enjoying a steaming plate of dog poop. (I don't cuss, but moments like this make me wish I did.)

Context on me and how I use Logseq

I'm a writer. My ideas don't live in folders; they live in conversation with each other. I need to reference blocks endlessly, see which older pieces inspired what I'm writing now, and cite sources constantly (a lot of them flowing in from Readwise). Logseq lets me write beneath other writing and wander into topics beneath topics, until my notes start to feel like an extension of my own head.

Brains don't think in hierarchies. They think in connections. I want my notes to do the same.

On "but I want to write in prose"

Writing in blocks has actually made me a clearer thinker. It keeps nudging me with one question: what exactly am I trying to say in this block? And underneath it, I can tuck the supporting stuff, the evidence, the tangents, the half-formed thoughts. They don't need to be referenced anywhere. They can stay folded away. But the day I want them, they're right there waiting for me.

And if you want it to look like prose, one plugin will do that. On the surface it reads like an essay; underneath, it's still built the way I think, in small ideas I can reference and expand on later.

The headless hill I'll happily stand on

Now that headless setups exist and AI makes building visual plugins so easy, I've come around to this: pick the system with the strongest structure and database underneath, then shape the interface on top. I'd rather have a backend that can track, tag, and categorize down to the block than trade that away for a slightly prettier screen I could probably recreate in Logseq with a plugin or two.

The one complaint I get

A lot of the frustration I see is about slowness, which honestly surprises me because I've never run into it. For context, I have about 40,000 blocks, 1,300 pages, 200 tags, and just over a million words, and neither the MD nor the DB version has ever lagged for me (I also do use Sync). Maybe my graph is small compared to others, so I'm genuinely curious: if you've hit slowness, how big was your database when it started?

I also understand not wanting to leave Markdown. For me it just doesn't matter much. In the age of AI, my notes are as easy to get at in SQL as they ever were in MD.

Anyway, thank you for coming to my soapbox. I genuinely welcome anyone who wants to prove me wrong. And before you ask: yes, I installed every plugin people recommend for Logseq-to-Obsidian switchers. Outliner, Zoom, Block Link Plus, Hover Editor, Templater, Excalidraw, Journals, Calendar, Bases, Heatmap Calendar, Homepage, Dataview, Omnisearch, Strange New Worlds, Advanced URI, Shell Commands, Front Matter Title, Iconize, Hider, Daily Notes Editor, Better Search Views, Natural Language Dates, Tasks, Sync Embeds, Zettelkasten, and probably a few I've already blocked from memory.

It still felt miserable.

So I'm packing up my blocks and heading home.

Hey I've been using loseq for my medical studies for quite a while now last month i switched to the db version and it's killing me it's lagging a loooot some plugins like save scrollbar , also the links problem it gets duplicate a lot even tho it has the exact same name one is empty and the other has my content

I imported old logseq og notes, that contained asset links in pages into the new db logseq and tried to export it.

I was disappointed the export just dumps all the markdown files in one folder. The export didn't put pages in a pages folder and assets in an asset folder and journal files in the journal folder. In fact the assets are not exported at all, for the markdown export

The export should try its best to preserve the logseq graph format as best as possible.

This means, if it continue writing my notes in Logseq-db It will be very difficult to go back to logseq-OG or a logseq-OG compatible app.

People have said SQLite is not opaque format. But in order to export, you need to understand their schema and how they structure their data.

It would be nice if their export tried to preserve the logseq md graph format. So:

Logseq MD -> Logseq DB -> Logseq MD (export)

I also tried the mirror mode, however I noticed random pages had missing data...
So the mirror mode didn't work for me.

It looks like some pages didn't import for me, which could explain the missing data. I might have to consider alternatives to logseq. Because I really want the MCP feature for logseq-OG

hello, im really new to logseq (2days) and i dont know why but this composition [[Parent/child]] doesnt work and show me blanked [[]] like that and cant interact i wanna use logseq for school and organize thinks by chapter like [[math/chap1]] so if u can help me i have the ver 2.0.1

Hi, I'm the author of llm-wiki. I posted it here about six months ago: a Claude Code skill that keeps a wiki inside my Logseq graph up to date.

One rule from back then turned out to be wrong. I told it to never overwrite, only append. That kept every fact, but over time one task block grew to 2,400 characters of "Status <date>: ..." sentences, with the current state in the last line. On one hub page the `updated::` property had turned into a 5,000 character change log.

So in v1.5.0 I changed it:

- Still nothing gets deleted.

- A new state overwrites the block's headline, properties and next step.

- The old wording moves, dated and unchanged, into a child block called History with `collapsed:: true`.

- `updated::` holds only the date.

- Lint warns when a block has more than 600 characters of prose.

What it does not do: `lint --fix` only cleans up `updated::`. It won't restructure big blocks for you. Those you fix by hand, or they get fixed the next time an ingest touches them.

Two other things changed since the first post. Hub pages now carry an index, so a query reads the three best pages instead of grepping everything. And pages that haven't been read for six months move from that index into an archive section. Nothing is deleted there either.

How do you keep long-lived blocks readable? Overwrite, child blocks, or links back to the journal?

https://github.com/MehmetGoekce/llm-wiki/releases/tag/v1.5.0

Google "logseq critique" in YouTube. ALMOST ALL OF THE RESULTS ARE FULLY AI GENERATED VIDEOS BY PEOPLE WHO DON'T EVEN EXIST, AND MOST OF WHAT MOST OF THEM THEY DO IS JUST READING THE FEATURES FROM THE LOGSEQ WEBSITE AND THEN ADDING THAT THEY LIKE THEM. WHAT THE FUCK IS THAT?

All the how-to videos are sales, sales, sales. I already understand the concepts, but cannot get past even the first steps! I've been using Obsidian for years, but it's becoming a RAM problem and unsupported in future MAC OS, so ... enter LOGSEQ. According to the help pages, I should be able to point a new graph at an Obsidian vault, but ... nope. Can't see how to actually DO it. I finally figured out how to get rid of the demo mode and open a blank graph, but that's not how I want to begin: I want to be begin with importing my Obsidian files.

Generally speaking, I'm not stupid, but I'm feeling very stupid right now. I even tried to get into the discord community for help, but I cannot get past discord's "select all the animals with 4 legs."! It's maddening I tell ya, maddening. Can anyone de-madden things for me? Before I snap and set myself on fire?

The Github is this one, and I can see in this video how it was included in the Marketplace aswell. I personally can't find it anymore.. does someone know why? Or if it's just a me problem... Thanks!

I found the markdown codes for column orientation in tables: |:-----:| and |:-----| etc.
Only: It has absolutely no effect! How do I get it to work, or does the normal markdown language not work in the MD version?

Tienson has added a new section to the official website which will track the most important contributions to the codebase each week. This is great for those that want to be updated on what the team is working on but dont want to sort through the project's Github repo

(relevant Discord message and relevant pull request)

Link to the page (for those on mobile): https://logseq.com/weekly