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

Привет.

Несколько месяцев назад я вышел ближе к ночи в магазин и, проходя мимо стойки с яблоками, придумал рабочую мысль, которую, как обычно, скинул себе в Telegram. Дома меня ждал знакомый ритуал: включить ноут, открыть Telegram, скопировать текст, открыть Obsidian, найти нужную заметку с идеями и только после этого вставить мысль туда, где она и должна была оказаться изначально.

Меня в тот момент зацепили не сами действия, а их архитектурная странность. Формально мои заметки лежали в обычной локальной папке и принадлежали мне. Практически же доступ к ним был завязан на конкретный десктопный клиент, плагины, sync и костыли. Попробуйте, например, нормально достучаться до своей локальной базы заметок с телефона или прикрутить к ней простую автоматизацию и быстро обнаружите БОЛЬ.

Именно тогда у меня появился не ответ, а вопрос: это моя частная боль или уже ставший привычным сценарий у других людей, которые уже ведут большие vault'ы в Obsidian, Logseq, Zim и других PKMS? И если проблема реальна, то чего им на самом деле не хватает - стабильной синхронизации, нормального плагина, ещё одного клиента... или отдельного серверного слоя?

Этот текст - не история в духе "смотрите, я сделал notes-as-a-service". Хотя соблазн подать его именно так есть, говорить об этом пока рано. Это дискавери о том, как из личной боли, ресерча и создания MVP у меня сложилась гипотеза, что части пользователей markdown-заметок нужен не новый редактор и не мощные плагины, а бэкенд поверх уже существующей папки с заметками.

Пара слов о позиции, из которой я это пишу. Я не разработчик по образованию, у меня филологический бэкграунд, но уже лет десять пользуюсь Linux и всё это время автоматизирую в быту всё, до чего дотягиваются руки, с помощью самописных bash- и Python-скриптов. За последний год я успел поработать “руководителем отдела разработки” - по большому счету разрабатывая продукты для начальства и переводя их задачи на человеческий язык для двух программистов и трёх нейросеток. Поэтому база знаний для меня - важная часть ежедневной рутины.

Что именно я хотел проверить

На старте мне было важно не «доказать рынок заметок вообще», а выбрать, какой класс решения стоит проверять первым.

Когда у тебя уже есть привычный Obsidian vault, очень легко не замечать, насколько он на самом деле заперт в своём интерфейсе. Да, файлы лежат локально. Да, они в markdown. Да, это вроде бы свобода. Но как только пытаешься выйти за пределы сценария «открыл десктопный клиент и руками что‑то написал», оказывается, что свобода там довольно условная.

При этом мне не хотелось сразу бежать и писать ТЗ для ИИ в духе: «сделай мне телеграм‑бота для папки Obsidian». Сначала хотелось понять, а нужно ли это вообще кому‑то или я один такой странный человек, который ночью у яблок внезапно упирается в проблемы архитектуры софта.

Поэтому тут сработал более узкий запрос: если у юзера уже есть живая база знаний — нужен ли ему способ полноценно работать с этой базой вне десктопного клиента? В браузере, на телефоне, используя внешний сервис или автоматизацию — и при этом не ломая воркфлоу и не используя костыльный оверинжиниринг?

По сути, на старте у меня было четыре конкурирующие гипотезы:

1. Людям нужен просто нормальный Obsidian Sync.

2. Людям нужен комбайн внутри текущего клиента.

3. Людям нужен ещё один клиент — например, более лёгкий.

4. Людям нужен хэдлесс бэкенд поверх уже существующей базы.

Как я проверял боль

Сначала я пошел на Реддит и штурмовал там несколько профильных сабреддитов, хотел понять, повторяется ли мой сценарий у других. И довольно быстро увидел: да, у юзеров есть желание упростить работу с заметками. Кому‑то нужен бот в Телеграм, кому‑то в XMPP или в Slack. А ещё нужен редактор, который можно открыть в браузере, а ещё нужно не платить за Obsidian Sync, а кто‑то просто хочет на телефоне нажать кнопку и сделать «хорошо»... Реддит не дал мне готового ответа, но убедил меня в том, что проблемы есть не только у меня.

