Block based concepts

[SteOtt]

Hi,
I'm currently a logseq user but I'm looking for alternatives and I found this project and the features really impressed me.

I do unterstand that trilium is note based and I've played around a few days with this app.

Unfortunately I've found out that I can't migrate my logseq database to trilium without losing most of the context in my notes. This comes from the way I usually take notes: Normally I write only in the daily journal and link blocks to other notes that mostly don't have any content. The only purpose of these notes is to show me the blocks that link to this note (backlinks). Now if I see in the backlinks the whole note (which can be quite long sometimes) and not the block this is confusing. In addition I've added attributes to blocks and queried this block later to do some math with the attributes.

I've seen that you have introduced the collapsible block element in the editor which has already the "block" in the name.
My idea would be to expand the functionality of this element to support a block based workflow:

• If there's a link to a note in the summary then show only the block in the backlinks of the linked note
• Support the block element in the search function
• Allow the block element to carry attributes so that you can use it with the search

[BeatLink]

Well there are may ways to skin that cat. You can add anchors where you want and link to them from other notes. You can also treat each note as a block, work primarily from the sidebar and make really granular nested notes. The cloning system is great for that and trilium can happily support a db with hundreds of thousands of notes. Thats what i actually do. A lot of my notes have no or very little actual content. Its context is from where its cloned in the tree, its title and what attributes it has

[SteOtt]

Hi BeatLink of course there are a lot of possibilities to organize notes amd I'm sure Trilium will fit my needs. Nevertheless I have a few years notes otherwise organized and I'd like to carry it over. But thanks for explaining me how you organize your notes.

[BeatLink]

It would be nice though if headings were given an automatic built in anchor and could be made collapsible, same with the collapsible bullet points

[eliandoran]

@SteOtt, maybe you could create a sample Logseq database that I could try to import in Trilium to better understand what the issues are.

[eliandoran]

@SteOtt , nice sample!
I will have a look to better understand the structure, maybe we can even make a dedicated importer for it like we did for Obsidian.

[eliandoran]

@SteOtt , I've had a look at the sample, it's pretty interesting.

What would be your expectation regarding the structure, as you would see it for Trilium? The Trilium way would be to convert the journal to day notes, but the bullets would turn into sub-notes. This probably goes against your expectation to use collapsible blocks instead <summary>, but it does enable attributes such as distance to exist, which in turn allows the jogging page to display a table with the items.

Regarding your original ideas:

My idea would be to expand the functionality of this element to support a block based workflow:
If there's a link to a note in the summary then show only the block in the backlinks of the linked note

This would be genuinely OK to do, we've been wanting to improve the display of the backlinks. Not sure if the collapsible block is necessarily the best candidate here since you can as well just display only the bullet and make use of collapsible bullets instead.

Support the block element in the search function

This is an interesting topic, could you describe more how the search function would support the block element? Is it simply about changing the inline snippet to only display the matched block, or is it about treating collapsible blocks as subnotes (which would probably be extremely complex to implement).

Allow the block element to carry attributes so that you can use it with the search

I believe this one has been requested before and it would be the largest change, since attributes currently only exist at note level. It would need quite significant rewiring to support it at block/inline level. Unless there is significant demand for it, I'm not sure we can implement it just yet.

One more interesting aspect you should be aware of is Include notes which can also render as a collapsible block. Not sure if it fits your use, but it bridges somehow the gap between displaying the content of a subnote inside another note, without breaking the philosophy of Trilium where everything is a note (not a block).

--

I'm also curious if you'd like to share, what are the reasons you are looking for an alternative to Logseq?

[rom1dep]

@SteOtt I believe I have what would qualify as a pretty similar workflow to yours:

