My problem is not really with #Logseq or other #PKM or #TfT apps but with the silos most apps are and how much effort it requires to build and maintain "bridges" between these silos i.e. the integrations everyone look for when evaluating a software solution.
Storing notes in a standard format like #Markdown is a step in the right direction but we need more standard protocols and formats and more OS-level integrations.
The OS should take care of stuff like contacts, calendar, indexing files etc and let applications transparently access them. This approach has been explored by #KDE for example with Kontact, Akonadi, Baloo and more.
I should be able for example to login into Mastodon from my system settings and 1) receive native notifications 2) being able to share a note or a image to Mastodon without opening a full client 3) found my bookmarked toots in my PKM app of choice 4) see my followed and following accounts in an ad-hoc category in my contacts and so on.
Too much work is required now, like "in which service did I save that thing?" because we have no unified search (well again KDE's Krunner does its best with this concept) or again "where can I contact that person? In which format the resource must be for that platfom?"
From this perspective projects promoting themselves as "Everything OS" while just being the n-th low-code platform like #Tana are laughable.
@post I have a preference for markdown format as the base storage of information, but also see that this doesn’t allow for a bunch of@other things. Something like OPML I think does allow for more transparency and transport between silos.
I see what you mean but let me split the matter in two and start from the latter:
Communication between apps/system should use structured formats as always but I'd like if we could all agree that at least fields containing text would use Markdown syntax for bold, italics etc.
On storing structured data in Markdown, #Logseq does it by using Markdown indented lists (to define hierarchies) and "properties" for each element with the syntax `key:: value`. To my knowledge everything can be stored with it but I see this as a nice option to have, while the first part is the important one.
@post re part two. I’d see this as a must have not a nice to have.
Not stuck on the syntax of `key:: value` But it is easy to type and maintain in plain text. Have seen anything I feel is a viable alternative. So quite happy with it.
But I feel we do NEED a way to give extra information to the system (app) we use to play with the data.
@post absolutely 👍