Мечтают ли папки с заметками об отдельном бэкенде? От ресерча к MVP

Привет, Хабр. Несколько месяцев назад я вышел ближе к ночи в магазин и, проходя мимо стойки с яблоками, придумал рабочую мысль, которую, как обычно, скинул себе в Telegram. Дома меня ждал знакомый ритуал: включить ноут, открыть Telegram, скопировать текст, открыть Obsidian, найти нужную заметку с идеями и только после этого вставить мысль туда, где она и должна была оказаться изначально. Меня в тот момент зацепили не сами действия, а их архитектурная странность. Формально мои заметки лежали в обычной локальной папке и принадлежали мне. Практически же доступ к ним был завязан на конкретный десктопный клиент, плагины, sync и костыли. Попробуйте, например, нормально достучаться до своей локальной базы заметок с телефона или прикрутить к ней простую автоматизацию и быстро обнаружите БОЛЬ. Именно тогда у меня появился не ответ, а вопрос: это моя частная боль или уже ставший привычным сценарий у других людей, которые уже ведут большие vault'ы в Obsidian, Logseq, Zim и других PKMS? И если проблема реальна, то чего им на самом деле не хватает — стабильной синхронизации, нормального плагина, ещё одного клиента... или отдельного серверного слоя? Этот текст — не история в духе «смотрите, я сделал notes‑as‑a-service». Хотя соблазн подать его именно так есть, говорить об этом пока рано. Это дискавери о том, как из личной боли, ресерча и создания MVP у меня сложилась гипотеза, что части пользователей markdown‑заметок нужен не новый редактор и не мощные плагины, а бэкенд поверх уже существующей папки с заметками.

https://habr.com/ru/articles/1012030/

#product_discovery #mvp #obsidian #logseq #pkm #pkms #markdown #rest_api #автоматизация #selfhosted

Getting pretty darn close in spite of distraction. A few obvious things to note:

I'm focusing on loading pages via #Logseq HTTP API and processing those pages' contents. Not thinking much about style. Stuffing everything into the #Nanoc tutorial starter site for a moment.

I'm on the Linux machine now, and Logseq's reading of events is everything started with the timestamps of the files on disk rather than Git history. *(sigh)*

That number next to the title is Logseq's row ID for the page.

Has anybody ever written a conversion tool from the #orgmode syntax by #logseq to a cleaner version of #orgmode syntax for Emacs?

Background: logseq has a unique interpretation of the #orgdown syntax as each element is also a heading on its own (in order to allow element references):
https://karl-voit.at/2024/01/28/logseq-from-org-pov/

I'm happy to lose element references if they are replaced by "page references" instead somehow.

Die Migration von Logseq zurück zu Vimwiki ist nebenbei ein guter Anlass, das Gesammelte mal wieder durchzuschauen und auszumisten.

#Logseq #Vimwiki

Zeit für was Altes

Meine Notizen, Knowledge Management etc. habe ich nun schon einige Zeit mit LogSeq erledigt und bin bisher recht zufrieden damit. Aber angesichts solcher Entwicklungen https://social.tchncs.de/@miXsed/116084929586497036 erwäge ich nun wieder einmal zu wechseln. Datenbank und Sync gehen mir gegen den Strich, brauche und will ich nicht. Closed Source schon gleich gar nicht. Auch nicht irgendwann! Alle Daten bei mir und NUR da!

Nun schaue ich mir also erneut alles an, was man aktuell zu VimWiki findet, denn das habe ich vor längerer Zeit auch schon genutzt und war durchaus nicht unzufrieden.

Termine und Aufgaben sind eh viel weniger als früher. Die hatte ich zwar auch in LogSeq, aber da genügt mir die simple Kaleder-App Orage (weil XFCE) völlig.

#LogSeq #VimWiki