Но отличается ли картина у наших соотечественников? Чтобы проверить, повторяется ли поведенческий паттерн, я выгрузил историю сообщений из крупного русскоязычного Telegram‑чата по Obsidian с октября по февраль и вручную перебрал их комментарии и отзывы. И вот лишь несколько цитат, описывающих типичные проблемы юзеров:

И даже такое:

К этому добавляется проблема оплаты: официальный Obsidian Sync (за $10 в месяц!) из России оплатить проблематично. А сторонние плагины для синхронизации, вроде Remotely Save, регулярно затирают свежие версии заметок устаревшими из облака.

Но дело не только в синхронизации. Люди мучаются с мобильными клиентами:

Стоит оговориться, это не академическое исследование, а простой ресерч пользовательского опыта. Я смотрел на уже активных пользователей, которые приходили в общий чат со своими жалобами. В общей сложности я просмотрел 6034 сообщения, отдельно выделил 1556 сообщений со сформулированной проблемой и разметил их по темам, которые собрал в более крупные группы:

1. Плагины и экосистема расширений: 413 сообщений (26.5%)
2. Dataview и автоматизация: 359 (23.1%)
3. Файлы, вложения, экспорт и импорт, медиа: 253 (16.3%)
4. Поиск, навигация, структура, ссылки: 147 (9.4%)
5. Синхронизация и работа между устройствами: 127 (8.2%)
6. Мобильный клиент: 123 (7.9%)
7. Кастомизация интерфейса: 75 (4.8%)
8. Производительность и стабильность: 59 (3.8%)

Собрал это в 3 кластера:

1. «Хочу превратить Obsidian в комбайн» (54.4%). Пользователи пытаются не просто писать заметки, а накатывать поверх них разные инструменты (плагины + bases/dataview + автоматизация + UI‑кастомизация = 847 сообщений). Это не разработчики, а обычные юзеры, которые хотят расширяемости.

2. «Хочу нормальный доступ к заметкам с разных устройств» (16.1%). Прямой запрос на независимость от десктопного клиента (синхронизация + мобильный клиент = 250 сообщений). Здесь и WebDAV, и Remotely Save, и краши на телефоне.

3. «Хочу работать с разными форматами и интеграциями» (16.3%). Вложения, тяжёлые файлы, PDF, Zotero (253 сообщения). Это уже про заметки как рабочий хаб.

Интересно было то, чего я почти не увидел, хотя ожидал. Люди мало обсуждают Zettelkasten, Graph View и прочую методологическую мишуру. В реальности их гораздо сильнее волнуют сугубо прикладные вещи: что сделать, чтобы не ломались плагины, нормально работало мобильное приложение, не конфликтовал Sync и можно было быстро собрать под себя нужный инструмент.

Эти проблемы дублируются и на форуме Obsidian, к которым добавляется еще одна, центральная и красноречивая (12.5 тысяч просмотров): отсутствие REST API.

"...вырубить старый вишнёвый сад..."

Здесь важно остановиться. На этом этапе главным было не перепутать две вещи: наличие боли и выбор решения. Ресерч показал повторяющийся паттерн: у части активных пользователей заметная боль связана с доступом к данным вне клиента, автоматизацией и ограничениями экосистемы. Но это еще не доказывало, что headless бэкенд - это решение их проблем. Может быть, всем просто нужен хороший плагин? Или несколько плагинов? Или адекватное мобильное приложение?

В этот момент я ещё не считал, что нашёл правильное решение. Максимум, к чему меня подвёл ресерч - это к гипотезе, что хэдлесс сервер стоит проверить раньше, чем новый клиент или набор плагинов. Иными словами, я попытался сузить часть решений, которые можно было бы проверить в первую очередь.

Чем дальше я копал, тем яснее видел одну вещь: пользователи снова и снова пытались не просто вылечить зависимость от какой-то определенной функции, но на более фундаментальном уровне - от самого факта, что "принадлежащие им" заметки живут только внутри десктопного клиента.

Если бы юзеры лишь массово жаловались на Obsidian Sync, что ж, можно было бы изучить Sync. Для мобильного клиента можно было бы сделать лёгкий клиент. Но в запросах регулярно повторялась одна мысль: пользователь хочет достучаться до данных извне, запускать автоматизации, подключать внешние сервисы, браузер, не всегда имея открытым свое заметочное приложение.

Свой первый JTBD я сформулировал так:

