Quem toma as decisões

A autoridade é uma abstração, não duas versões do SDK. Não existe um SDK de cliente e outro de servidor. Existe um único SDK, e o que cada chamada pode fazer é decidido pelo ator que a faz.

Um cliente mestre não é nem cliente nem servidor

Quando a máquina de um jogador cria uma sala (room) e depois a conduz, ela é um cliente mestre (master-client): tem as interfaces de room-owner e nada além disso. Não é um servidor, porque não pode fazer tudo o que um servidor faz. Mas também não é um cliente comum.

Um servidor dedicado é a mesma coisa vista do outro lado: o mesmo cliente, sem a renderização, e sem precisar de um SDK à parte. O que separa os dois é a confiança, não a construção — e a confiança vem das permissões concedidas (grant).

As interfaces seguem o ator, não o lado

Um módulo não oferece “a API do cliente” e “a API do servidor”. Ele oferece o que um room-owner pode fazer, o que um entry-validator pode fazer, o que um seller pode fazer. As páginas de módulo agrupam a interface da mesma forma: por ator.

Um papel é ao mesmo tempo o direito e a classificação

Um papel (role) diz o que um ator pode fazer e também é a forma de dizer a quem algo se destina. Não existe um segundo eixo de tags ou rótulos ao lado dele.

O código pergunta com whoami. A resposta traz o ator e as interfaces que esse ator libera agora — não uma lista fixa gravada no binário na hora do build.

Onde o código roda e qual ator ele tem são perguntas separadas

Pergunta	Respostas
Onde este código é executado?	uma cloud function · um cliente do jogo · um host que é cliente mestre ou servidor dedicado
Qual interface de ator ele tem?	`player` · `room-owner` · `entry-validator` · `seller` · `moderator` · `backend-service` · …

Numa grade, os dois eixos são independentes e toda célula é alcançável:

	cloud function	cliente do jogo	host da sala	admin
`player`	✓	✓	✓	—
`room-owner`	✓	✓ — a máquina do próprio jogador, hospedando	✓	—
`backend-service`	✓	—	✓	✓

A célula em destaque é código rodando num cliente e fazendo o trabalho de um servidor. Ela tem nome — room-owner — e é uma permissão concedida como qualquer outra.

Qualquer combinação é válida. Uma cloud function não é privilegiada automaticamente, e um cliente não é limitado automaticamente: os direitos vêm das permissões concedidas, e elas são declaradas.

A revogação vale sem emitir a credencial de novo

Uma credencial aponta para uma identidade. Ela não carrega uma lista de papéis. Os papéis são resolvidos no servidor, a cada requisição. Assim, o cliente nunca guarda a prova das próprias permissões, e depois de uma revogação não sobra nada desatualizado para ele continuar apresentando.

Por isso, revogar um papel vale sem emitir a credencial de novo; veja O que conceder um papel permite.

A revogação não é instantânea

Um papel revogado passa a ser percebido, no máximo, dentro do limite de desatualização declarado para o cache de direitos. Não há promessa de efeito instantâneo.

Onde a autoridade é declarada, não deduzida

Um tipo de sala declara o seu modo de autoridade, e não existe padrão: ou a simulação da plataforma executa o tick, ou uma autoridade externa o executa — o servidor de jogo do estúdio ou o cliente de um jogador como cliente mestre. Isso é Quem executa o tick.
Quanto se confia numa autoridade externa sobre o resultado é outra declaração no tipo de sala: aceitar o resultado, verificá-lo com um hook ou não aceitá-lo. Também sem padrão.
Qual credencial é resolvida para qual papel, e o que é uma chave de host, está em Access & Roles.