Хто ухвалює рішення

Авторитетність — це абстракція, а не дві збірки SDK. Немає клієнтського SDK і немає серверного. SDK один, а що дозволено конкретному виклику, вирішує актор, який його робить.

Майстер-клієнт — не клієнт і не сервер

Машина гравця, яка створює кімнату (room), а потім сама її веде, — це майстер-клієнт. Він має інтерфейси room-owner, і більше нічого. Це не сервер: він не може всього того, що може сервер. Але й не звичайний клієнт.

Виділений сервер — те саме, тільки з іншого боку: той самий клієнт без рендерингу, якому не потрібен окремий SDK. Розрізняє їх довіра, а не будова, а довіру несуть видані права (grant).

Інтерфейси залежать від актора, а не від сторони

Модуль не пропонує «клієнтський API» і «серверний API». Він показує, що може room-owner, що може entry-validator, що може seller. Сторінки модулів так само групують свій інтерфейс за акторами.

Роль — це і право, і класифікація

Роль (role) визначає, що дозволено акторові, і водночас нею ви вказуєте, кому щось адресовано. Другої осі з тегами чи мітками поруч із нею немає.

Через whoami код ставить це питання. Відповідь називає актора та інтерфейси, які цей актор відкриває саме зараз, — а не статичний список, зашитий у бінарник під час збірки.

Де працює код і яким актором він діє — окремі питання

Питання	Відповіді
Де виконується цей код?	у хмарній функції · в ігровому клієнті · на хості кімнати: майстер-клієнті або виділеному сервері
Який інтерфейс актора він має?	`player` · `room-owner` · `entry-validator` · `seller` · `moderator` · `backend-service` · …

Якщо розкласти це в сітку, дві осі виявляються незалежними, і досяжна кожна клітинка:

	хмарна функція	ігровий клієнт	хост кімнати	адмін-панель
`player`	✓	✓	✓	—
`room-owner`	✓	✓ — власна машина гравця, яка хостить кімнату	✓	—
`backend-service`	✓	—	✓	✓

Виділена клітинка — це код, який працює на клієнті й виконує роботу сервера. Вона має ім’я — room-owner — і це такі самі видані права, як будь-які інші.

Допустиме будь-яке поєднання. Хмарна функція не отримує привілеїв автоматично, і клієнт автоматично не обмежений: усе вирішує те, які права видано, а видачу прав оголошують.

Відкликання діє без перевипуску облікових даних

Облікові дані (credential) вказують на обліковий запис (identity). Списку ролей вони не містять. Сервер визначає ролі при кожному запиті, тож клієнт ніколи не тримає в себе доказу власних дозволів, і після відкликання йому просто нічого застарілого пред’являти.

Тому відкликання ролі набуває чинності без перевипуску облікових даних. Див. розділ Що дає видача ролі.

Відкликання діє не миттєво

Відкликану роль стане видно не пізніше, ніж мине оголошена межа застарілості кешу прав. Миттєвості ніхто не обіцяє.

Де авторитетність оголошують, а не виводять

Тип кімнати оголошує свій режим авторитетності (authority mode), і значення за замовчуванням тут немає. Тік виконує або симуляція платформи, або зовнішнє авторитетне джерело (external authority) — ігровий сервер студії чи клієнт гравця в ролі майстер-клієнта. Докладніше — у розділі Хто виконує тік.
Наскільки довіряти зовнішньому авторитетному джерелу щодо результату, окремо оголошує тип кімнати: прийняти результат, перевірити його хуком або не приймати. Значення за замовчуванням знову немає.
Які облікові дані відповідають якій ролі і що таке ключ хоста (host key), описує сторінка Access & Roles.