Когда у пользователя уже есть база заметок в Obsidian, Logseq, Zim, он хочет полноценно взаимодействовать с этой базой на другом сценарном уровне - используя мобильное приложение, дополнительные плагины, браузер, бота, синхронизацию, автоматизации. При этом не ломая существующий воркфлоу и не переезжая в другую систему.

Довольно быстро сформировалось и название проекта - Moonstone. Обсидиан - тяжелый, темный камень, а лунный камень - легкий переливающийся минерал.

Moonstone (если эта штука вообще нужна) - не для среднего пользователя с тридцатью заметками. Первый внятный сегмент здесь гораздо уже - это человек с уже живой базой знаний, у которого появилась потребность в трёх вещах - селф-хостинге, доступе к данным вне десктопного клиента и автоматизации через единый API.

Это, прежде всего, сторонник selfhosted сервисов, который хочет держать всё у себя и открывать свою базу из браузера. Или исследователь с папкой заметок, который хочет автоматизировать работу с ней одним API. Уже потом к ним примыкают пауэр юзеры Обсидиана и люди, которым хочется писать свои инструменты поверх заметок без мучений с Electron и npm build’ом.

И наоборот: чем дальше я разбирался, тем яснее видел, кому это, скорее всего, не нужно. Если у человека мало заметок, нет привычки поднимать свои сервисы, а существующий sync-сценарий его в целом устраивает, боли просто недостаточно, чтобы ради неё ставить отдельный сервер

Почему я не пошёл делать ещё один интерфейс

Когда я смотрел на реальные проблемы пользователей, я всё чаще упирался не в нехватку ещё одного интерфейса, а в нехватку отдельного слоя доступа и автоматизации. Если люди спотыкаются о сценарии вне десктопного клиента - браузер, боты, внешние сервисы, фоновые процессы - то проверять логичнее не новый редактор, а серверный слой поверх существующего vault.

Тогда же пришлось забраться обратно на Реддит, в Телеграм-чаты и на форум Обсидиан и задать себе новый вопрос: а почему бы не использовать те костыли, которым вполне успешно пользуются юзеры сегодня?

Syncthing решает только задачу доставки файлов. Он синхронизирует папку, но не понимает структуру заметок. Он не даёт API для тегов, поиска незакрытых задач, графа связей, совместного редактирования через вебсокеты или подписки на SSE, если файл изменился.

Плагины сами по себе часто бывают отличными. Но они заперты внутри клиента и привязаны к факту его работы. Закрыл Обсидиан, чтобы сэкономить память? Умерла автоматизация. Забыл открыть Обсидиан после включения компьютера? Автоматизация и не оживала.

Гитхуки хороши для разовых случаев, но это не платформа. Если попытаться на баше распарсить YAML фронтматтер и маркдаун-ссылки в тысяче файлов, чтобы просто поиграться с графом связей или собрать автоматизацию, может быть немного больно.

Существующие markdown-редакторы вроде vnote, apostrophe или Markor обычно воспринимают маркдаун как маркдаун. Они не понимают папку заметок как папку заметок со ссылками, тегами, вложениями и структурой.

И да, FastAPI-сервер поверх папки с файлами можно написать за вечер. Но как только вы дойдёте до нормализации тегов, поиска, сирот, конфликтов и консистентности, этот наколеночный скрипт разрастется до колоссальных размеров.

Собственно, в этом для меня и была главная развилка. У каждой боли есть частичный костыль, но все они решают отдельные симптомы, в то время как мне хотелось проверить, нужен ли людям именно устойчивый серверный сценарий, в котором база знаний живёт как сервис, а не как приложение.

Так появился он

Здесь я, возможно, уже вышел за границы MVP. Для проверки части гипотез хватило бы более узкого слоя: API на чтение и запись, браузерный доступ и один-два скрипта для автоматизации. Но мне было важно не только проверить пользу, но и собрать архитектуру, которая не развалится при первой же возможности.

Из этой логики родился продукт - не как попытка заменить Obsidian или Logseq, а как MVP для проверки одной узкой гипотезы: возможно ли превратить локальную папку с заметками в API, не нарушая воркфлоу и не заставляя пользователя пересаживаться в другую PKMS.

Здесь важно не спутать две вещи. Этот текст не про архитектуру ради архитектуры. Но и сделать вид, что всё решается простым FastAPI поверх папки с заметками, тоже было бы нечестно. Если совсем коротко: стоит отвязать данные от десктопного клиента и мы получаем не просто веб-доступ, а принципиально другой опыт.

