Чем FSS отличается от существующих подходов

Каждый элемент FSS уже существует в каком-то виде. Уникальна не отдельная технология, а их комбинация: федеративный протокол + LLM-посредник + личные графы + типизированные связи.

Краткая таблица

Детальное сравнение по группам

1. Формальные семантические технологии (RDF/OWL/SPARQL)

RDF и OWL — золотой стандарт формальной семантики, и FSS не пытается их заменить. Мы используем RDF-совместимый формат триплетов внутри графа, но не требуем от пользователей писать OWL-онтологии вручную. Вместо этого LLM-посредник предлагает маппинги между типами связей разных графов на лету, а пользователь подтверждает или отклоняет. Это принципиально отличается от классического подхода, где онтология проектировалась заранее и была обязательной.

SPARQL остаётся языком запросов внутри одного графа, но для межграфовых запросов FSS вводит семантический мост: запрос на естественном языке → LLM переводит в SPARQL к локальному графу + federated запросы к дайджестам других узлов → объединение результатов с provenance. Это даёт мощь SPARQL без боли написания запросов вручную.

2. Централизованные базы знаний (Wikidata, DBpedia)

Wikidata — феноменальный ресурс, и FSS позиционирует его как один из публичных графов в сети, а не как конкурента. Локальный узел FSS может синхронизировать подмножество Wikidata по своим интересам (например, все статьи по философии), получить триплеты в локальный граф и обогащать их личными заметками. Когда другой узел запрашивает информацию, локальный LLM-агент может ответить из личного графа, из кэша Wikidata, или сделать federated запрос напрямую.

Принципиальное отличие: Wikidata — это одна большая база, а FSS — это сеть малых баз. Wikidata хорош для энциклопедических фактов (дата рождения Достоевского), но не подходит для личных утверждений («я прочитал „Преступление и наказание“ в марте 2024 и оценил на 8 из 10»). FSS покрывает оба сценария: общие факты тянутся из Wikidata, личные утверждения живут локально и опционально публикуются.

3. Личные поды (Solid)

Solid — самый близкий к FSS по философии проект: данные у пользователя, контроль доступа через токены, федеративный обмен. Но Solid решает задачу хранения данных, а не их смысловой интерпретации. Solid-pod может содержать что угодно: фотографии, документы, JSON-файлы. Протокол не говорит, как два разных приложения должны понимать один и тот же файл.

FSS можно рассматривать как семантический слой поверх Solid: pod остаётся хранилищем, но FSS добавляет типизацию связей, LLM-посредника и протокол обмена дайджестами. Технически FSS-узел может использовать Solid-pod как backend, и это даже рекомендуется — Solid уже решил проблему авторизации и синхронизации, нет смысла её дублировать.

4. Корпоративные RAG-стеки (GraphRAG, LlamaIndex Graph)

GraphRAG от Microsoft Research — отличная библиотека, и мы активно используем её идеи в фазе 1. Но GraphRAG — это библиотека для построения графа из текста, а не протокол для обмена между графами. Она работает в рамках одной системы, одной организации, одного индекса. FSS использует GraphRAG-подобные алгоритмы внутри узла, но добавляет сетевой протокол поверх.

Аналогично, LlamaIndex Graph и Neo4j + LangChain — отличные инструменты для корпоративного RAG, но они не предназначены для p2p-обмена между независимыми пользователями. FSS — это открытый протокол, в который GraphRAG и LlamaIndex могут входить как внутренние компоненты.

5. PKM-инструменты (Obsidian, Logseq, Tana, Anytype)

Obsidian и Logseq — феноменальные локальные базы знаний, и FSS рассматривает их как primary-клиентов. Планируется плагин для Obsidian, который добавляет типизированные свойства (через существующий механизм Properties) и LLM-агента для извлечения триплетов. Без плагина Obsidian остаётся гипертекстовой системой с нетипизированными ссылками; с плагином — становится полноценным FSS-узлом.

Tana с её supertags концептуально ближе всего к идее типизированных связей, но остаётся закрытым SaaS без сетевого протокола. Anytype использует P2P-синхронизацию и типизированные объекты, но синхронизация — это репликация данных, а не обмен смыслом. Если у меня и у вас есть заметка про Достоевского, Anytype синхронизирует текст заметки, а FSS позволяет сделать federated запрос «какие утверждения о Достоевском есть в твоём графе» без полного копирования.

6. Федеративные сети (ActivityPub, AT Protocol)

ActivityPub — успешный прецедент федеративного протокола (Mastodon, Lemmy, Pixelfed), и FSS активно заимствует его архитектурные паттерны: распределённые акторы, подписки, inbox/outbox, подписанные сообщения. Но ActivityPub работает с постами (короткий текст, медиа), а FSS — с триплетами (структурированные утверждения). Это разная структура данных и разная модель запросов: ActivityPub push-ориентирован (новые посты в ленте), FSS pull-ориентирован (запросы к графу).

AT Protocol (Bluesky) интересен технически, но слишком завязан на социальные сценарии. FSS не пытается быть социальной сетью — это инфраструктурный слой, на котором социальные сценарии могут строиться сверху, но это не основная цель.

Уникальная комбинация FSS

Подводя итог: каждый отдельный компонент FSS уже где-то реализован. Локальные графы — Obsidian. Типизация — Tana. P2P-синхронизация — Anytype. Извлечение триплетов — GraphRAG. Федерация — ActivityPub. Личные поды — Solid.

Уникальна именно комбинация: федеративный протокол (как ActivityPub) + LLM-посредник (как GraphRAG) + личные графы (как Obsidian) + типизация через контракты (не как Tana, а мягче) + совместимость с существующими онтологиями (RDF/OWL, Schema.org). Эта конкретная комбинация никем не реализована, и именно она, на наш взгляд, отвечает на вызов 2026 года: как соединить личные базы знаний в семантическую сеть без центра.