The demo is nice. I liked its paragraph-level autocompletions that help target a particular block. Though storing block ids in markdown content would come with the same editing brittleness as header references in Dendron. This made me think about how offline markdown notes apps promise readability and portability of notes. But all these new features like wiki links, block references and block embeds require nonstandard syntax. An expression like

((ref:[[my.note]]))

is awesome while using Dendron but take the app away and it's just some characters sequence in a text file. Same with any potential

^

-ids. Take the app away and any expectation of continuing to work fluidly with the same notes falls apart because links and lookups and embeds all turn into pumpkins. And they stay that way until you manage to translate all the nonstandard pieces into a format that another tool can digest. So some amount of data lock in occurs even in the "plain markdown files" camp 🙂 Thinking about all these markdown extensions has made me much more tolerant of a new app potentially saying "Yes, we choose to store data in a database to make way for advanced features. Here are our well documented export formats, here's how they preserve ids, links and embeds".