Understanding the proper way to handle attachements ("assets")

Honestly, I don’t even think any user of Logseq should be thinking about “how to structure their assets”.

While it is ok for Logseq to have a folder where you put the files that have no other home, everyone already has tens of thousands of files on their disks, and users can’t be expected to put everything into some new structure Logseq likes.

Many other programs also made this mistake, which makes it impossible to interface with other programs that also want to own all of your data.

Take for example Zotero, they have a good case for having their assets all in a single storage folder. Unfortunately Logseq can’t have relative paths to these files, so they either have to be duplicated, or use absolute paths, which is too fragile:

Similarly the widely used e-book management program Calibre does not permit linking to outside files at all, which makes it close to impossible to annotate Calibre books in Logseq.

In my opinion, Logseq should re-think their asset strategy and try to become as non-intrusive as possible and seamlessly fit into existing OS folder structures.

Logseq should not only do relative paths by default, but there should be a way to change and fix those paths should a user decide to move their external folders around.

6 Likes