Я взял за основу логику потрясающей программы Zim Wiki (олды пустят слезу ностальгии - древовидная структура была гениальна, а все модные функции из Обсидиана работали как часы еще при царе Горохе) и задал себе вопрос: что если вынести ядро работы с файлами в отдельный Python-демон?

Архитектура сервера построена на следующих принципах:

1. Программа на лету определяет формат папки (Obsidian, Logseq, Zim или просто папка с заметками). Она парсит файлы, нормализует теги, строит связи и метаданные. На выходе получается чистый JSON. При этом файлы на диске не ломаются. Если вы выключите сервер, ваш Obsidian продолжит работать с этой папкой как ни в чем не бывало.

2. Сейчас в программе больше 70 REST API эндпоинтов: GET /api/pages, PATCH /api/page/Idea.md, POST /api/search и так далее. Но важно здесь не само их число (большая часть мигрировала из логики Zim), а то, что база знаний вообще становится доступной как сервис.

3. Сервер слушает файловую систему (через watchdog: inotify/FSEvents). Как только файл меняется на диске (например, вы отредактировали его в Vim), сервер пушит событие всем подключенным клиентам через WebSockets или SSE в зависимости от юзкейса.

4. Помимо API, в систему встроен менеджер веб-апплетов и фоновых сервисов. Юзер может устанавливать небольшие приложения (HTML/JS/CSS) или Python-скрипты, которые будут работать поверх его хранилища, расширяя возможности сервера без необходимости менять ядро самой программы

Разработка заняла два месяца. Я спроектировал архитектуру, составил OpenAPI спецификации и выступил в роли техлида и продакта, а код писали Gemini/Claude и два разработчика. Разве что мне приходилось писать тесты на каждый чих (например, парсить Markdown оказалось сущим адом) и ловить баги. А потом читать код полночи и ругаться с нейросеткой: “Какие if/else на 500 строк, дурачина?" Но в итоге всех страданий получился очень легкий, асинхронный демон.

Что дискавери развернуло в самом продукте

Когда делаешь систему для работы с заметками, очень легко потеряться в фантазиях о графах, втором мозге и прочем методологическом маркетинге. К счастью, CustDev вдохнул реальности в этот продукт, а обкатка прототипа на себе, близких и коллегах показала, что от продукта это и не требуется.

Изначально я думал сделать бóльший акцент на графах, потому что в мире PKMS давно бытует мнение, будто это и есть их главная фишка. Но, как показал анализ Телеграм-чата, людям в целом хватает того, что уже есть. Больше 50% болей лежат в другом месте - в автоматизации и попытках собрать из Obsidian комбайн. Вопросы у людей на практике звучат не как "как мне элегантнее организовать граф заметок", а "как сделать бота в телеге, чтобы присылать туда фотки, чтобы они попадали в Inbox?" или "как автоматически собрать таски, чтобы потом обработать их через нейронку?" Вся романтика очень быстро разбивается о желание просто удобно пользоваться своей базой знаний.

Точно так же у меня менялось и понимание целевой аудитории. Сначала я думал, что основными пользователями будут пауэр юзеры Obsidian и Logseq. Но горячий отклик неожиданно пришёл в r/selfhosted: людям понравилась идея поднять свою папку заметок на домашнем сервере, пробросить её в веб через WireGuard и заходить в неё из любой точки мира. Там у поста было 54 апвоута и 39 комментариев.

Это, конечно, не доказательство успешности, перспективности и т.д., но это явный сигнал.

Поэтому приоритеты сместились: вместо сложной работы с web-editor и графами (что выглядело заманчиво, но размывало фокус) я обратил внимание на стабильность API и простоту разработки аплетов и Python-сервисов. Мне важно было сначала проверить более узкую гипотезу: нужен ли людям вообще сервер для существующей базы заметок.

Для себя я разделил сигналы на сигналы интереса и валидации. Интерес - это апвоуты, комментарии, звёзды и обсуждения. Они полезны, но сами по себе ничего не доказывают. Валидацией я считаю поведение: пользователь подключает существующий vault без миграции, делает первую полезную автоматизацию и возвращается к серверному сценарию повторно - уже не как к демо, а как к части повседневного воркфлоу.