• I log stuff on a journal. Day notes are, effectively, just normal notes collected together, and rendered in a manner that makes use of certain note attributes (in this case, the #dateNote attribute value).
• Those day notes contain a bunch of paragraphs (which are analogous to your blocks) and references to other notes (you can insert those by pressing @ and there come your backlinks)
• Because you generally want your referred notes to be typed (e.g. "Projects", "People", "Runs", …), and all notes of a certain type to share identical properties (e.g. "Client", "First Name", "Date of Birth", "Running distance", …, or a certain icon and color), you can leverage templates (just like in logseq), or use the fact that notes can be laid out in one or multiple hierarchies, and attributes passed down through it.
• Those list of "Projects", "People", "Runs", … can then be rendered as collections of their own, and displayed in a grid (convenient for bulk editing), on a kanban (good for tasks or projects monitoring), on a map (to keep track of the places you went to, or paths you ran, since you an import GPS traces there too), etc. This is essentially leveraging the "note as data" paradigm and "database" use-cases (having notes as an analogous of rows in a database)
• Once you've done all the above, you've built for yourself a nice graph of notes, that you then want to query like you did (e.g. which days did I run more than 5km), a little known feature is that you can render search results as a notes tree and then as a collection, i.e. you can have "views" over your databases (e.g. "show me in a list my contacts living in a certain country", "show in a kanban the list of active projects grouped by customer", etc)

in all, if you can take some distance with the outliner reflexes, settle on the note as the practical "unit of content", use references, and then learn attributes management, you'll be soon-enough back on your feet.

[SteOtt]

Hi there,

a lot of stuff to think about...

Maybe I start with the last question (why I'm looking for alternatives to logseq):
The main reason is that the devs are working for over 2 years now on a rework of the core. Moving from a markdown-file based data storage to a database storage and. I see that this could increase performance vastly and it was often requested. However this also meant almost no bug fixing for the old version and no new features. Last month the database version was released and it didn't convince me. First of all I couldn't see any performance improvements (I didn't have a problem with it anyway), secondly features that I use like presentation mode or Excalidraw-drawings were removed and third some concepts were changed in a non intuitive way. Last but not least the change to a database made the synchronization between devices a lot more complex.
I still use the old markdown version and I'm quite happy with it but the above made me to look for alternatives.

What would I expect regarding the structure?
Well that's not an easy question. If the bullets turn into subnotes I would end up having a lot of notes with the same name (e.g. Private/Sport/Jogging) where in Logseq the "/" character is hierarchy seqarator which aggregates the backlinks. So when I'm on the page "Private/Sport" I see all blocks linking to all sub-Pages of Sport. I would lose this information. I think my dream would be if the hierarchy would translate into a nested notes structure, the daily notes are kept and the collapsible blocks would link to the structure and I could only see the blocks in the backlinks not the whole note.

I think it would be enough to just display the text snippet of the collapsible block in the search function.

I understand that including attributes to in a block is a big change and goes against the philosophy of everything is a note but I thought I could ask...

I've seen the included notes feature and I find it good. I'm just not sure how this could fit into my workflow.

@rom1dep
thanks for sharing your workflow with me.
If I understand you right you take your notes in the journal and link them to other notes? Do your journal notes contain the content or the notes you link to and how do you name your notes you link to then if they contain the content?
I see that you can use collections, but is there a way to sum up a tag in a collection?

It's a little confusing, but I try to understand.

BR
Stefan

[rom1dep]

Hi @SteOtt !

What would I expect regarding the structure?
Well that's not an easy question. If the bullets turn into subnotes I would end up having a lot of notes with the same name (e.g. Private/Sport/Jogging) where in Logseq the "/" character is hierarchy seqarator which aggregates the backlinks. So when I'm on the page "Private/Sport" I see all blocks linking to all sub-Pages of Sport.

To me that's a strong indicator that the unit of content (i.e. the Trilium note level) is the level at the last "/" or one just below, there's probably no practical benefit of having subnotes for every block/paragraph.

If I understand you right you take your notes in the journal and link them to other notes?

More like, I log my day in the journal, and by doing so, I pull references to other notes generally stored elsewhere as collections, hence establishing a link/backlink between the journal note and the reference. For instance:

Note path: Journal/2026/August/14
Note content: "Went to {Central Park} with {Emily}. We had {Tonkotsu Ramen} at {Shinjuku Ramen}"

everything within curly braces is a reference to a note, so when I have {Emily}'s note open, I can know from the backrefs dialog when, and then where we met.

The other thing is: you may easily have multiple journals with Trilium: one for your personal life events (notes are days or memorable events), one for work work (notes are meetings), one for sport (notes are workouts), etc.

Of course, I also have a bunch of other topical notes outside the journal (cooking recipes, tech writeups, lists of various things, …), but starting from the journal is generally is a good way to trigger the need to give structure to your database, think as collections, and build a habit of using templates and attributes.

Do your journal notes contain the content or the notes you link to and how do you name your notes you link to then if they contain the content?

If I need to write about a place e.g. {Central Park} and it doesn't already exist, I have to create a new note. It takes me to pop open a new tab, type "Places" to jump to the collection hosting all pre-existing places, and pressing "ctrl+p" to create a child note. By configuration (using templates), the new note will have all the structure and attributes expected from a "Place" note. I just type "Central Park", close the tab, back to the source note, press @ and enter, my reference to {Central Park} is inserted in that journal entry.

I see that you can use collections, but is there a way to sum up a tag in a collection?

What do you mean by "sum up"? also, there's no "tag" in Trilium, everything is an attribute (which may or may not have value).
If you want to do operations on attributes, you can easily script it, and eventually publish the outcome in a dashboard.

Hope that helps!