本页尚未翻译，当前显示英文版本。
由谁决策
权威是一层抽象，而不是 SDK 的两个 build。 没有客户端 SDK，也没有服务器 SDK。SDK 只有一个，一次调用能做什么，由发起调用的主体决定。
主客户端既不是客户端，也不是服务器
玩家的机器创建房间（room）后接着运行它，这台机器就是主客户端（master-client）。它持有 room-owner 接口，仅此而已。它不是服务器：服务器能做的事，它并不都能做。它也不是普通客户端。
专用服务器是从另一侧看到的同一种形态：同一个客户端，只是去 掉了渲染，不需要单独的 SDK。两者的区别在于信任，而不在于构造，而信任由授权（grant）承载。
接口跟随主体，而不是跟随哪一端
模块不会提供“客户端 API”和“服务器 API”。它提供的是 room-owner 能做什么、entry-validator 能做什么、seller 能做什么。模块页面也按同样的方式——按主体（actor）——组织各自的接口。
角色既是权利，也是分类
角色（role）承载主体可以做的事，同时也用来表明某样东西是发给谁的。除此之外，没有第二套标签或标记体系。
代码通过 whoami 询问。它报告当前主体，以及这个主体此刻解锁的接口——而不是构建时写死在二进制里的静态列表。
代码在哪里运行、持有哪个主体，是两个独立的问题
| 问题 | 答案 |
|---|---|
| 这段代码在哪里执行？ | 云函数 · 游戏客户端 · 主客户端或专用服务器主机 |
| 它持有哪个主体接口？ | player · room-owner · entry-validator · seller · moderator · backend-service · … |
把两条轴排成网格，就能看出它们相互独立，每个格子都可以取到：
| 云函数 | 游戏客户端 | 房间主机 | 管理端 | |
|---|---|---|---|---|
player | ✓ | ✓ | ✓ | — |
room-owner | ✓ | ✓——玩家自己的机器，负责托管 | ✓ | — |
backend-service | ✓ | — | ✓ | ✓ |
加粗的格子表示代码运行在客户端上，却在做服务器的工作。它有名字——room-owner——而且和其他授权一样，也只是一项授权。
任何组合都合法。云函数并不自动拥有特权，客户端也不自动受限：权利来自授权，而授权是声明出来的。
撤销无需重新签发凭据即可生效
凭据标明的是身份，不携带角色列表。角色在服务器端按每次请求解析，因此客户端从不持有自身权限的证明，撤销之后也没有过期的东西可以继续出示。
所以撤销角色无需重新签发凭据就会生效；参见 授予角色意味着什么。
撤销不是即时的
角色撤销后，最迟在权限缓存声明的过期上限内 就能观察到效果。平台不承诺即时生效。
权威在哪里声明，而不是推断
- 房间类型声明自己的权威模式（authority mode），而且没有默认值：要么由平台模拟运行 tick，要么由外部权威运行——工作室的游戏服务器，或者作为主客户端的玩家客户端。详见 由谁运行 tick。
- 外部权威报告的结果可信到什么程度，是房间类型上的另一项声明——接受、用 hook 检查，或者不接受。同样没有默认值。
- 哪种凭据解析为哪个角色，以及主机密钥是什么，见 Access & Roles。