Здесь появляется и метрика успеха, когда пользователь становится независим от открытого десктопного клиента.

Что это дает на практике

На практике это дало мне не просто доступ к заметкам из браузера, а более программируемый сценарий работы с базой. Вокруг этого я построил две сущности: апплеты и сервисы.

Апплеты

Для меня здесь важен не только комфорт разработки, но и низкий порог входа. Если для Obsidian-плагина нужен Electron, то для апплета достаточно HTML, JS и fetch к REST API.

Апплет - это просто папка с файлами index.html и manifest.json. Вы кидаете эту папку в директорию applets, и она мгновенно появляется в веб-интерфейсе сервера.

Вам нужен трекер привычек? Пишете или вайбкодите ванильный HTML + JS. Подключаете встроенные в пакет css и js либы. Сервер сам отдаст статику, сам разрулит CORS и сам пришлет SSE-событие, когда файл изменится.

Сервисы

Services - это изолированные Python-скрипты, которые крутятся в фоне.

По чату юзеров Obsidian было видно, что пользователи считают мобильную версию "обсидианом на минималках": долго грузится, плагины тупят, или не работают, или просят костылей. Поэтому в числе первых сервисов я сделал Telegram Bridge. Я просто хотел записывать инфу в нашу базу даже если находился в самых неудобных для работы местах, где обычно приходят самые умные мысли. Без открытого на ноуте Обсидиана. Теперь сервис слушает бота, скачивает фотки и создает заметки в Inbox. Чуть позже хочу допилить транскрипцию голосовых.

Пример сервиса на Python, который ищет заметки-"сироты":

import time, signal
from moonstone_sdk import MoonstoneAPI

api = MoonstoneAPI()
running = True
signal.signal(signal.SIGTERM, lambda sig, frame: globals().update(running=False))

while running:
    orphans = api.get("analysis/orphans").get("orphans", [])
    
    content = "# 🧹 Потерянные заметкиnnНа эти страницы нет ни одной ссылки из других заметок. Пора их разобрать!nn"
    for page in orphans:
        content += f"- [[{page['name']}]]n"
        
    api.save_page("System:Orphans", content)
    
    time.sleep(3600)

И тут всплыл неожиданный побочный эффект.

Это был не центральный тезис discovery, но оказался очень практичным следствием архитектуры: как только у заметок появился внятный REST API, с ними резко стало проще работать не только людям, но и LLM. И да, вы угадали, трекер привычек со скриншота выше я сгенерировал за 30 секунд в Gemini.

Для меня здесь важно, что апплеты и сервисы становятся способом снизить стоимость кастомизации. Вместо написания тяжеловесных Electron программ пользователь может проверить свою идею через HTML/JS или один Python-скрипт.

Юзкейс

Чтобы всё это не звучало слишком абстрактно, приведу сценарий, который хорошо показывает разницу.

Пользователь ведет рабочие заметки, встречи, фиксирует идеи и задачи в течение недели. В пятницу ему нужно собрать из всего этого один отчет и кинуть выжимку руководителю в Telegram. В обычном Obsidian для этого нужно иметь запущенный десктопный клиент, установить, настроить и научиться использовать тяжелые плагины (Dataview, Templater, опционально плагин для нейросети), вручную копировать текст и отправлять в Telegram, потому что Obsidian из коробки не умеет пушить данные наружу. Сценарий занимает 6-7 шагов.

С API это превращается в один шаг: поднятие сервиса, который работает в фоне. Так как база знаний стала сервисом с REST API, задача выполняется простейшим скриптом, пока сам пользователь вообще может быть не у компьютера:

1. Скрипт в 18.00 делает простой GET-запрос к API: GET /api/tags/meeting/pages и опрашивает все таски: GET /api/search?q=TODO

2. Скрипт собирает полученный JSON, форматирует его в Markdown, опционально обрабатывает в Gemini/Claude и создает новый файл: POST /api/page/Дайджесты/Неделя_42.md. Сервер сам подхватит файл, распарсит его и он мгновенно станет доступен во всех интерфейсах.

3. Этот же скрипт через Telegram API отправляет сообщение: "У тебя 5 открытых задач и 3 встречи. Ссылка на заметку: ..."

Это и есть тот момент, когда заметки становятся сервисом.

Первые юзеры

