Phase 3: Производный Захват Программных Приложений через iFay

Phase 3 поворачивает направление расширения с терминального оборудования на программные приложения — локальные приложения, облачные сервисы и встроенные In-APP-сценарии.

Между программными приложениями и терминальным оборудованием есть одно ключевое различие: состояние терминального оборудования относительно сосредоточено — дрон или робот представляет собой единый объект под опекой, — тогда как граница программного приложения часто процессная, модульная и кросс-сетевая. E-commerce-клиент, захваченный iFay, может одновременно взаимодействовать через несколько доменов, несколько API и несколько сторонних сервисов. Сложность Phase 3 не в «захвате», а в том, ясно ли описана граница захвата.

Деривационная структура, гомологичная Phase 2

Phase 3 структурно симметрична Phase 2 и так же не вводит «Human Prime ↔ программное приложение» как прямое отношение:

Программное приложение входит в Faying State через iFay соответствующего Human Prime.

Ответственный конец по-прежнему Human Prime. iFay производно захватывает программное приложение через Faying State; механизм гомологичен механизму захвата терминала в Phase 2. Само программное приложение не стоит самостоятельно в Faying State.

Три ключевых отличия

Phase 3 добавляет три дополнительных усложнения, требующих особой обработки поверх структуры Phase 2.

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

Более плотное межграничное взаимодействие. Захваченное ПО может внутренне вызывать множество внешних сервисов, сторонних API и удалённых облачных функций. Phase 3 должна обеспечить, чтобы любой вызов, инициированный iFay через захваченное ПО, по-прежнему имел свою ответственность атрибутированной исходному Human Prime; ответственность не должна молча ускользать через цепь межсервисных вызовов. Это требование напрямую отвечает на реальную боль, очерченную в Главе 1: «никто не может ясно сказать, какие стороны обрабатывают данные по цепи вызовов».

Более скрытные побочные эффекты. По сравнению с физическими действиями, программные побочные эффекты (запись данных, изменения подписок, привязки сторонних аккаунтов) интуитивно труднее воспринимаются Human Prime. Phase 3 должна более явно приземлить требование «достижимости информации» Human View из Главы 11 — побочные эффекты должны раскрываться так, чтобы Human Prime мог узнать о них с разумными издержками, а не быть похороненными глубоко в цепи вызовов.

Отношение к объёму текущего периода

Phase 3 выходит за рамки текущего дизайна Faying Protocol. Эта глава очерчивает существование Phase 3, чтобы объяснить направление эволюции Faying Protocol, а не обязывает поставить её в этом периоде. Конкретная форма протокола Phase 3 будет нести отдельная более поздняя спецификация.

После Phase 3 Faying Protocol покрывает отношение Fay как с аппаратными, так и с программными концами исполнения, но обсуждение по-прежнему вращается вокруг «один Human Prime + один iFay». Следующий этап, Phase 4, расширяет перспективу до организаций: когда Fay более одного и ответственный конец более не является единственным физическим лицом, как отношение Faying по-прежнему сохраняет согласованную атрибуцию.