Технологический стек
Стек выбран под три приоритета: локальность (всё работает офлайн), нулевая стоимость запуска (бесплатные open-source компоненты), долговечность (Markdown и SQLite открываются через 20 лет).
Принципы выбора стека
Каждый компонент должен удовлетворять трём критериям. Первый — возможность работы полностью офлайн: локальный LLM, локальная база, локальный индекс. Облачные API допустимы только как опциональное ускорение, не как обязательная зависимость. Второй — open-source с permissive лицензией (MIT, Apache 2.0, BSD): никаких proprietary компонентов, которые могут умереть или сменить лицензию. Третий — стандартные форматы хранения: Markdown для текста, JSON-LD для триплетов, SQLite для индексов. Любой из них открывается сторонними инструментами через 20 лет, что критично для базы знаний.
Эти критерии отсекают многие соблазнительные варианты. Не подходит векторная база Pinecone (облако). Не подходит OpenAI API как обязательный компонент (облако + проприетарное). Не подходит Notion API (проприетарное). Не подходит кастомный бинарный формат индекса (долговечность). Что остаётся — описано ниже.
Стек по слоям
Слой хранения
Основа — файловая система с Markdown-файлами. Каждый файл = одна заметка с frontmatter для типизированных свойств. Это делает хранилище напрямую совместимым с Obsidian, Logseq, и любым текстовым редактором. Никакого проприетарного формата, никакой обязательной базы — только текстовые файлы в папке.
SQLite выбран как индекс, а не как основное хранилище, по важной причине: если база повредится, пользователь не теряет данные — Markdown остаётся, индекс перестраивается за минуты. Это критично для долговечности: базы данных ломаются, текстовые файлы — нет. LanceDB встроен как embedded-библиотека (без отдельного сервера), что упрощает установку.
Слой логики
Reference-имплементация пишется на Python — это самый низкий порог входа для контрибьюторов и лучший ecosystem для AI/ML задач. FastAPI как API-сервер (для интеграции с плагинами Obsidian и другими клиентами). LlamaIndex как OR/M для графа знаний и абстракция над LLM-провайдерами.
Выбор Python не закрывает возможности других языков: спецификация протокола языконезависима, и параллельная TypeScript-имплементация для браузерных клиентов появится в фазе 2. Rust или Go версии приветствуются сообществом — это даже желательно для production-использования, где Python может быть медленным.
Слой LLM
По умолчанию используется Ollama с локальной моделью — это обеспечивает приватность и работу офлайн. Рекомендуемые модели на 2026 год: Qwen 2.5 (7B или 14B), GLM-4 (9B), Llama 3.1 (8B). Для извлечения триплетов достаточно 7B, для маппинга онтологий лучше 14B. Опционально — облачные модели через OpenAI API / Anthropic API для тяжёлых задач, но это никогда не обязательно.
Критически важный компонент — structured output. Извлечение триплетов из текста должно быть надёжным, а не вероятностным: модель обязана вернуть JSON строго определённой схемы. Для этого используется Outlines (или guidance, или instructor — альтернативы), что гарантирует парсимость. Без этого компонента протокол нестабилен.
Слой сетевого обмена
Федеративный обмен строится поверх HTTPS + JSON-LD, по архитектурному образцу ActivityPub. Каждый узел имеет inbox (для входящих запросов) и outbox (для публикации дайджестов). Сообщения подписываются PGP-ключом узла, что даёт авторство без блокчейна.
Почему не ActivityPub напрямую? ActivityPub работает с постами (короткий текст), а FSS — с триплетами (структурированные утверждения). Структура сообщения другая, модель запросов другая (pull, а не push). Но паттерны подписок, доставки, обработки inbox — заимствуются целиком, чтобы не изобретать колесо.
Слой клиента (UI)
Reference UI — Tauri-приложение (Rust + веб-фронтенд), которое выглядит как Obsidian, но с тремя видами: текст (редактор Markdown), граф (визуализация триплетов), чат (LLM-агент). Параллельно — плагин для Obsidian, который добавляет FSS-функциональность в существующий Obsidian без отдельного приложения.
Плагин для Obsidian — приоритетный путь, потому что у Obsidian уже многомиллионная аудитория PKM-пользователей, и добавить FSS-функциональность в существующий workflow проще, чем убедить перейти на новое приложение. Tauri-приложение — для тех, кто хочет всё-в-одном без зависимости от Obsidian.
Зависимости и риски стека
Главный риск — Ollama. Если проект перестанет развиваться, переход на альтернативу (llama.cpp напрямую, LM Studio, vLLM) потребует рефакторинга, но не переписывания всего стека. Чтобы снизить риск, мы абстрагируем LLM-доступ через LlamaIndex, который поддерживает множество провайдеров.
Второй риск — LlamaIndex. Библиотека активно развивается, API меняется. Чтобы не зависеть от её капризов, мы используем только стабильное подмножество (Structured Extractors, LLM-абстракция, Graph Store). Всё остальное — собственный код поверх SQLite и LanceDB, что гарантирует контроль.
Третий риск — Tauri. Если он не взлетит как Electron-альтернатива, у нас всегда есть fallback на Electron (тяжелее, но зрелый) или вообще на чисто-веб-версию (PWA). Плагин для Obsidian от этого не зависит и остаётся основным клиентом.
Что сознательно не в стеке
Несколько технологий соблазнительны, но явно не входят в стек, чтобы не перегружать систему. Не используется блокчейн — доверие через PGP и репутацию, не через консенсус. Не используется IPFS — обычный HTTPS достаточно, а IPFS добавляет сложность без очевидной выгоды для личных графов. Не используется GraphQL — REST + JSON-LD проще и совместимее. Не используется Kubernetes или Docker Swarm — это для одного пользователя избыточно, локальный процесс с SQLite справляется.
Каждое «не используется» — осознанный отказ. FSS должен работать на ноутбуке разработчика без докера, на старом компьютере без GPU, на VPS за 5 долларов. Чем меньше обязательных компонентов, тем выше adoption. Это противоречит энтерпрайз-тренду на microservices, но соответствует задаче: личный семантический граф для каждого, а не корпоративная платформа.