Пока что продукт тестировался в основном на мне самом, коллегах и нескольких близких людях. Это не валидированная выборка, скорее купирование персональных болей, но даже на этом уровне стало видно несколько сигналов:

1. Самый понятный и быстрый сценарий входа - не "веб-редактор" в целом, а конкретные штуки вроде Telegram Bridge и доступа к заметкам из браузера без поднятого десктопного клиента.

2. Ряду пользователей очень понравилась тайлинговая концепция воркспейсов - это напомнило им UI в Obsidian и сделало порог входа ниже.

3. Первые пользователи оценили простые автоматизации вокруг уже существующего vault’а, учитывая, что им не надо ничего никуда переносить и отказываться от привычного Obsidian.

Для меня это пока не подтверждение гипотезы, но позитивный маркер - пользователь подключил свою базу заметок без миграции, сделал первую автоматизацию через нейронку и продолжил использовать сервер без десктопного клиента три дня.

Потребление ресурсов

Если цель - держать базу знаний онлайн на слабом Raspberry Pi или дешевом VPS, разница очевидна (запущено на тестовом vault - 346 заметок и 44 изображения):

Где собака зарыта

Читатель резонно спросит: "Окей, просто повесить FastAPI поверх папки с маркдауном и всё. В чем проблема-то?"

Настоящая сложность заключалась не в создании пары методов для отдачи текста, а в проектировании API и в обилии этих самых эндпоинтов.

Зоопарк эндпоинтов

Сейчас в продукте больше 70 эндпоинтов. Когда работаешь с базой знаний, нужно закрыть большую часть вопросов: CRUD для страниц, поиск (включая полнотекстовый и со сниппетами), работу с тегами, графы связей, не забыть сирот, экспорт, работу со вложениями, а также системные эндпоинты для работы сервисов, сервера и предупреждения конфликтов (/api/_yield). То есть, обилие эндпоинтов - это палка о двух концах. С одной стороны это дает невероятную гибкость любому апплету или сервису - вам не надо парсить текст, т.к. все уже разложено по полочкам. С другой стороны на седьмом десятке эндпоинтов начинаешь натурально путаться в архитектуре. Продукт завязан на REST API - а из этого будто вытекает, что для каждой новой фичи надо сделать эндпоинт. В какой-то момент это стало тяжко.

Профили и парсинг

Вторая сложность - это парсинг маркдауна и организация структуры профилей. Обсидиан и Логсек, несмотря на визуальную схожесть, оказались двумя разными мирами. Чтобы не плодить спагетти-код из if/else, я ввел концепцию Профилей (BaseProfile, ObsidianProfile, LogseqProfile) и перетянул из Zim его ParseTree. При запуске сервер сканирует корень папки. Видит .obsidian - включает профиль Обсидиана. Видит logseq/config.edn- профиль Logseq.

Дальше любая заметка парсится и превращается в абстрактное дерево. И уже из этого дерева строятся графы связей и нормализуются теги. В результате API вообще "не знает", с каким форматом он работает. Один и тот же GET-запрос вернет абсолютно одинаковый JSON, независимо от того, в какой программе была создана заметка.

Консистентность

Если у нас есть индекс в памяти, как он не разъезжается с реальными файлами, если юзер параллельно открыл Obsidian или Vim и начал менять файлы там?

Сервер не парсит все файлы постоянно. Я использовал watchdog, который под капотом цепляется к нативным событиям ОС (inotify на Linux, FSEvents на macOS). Как только файл меняется на диске, демон точечно инвалидирует эту страницу в кеше, обновляет связи и мгновенно пушит событие page-saved по SSE во все подключенные клиенты.

Здесь же пришлось решить проблему дедупликации: когда сам сервер (через API) сохраняет файл, файловая система тоже генерирует событие. Чтобы события не летали по кругу, используется окно в 4 секунды и трекинг. Если файл сохранило наше API, мы игнорируем эхо от диска. Проблема в том, что для определения реальной пропускной способности надо сильно нагружать программу, хотя на регулярную работу это не влияет.

Тяжеловесы

Я сознательно отказался от парсинга и интерпретации синтаксиса плагинов (Dataview, Excalidraw и т.д.). Этим должны заниматься интерфейсы, а бэкенд должен оставаться легким движком, отдающим чистые данные.

Что я понял, но пока еще не доказал

