roblox-networkinglisted

# Roblox networking Read [`../../references/roblox-engineering.md`](../../references/roblox-engineering.md). Inventory the existing remotes and both endpoints before changing a protocol. ## Define the protocol first For each message, name its direction, purpose, sender, recipients, reliability, expected rate, payload type, validation, authoritative mutation, response, and compatibility behavior. - Send player intent and stable identifiers, not client-computed outcomes, prices, ownership, arbitrary instance paths, or whole mutable objects. The server resolves identifiers against authoritative state. - Use RemoteEvent for asynchronous one-way messages. Use RemoteFunction only when the caller truly needs an immediate reply and the handler is bounded. Never make authoritative server progress depend on a synchronous client callback. - Use UnreliableRemoteEvent only for high-frequency, supersedable presentation data. Never use it for inventory, currency, rewards, purchases, permissions, or authoritative combat outcomes. - Validate shape, size, range, class, ancestry, ownership, permission, rate, and current game state before mutation. Reject unknown fields when accepting them would broaden authority. - Rate-limit per player and action. Bound payload size and fanout; coalesce cosmetic updates instead of emitting redundant state. - Replicate authoritative snapshots or deltas with a revision when messages can race. Clients discard stale revisions and reconcile prediction without b