Authority

Authority is an abstraction, not two builds of the SDK. There is no client SDK and no server SDK. There is one SDK, and what a given call is allowed to do is decided by the actor making it.

A master-client is neither a client nor a server

A player's machine that creates a room and then runs it — a master-client — holds the room-owner interfaces and nothing more. It is not a server: it cannot do everything a server can. It is not an ordinary client either.

A dedicated server is the same shape from the other side: the same client without the rendering, needing no separate SDK. What separates the two is trust, not construction, and trust is carried by the grant.

Interfaces follow the actor, not the side

A module does not expose "the client API" and "the server API". It exposes what a room-owner can do, what an entry-validator can do, what a seller can do. Module pages group their surface the same way, by actor.

A role is the right and the classification, both

A role carries what an actor may do, and it is also how you say who something is addressed to. There is no second axis of tags or labels beside it.

whoami is how code asks. It reports the actor and the interfaces that actor unlocks right now — not a static list baked into the binary at build time.

Where code runs and which actor it holds are separate questions

Question	Answers
Where does this code execute?	a cloud function · a game client · a master-client or dedicated server host
Which actor interface does it hold?	`player` · `room-owner` · `entry-validator` · `seller` · `moderator` · `backend-service` · …

Laid out as a grid, the two axes are independent and every cell is reachable:

	cloud function	game client	room host	admin
`player`	✓	✓	✓	—
`room-owner`	✓	✓ — a player's own machine, hosting	✓	—
`backend-service`	✓	—	✓	✓

The emphasised cell is code running on a client and doing a server's work. It is named — room-owner — and it is a grant like any other.

Any combination is legal. A cloud function is not automatically privileged, and a client is not automatically limited: rights come from the grant, and the grant is declared.

Revocation takes effect without reissuing the credential

A credential names an identity. It does not carry a role list. Roles resolve server-side, per request, which means the client never holds the proof of its own permissions and there is nothing stale to keep presenting after a revocation.

Revoking a role therefore takes effect without reissuing the credential; see Granting a role.

Revocation is not instant

A revoked role becomes observable no later than the declared staleness bound on the rights cache. Instant is not promised.

Where authority is declared, not inferred

A room type declares its authority mode, and there is no default: either our simulation runs the tick, or an external authority does — the studio's game server, or a player's client as the master-client. That is Who runs the tick.
How far an external authority is trusted about the outcome is a separate declaration on the room type — accept it, check it with a hook, or do not accept it. Again no default.
Which credential resolves to which role, and what a host key is, is Access & Roles.