На этом этапе я точно не могу сказать, что все гипотезы доказаны, или что передо мной уже готовый продуктовый план. Но дискавери позволил мне сузить неопределённость.

Во-первых, я увидел, что значимая часть боли вокруг заметочных приложений лежит не в интерфейсе, а в доступе, автоматизации и независимости от десктопного клиента.
Во-вторых, стал понятнее сегмент пользователей: не "все пользователи заметок", а селфхост энтузиасты и юзеры с уже живой базой, которым важно подключать свои заметки к внешним сервисам.
В-третьих, мне стало проще отделять красивую инженерную идею от реального входа в продукт. Людей пока гораздо сильнее цепляют конкретные боли и понятные сценарии - доступ через браузер, бридж в мессенджеры, фоновая автоматизация, отсутствие миграции, чем абстрактная идея “единого API для знаний”.

При этом есть вещи, которые я пока не доказал. Я не могу уверенно сказать, насколько действительно широк этот сегмент, насколько устойчиво люди будут пользоваться таким продуктом в долгую и где именно находится граница между “интересно почитать” и “готов сделать частью повседневного воркфлоу”. Вполне может оказаться, что части людей нужны не все 70 эндпоинтов, а только 2-3 для замены Obsidian Sync плюс иногда доступ из браузера.

Если же окажется, что большинство пользователей используют продукт только как замену Obsidian Sync или лишь изредка для редактирования заметок с телефона, а апплеты и сервисы почти не трогают, это будет для меня сигналом, что гипотезу про платформенный слой я переоценил и продукт надо сужать.

Что дальше?

Здесь важно уточнить: я не конкурирую с Obsidian или Logseq как с редакторами. Они остаются удобными клиентами, а мой продукт просто дает им серверный слой.

Сейчас ядро хорошо понимает форматы Obsidian, Logseq и старого доброго Zim Wiki. В планах на ближайшие месяцы - работа с аудиторией и доработка профилей. Также не исключаю поддержку Notion, но в этом вопросе не разбирался, т.к. это совсем другая история.

На ближайший месяц у меня, по сути, три продуктовые гипотезы.
Первая: людям действительно нужен единый API к разным PKM-форматам.
Вторая: self-hosted-аудитория хочет не просто sync, а именно headless-доступ к заметкам как к сервису.
Третья: уставшие от плагинной экосистемы Obsidian разработчики/пауэр юзеры готовы делать свои мини-инструменты, если убрать Electron/Typescript из уравнения.

Маркетинг здесь для меня - не реклама, а способ проверить, какая из этих гипотез является главным входом в продукт.

Проверка боем

Для меня Хабр всегда был отличной площадкой для чтения умных архитектурных дискуссий, поэтому этот кейс я пишу сюда. Но проверку продукта боем я начну на следующей неделе, когда продукт перейдет в стадию маркетинга.

Я планирую запустить кампанию на западных площадках: HackerNews, Product Hunt и профильных сабреддитах (r/obsidianmd, r/selfhosted, r/pkm). Вместо прямой спам-рекламы я буду заходить через решение болей, упакованных в контент. Я не хочу выходить на западные площадки с абстрактным месседжем “смотрите, я сделал платформу”, т.к. для раннего маркетинга это плохая подача.

Вместо этого я хочу проверить несколько узких точек входа, описанных выше - "один API для разных форматов заметок", "notes-as-a-service" и "простое и доступное создание расширений без Electron", когда для своего инструмента достаточно HTML+JS/Python и REST API.

Если одна из этих болей будет стабильно цеплять людей сильнее других, дальше уже можно будет строить вокруг неё всё позиционирование.

Для себя я буду считать сигналами попадания не абстрактный интерес, а вполне явные вещи: звёзды на GitHub и появление сторонних апплетов от других людей.

Итого

С тех пор как я впервые поднял сервер на ноуте, я почти перестал открывать десктопный клиент. И для меня это честный индикатор того, что в идее что‑то есть.

Если вспомнить ту ночь, когда я стоял в магазине перед стойкой с яблоками — раньше путь моей заметки проходил через Telegram, клипборд, запуск компьютера, запуск Обсидиана и вставку в файл, теперь же я просто пишу свои идеи в Telegram бридж и они попадают в мою папку мгновенно. Мои данные - это снова просто папка с заметками, но теперь у нее есть сила независимого API.