Фаза 2: Протокол обмена между графами

Превратить локальный прототип в сетевой протокол. Два независимых хранилища должны уметь «договориться» о смысле без ручной настройки маппингов.

Главная задача фазы

Фаза 1 доказала, что локальный граф работает. Фаза 2 должна доказать, что между графиками можно договориться о смысле — без ручного проектирования маппингов, без единой онтологии, без центрального сервера. Это принципиально новая задача: Semantic Web 2001 года предполагал единую онтологию, ActivityPub 2018 года работает с однородными постами. FSS соединяет неоднородные графы, и это не имеет прямого прецедента.

Технический вызов — не столько сетевой обмен (он относительно простой), сколько семантический мост: LLM-посредник, который сравнивает предикаты двух узлов и предлагает маппинги. Это новый класс задач, и в фазе 2 мы экспериментируем с несколькими подходами.

Компоненты фазы 2

1. Спецификация протокола

Главный артефакт фазы — спецификация FSS v1.0, написанная в RFC-стиле. Она описывает: идентификацию узлов (WebID), форматы сообщений (JSON-LD), жизненный цикл взаимодействия, подписание сообщений, обработку маппингов, обработку ошибок, расширения. Целевой объём — 30 страниц, достаточно для независимой имплементации, но без избыточных деталей.

Спецификация пишется через GitHub pull requests, с публичным обсуждением каждой существенной правки. Цель — не академическая безупречность, а имплементуемость: любой компетентный разработчик должен за неделю прочитать спецификацию и написать базовую имплементацию. Поэтому спецификация сопровождается reference-кодом, который служит живым примером.

2. LLM-маппер онтологий

Модуль, который сравнивает предикаты двух узлов и предлагает маппинги. Подходов несколько, и фаза 2 — экспериментальная площадка для их сравнения. Первый подход — семантическая близость: вычислить косинусное расстояние между эмбеддингами названий предикатов («rated» и «оценил» должны быть близки). Второй — тестовые запросы: отправить оба предиката в LLM с примерами и попросить оценить эквивалентность. Третий — поведенческая верификация: проверить, отвечают ли оба узла одинаково на тестовые запросы через эти предикаты.

def propose_mapping(pred_a: str, pred_b: str, node_a, node_b) -> Mapping:
    # 1. Семантическая близость
    sim = cosine(embed(pred_a), embed(pred_b))
    if sim < 0.3:
        return Mapping(confidence=0.0, reason="too dissimilar")

    # 2. LLM-оценка с примерами
    examples_a = node_a.sample_triples(pred_a, limit=5)
    examples_b = node_b.sample_triples(pred_b, limit=5)
    llm_score = llm_judge_equivalence(pred_a, examples_a, pred_b, examples_b)

    # 3. Поведенческая верификация
    behavioral_score = verify_behaviorally(pred_a, pred_b, node_a, node_b)

    # 4. Комбинированная оценка
    confidence = 0.3 * sim + 0.4 * llm_score + 0.3 * behavioral_score
    return Mapping(confidence=confidence, ...)

Каждый подход имеет сильные и слабые стороны, и финальный маппер — их комбинация. Метрика: 70% предикатов на тестовом наборе пар узлов получают confidence > 0.7, что достаточно для автоматического использования без ручного подтверждения.

3. Inbox / Outbox архитектура

Каждый узел имеет inbox (для входящих federated запросов) и outbox (для публикации дайджестов). Это заимствовано из ActivityPub, с адаптацией под триплеты. Inbox — это HTTPS-эндпоинт, принимающий подписанные запросы от других узлов. Outbox — публичный фид с дайджестами, на который можно подписаться.

# Узел Alice публикует обновлённый дайджест
POST https://alice.example/fss/outbox
Content-Type: application/ld+json
X-FSS-Signature: ed25519:...

{
  "@type": "FSSDigest",
  "node": "https://alice.example/fss-node",
  "generatedAt": "2026-09-15T10:00:00Z",
  "entityCounts": {...},
  "predicates": [...],
  ...
}

# Узел Bob делает federated запрос
POST https://alice.example/fss/inbox
Content-Type: application/ld+json
X-FSS-Signature: ed25519:...

{
  "@type": "FSSQuery",
  "from": "https://bob.example/fss-node",
  "query": "films directed by Hitchcock",
  "ontologies": ["personal-films/v1"],
  "maxResults": 10
}

4. Доверие и подписи

Каждое сообщение подписывается Ed25519-ключом отправителя. Подпись покрывает канонизированный JSON-LD. Доверие — отдельный слой: каждый узел ведёт белый список доверенных узлов (confidence 1.0), серый список (валидная подпись, но без явного доверия, confidence 0.5) и чёрный список (игнорировать). Репутация строится через социальный граф: если Алиса доверяет Бобу, а Боб — Кэрол, утверждение Кэрол может приниматься с коэффициентом 0.7.

Это та же модель, что в PGP Web of Trust, адаптированная под триплеты. Преимущество — нет центрального удостоверяющего центра. Недостаток — загрузка: новый пользователь начинает с пустым графом доверия и должен явно добавлять первых доверенных. Смягчение: интеграция с существующими социальными графами (Mastodon follow graph, email-контакты).

5. Demo с 3 узлами

К концу фазы 2 — публичное демо, где три независимых узла (Алиса, Боб, Кэрол) обмениваются триплетами. Сценарий: Алиса спрашивает «какие фильмы Хичкока мои друзья оценили выше 8», её узел federated запрашивает Боба и Кэрол, получает триплеты, собирает ответ с provenance. Это наглядная демонстрация того, что протокол работает.

Демо должно работать на реальных данных: реальные заметки Алисы, Боба, Кэрол (с их согласия), реальные LLM-маппинги. Никаких mock-ов. Это даёт доверие к протоколу и привлекает ранних адоптеров в фазе 3.

Календарь фазы 2

Риски фазы 2

Четыре риска. Маппинг не достигает 70%: если LLM не справляется с автоматическим маппингом, придётся вводить больше ручной работы, что снизит adoption. Смягчение: гибридный подход с UI для подтверждения маппингов пользователем (но не ручным созданием). Спецификация слишком сложная: если спецификация разрастается до 100+ страниц, её никто не имплементирует. Смягчение: жёсткий лимит 30 страниц, выносим детали в supplementary документы. Безопасность подписей: ошибки в канонизации JSON-LD приводят к уязвимостям. Смягчение: используем проверенный RDF Dataset Canonicalization (RFC), не изобретаем свой. Сетевая надёжность: federated запросы могут быть медленными или таймаутить. Смягчение: асинхронная обработка с кэшированием, явные таймауты в протоколе.

← Назад к фазе 1 · Вперёд к фазе 3 →