Прогнозные Темы

Темы ниже выходят за рамки текущего дизайна Faying Protocol.

Это последняя глава blueprint и единственная глава, чей стиль отличается от всех остальных. Она не делает выводов; она честно перечисляет открытые вопросы. Это служит двум целям: позволить читателям, дочитавшим blueprint, точно знать, что текущий Faying Protocol решает, а что — нет; и оставить ясные точки подключения для последующих отдельных спецификаций.

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

Прочие виды отношений Faying

Faying Protocol этого периода покрывает только один вид отношения: Human Prime ↔ iFay. Помимо него, как минимум следующие четыре вида отношений ещё не введены в проектирование протокола.

Прямое отношение Faying между человеком и терминалом — blueprint этого периода выбирает iFay как единственную форму сущности, которой доверено нести контракт опеки; поэтому «нахождение терминала в управляемом состоянии» должно выражаться производно через Faying State iFay. Введение «Human Prime устанавливает отношение Faying напрямую с терминалом» на каком-либо будущем этапе сначала требует ответа на несколько глубоких вопросов: обладает ли терминал достаточной «целостностью идентичности», чтобы нести контракт опеки? Не сделает ли прямое отношение, обходя iFay на уровне протокола, цепь ответственности более трудной для отслеживания и не ухудшит ли это видимость Human View? Когда два пути «прямой» и «производный через iFay» сосуществуют, как обеспечить уникальность атрибуции? У этих вопросов нет удовлетворительного ответа в этот период.

Прямое отношение Faying между человеком и программным приложением — гомологично предыдущему пункту, но с одним дополнительным слоем сложности. Программное приложение само по себе часто модульное, кросс-процессное и кросс-сетевое. При установлении отношения Faying напрямую с приложением необходимо сначала точно определить границу «приложения», а это определение ещё не сошлось через разные экосистемы и формы развёртывания. Причина, по которой этот период сделал расширение Phase 3 «производным захватом программного приложения через iFay», — именно отсрочка этой проблемы определения границы.

Взаимодействие и делегирование iFay ↔ coFay — это центральная тема Phase 4. Этот период не вводит форму протокола опеки coFay по двум причинам: атрибутивный конец coFay обычно — организация или роль, и то, как организация институционально приземляет обязанность опеки на конкретных людей или роли, — само по себе сложная дискуссия, охватывающая институты, право и корпоративное управление; и форма протокола «передача ответственности не теряется» при кросс-Fay-взаимодействии нуждается в стабильности Phases 1–3, прежде чем у неё появится подходящая точка подключения.

Взаимодействие iFay ↔ iFay — когда несколько iFay (каждый атрибутирован разному Human Prime) взаимодействуют через отношения опеки для выполнения одного действия, это поднимает вопрос «многоличного пути передачи атрибуции действия»: должно ли действие атрибутироваться инициатору, получателю или обоим по некоторому правилу распределения? Этот вопрос сходен с правовым проектированием «субделегирования между представителями» в реальном обществе, но высокочастотная плотность взаимодействия в эре Fay делает скорость обработки традиционным правом сильно отстающей. Эта тема нуждается в одновременной эволюции права, протокола и социального управления, прежде чем можно будет получить стабильный ответ.

Все четыре вида отношений выше относятся к долгосрочным направлениям эволюции Faying Protocol. Они будут вписаны постепенно в Phases 2–5 Пути Миссии, но форма протокола каждого несёт отдельная более поздняя спецификация и выходит за рамки этого периода.

B4: Отчёт о местоположении во время Rogue

Пункт 4 измерения B в Главе 13 (B4) — единственная точка проектирования протокола в этом blueprint, явно помеченная «без вывода в этот период».

Описание темы

Когда захваченный iFay терминал (например, дрон) входит в Rogue Fay, должен ли он продолжать активно отчитываться о своём физическом местоположении или состоянии терминала перед атрибутивным Human Prime?

Например: дрон Jack в ходе задачи теряет связь с Jack (удовлетворяя триггерному условию 4 в Главе 13: «Human Prime офлайн или недостижим в течение длительного времени») и входит в Rogue Fay. Физическое местоположение дрона по-прежнему меняется — под воздействием инерции, ветра, алгоритмов автоматической посадки и т. п. Вопрос таков: должен ли этот дрон продолжать активно отчитываться о своей позиции, уровне заряда и прочем состоянии терминала на сторону Jack?

Двусторонняя тяга

За продолжение отчёта — чем больше отключённый Fay отчитывается, тем легче Human Prime найти его снова и заново установить Faying. С перспективы восстановимости «местоположение видимо» — способность, защищающая интерес Human Prime.

Против продолжения отчёта — как только Fay продолжает отчитываться о своём местоположении в Rogue, злоумышленник может эксплуатировать этот канал: перехватывать информацию о местоположении, чтобы понять диапазон активности Human Prime; подделывать канал отчёта, чтобы выдавать себя за сторону Human Prime и индуцировать действия Fay; использовать «непрерывный отчёт» как средство атакующей разведки.

Обе стороны ценности легитимны, и обе соответствуют внутреннему духу Human View, но они указывают на противоположные проектные выборы протокола. В состоянии rogue Rogue Fay «активный отчёт» может одновременно защищать Human Prime и предавать Human Prime.

Возможные средние пути

Возможные решения в будущем включают, но не ограничены, следующими линиями мысли. Blueprint не предотбирает между ними.

Дифференцированная обработка по причине Rogue — Human Prime активно отозвал → скрыть местоположение; связь потеряна / таймаут → раскрыть местоположение; оповещение о вторжении → раскрыть местоположение. Использовать «почему вошёл в Rogue» как критерий, отчитываться или нет.

Явный выбор через предварительную авторизацию — в момент инициации Faying Action заставить Human Prime явно объявить «если я впоследствии потеряю связь, разрешено ли этому терминалу продолжать отчитываться о местоположении?».

Многоуровневый отчёт — не отчитываться о точном местоположении, а отчитываться о минимальных сигналах, не раскрывающих пространственной информации, например «я по-прежнему в Rogue, здоровье в норме».

Ни одна из этих трёх линий мысли не принимается как вывод в этот период. Они относятся к темам, нуждающимся в полном обсуждении в ходе эволюции Faying Protocol в Phases 2–5, и должны вбирать вход от приватности, безопасности и регуляторных сторон.

Отношение этой темы к Главе 13

B4 — лишь подлежит обсуждению, а не подлежит исполнению. До того как документ спецификации протокола приземлит окончательный выбор для B4, все остальные правила, данные Главой 13 — B1–B3 разрешены, полные правила A1–A4, C1–C3, D1–D4 — остаются в полной силе. Фактическое положение B4 в этот период таково: «уровень протокола ни требует, ни запрещает реализацию», оставляя решение конкретным реализаторам и будущим спецификациям.

Конец blueprint

К этому моменту вы должны быть способны самостоятельно ответить на следующие три вопроса о Faying Protocol:

• Что это? Контракт, явно выражающий между Human Prime и Fay «как передаются управление и ответственность».
• Что он несёт сегодня? Этическую нижнюю границу Глав 11–13 + минимальную форму контракта Phase 1.
• Что он пока не несёт? Все прогнозные темы, честно перечисленные в этой главе.

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