A legendary drops on the fourth run of the night. Somebody's machine decided that, and unless you were hosting, it was not yours.
That sentence describes almost every co-op session ever played, and it is worth sitting with, because the architecture underneath it explains loot disputes, desyncs, host advantage, modded gear appearing in your inventory, and why Diablo went permanently online.
Four Ways to Run a Session
Co-op games pick from a fairly short menu, and the choice determines who computes what.
Host-authoritative, sometimes called a listen server, makes one player's machine the server. It runs the simulation, resolves combat, spawns enemies and rolls loot, while everyone else sends inputs and receives results. This is the default for most co-op games because it costs the developer nothing. Valheim, Deep Rock Galactic, Monster Hunter and the Borderlands series all work broadly this way.
Dedicated servers move the simulation onto a neutral machine that nobody is playing on. Valheim, Palworld and Minecraft all support this, and it removes host advantage while adding a hosting cost somebody has to bear.
Publisher-run server authority puts the simulation entirely on the developer's infrastructure. Diablo III and IV, Destiny and Warframe operate here. The client is close to a rendering terminal.
Deterministic lockstep is the outlier and the most interesting. Every client runs an identical simulation from identical inputs and an identical seed, and nobody has authority because everyone computes the same answer independently. This is the real-time strategy model, used by the Age of Empires and StarCraft lineages, and it appears in co-op only occasionally.
Whoever Runs the Simulation Owns the Randomness
In the host-authoritative model, which covers most of what this site reviews, the host's machine generates the random numbers that determine your loot, your critical hits and your enemy spawns. Not the game's servers. A stranger's desktop.
Games get away with this because nothing of consequence rides on the outcome. Where something does, entirely different architectures exist. Verification systems built for real-money play publish a cryptographic hash of the server's seed before a session begins, combine it with a seed the player supplies, and let anyone recompute every result afterwards to confirm the committed seed was the one actually used. Reviews of the best crypto casino sites now treat that recomputability as a scored testing criterion rather than a marketing line, alongside a separate and weaker model in which studio-produced games are certified by an outside testing agency and the operator simply hosts them without touching outcomes.
Verify it yourself, or trust an auditor. Co-op games offer neither. You trust the host.
What Host Authority Actually Enables
The consequences are familiar to anyone who has played co-op with strangers, even if the cause is not.
Modified clients on the host side are the big one. Because the host resolves loot, a host running modified code can generate items that cannot legitimately exist, and those items then propagate into other players' inventories and persist there. The Borderlands community has dealt with this for over a decade, and Monster Hunter has seen manipulated quest rewards distributed the same way. The receiving player did nothing and often cannot tell.
Host advantage is the quieter one. The host experiences zero network latency because the simulation is running locally. Everyone else is playing against a version of the world that is a few dozen milliseconds stale. In co-op this rarely matters. In anything competitive it decides fights.
Host migration is the failure mode. When the authoritative machine disconnects, the session either dies or has to rebuild state on another client, and rebuilding is hard enough that plenty of games simply do not try. Destiny built its reputation partly on how badly this could go.
Why Diablo Went Always-Online
Blizzard's decision to make Diablo III require a permanent connection was received as a customer-hostile business move, and there was a business dimension to it. But the technical reasoning was sound and it is the cleanest illustration of the trust problem in the whole medium.
An item's value in Diablo depended on it having been generated legitimately. Under client or host authority, that guarantee is unenforceable, because the machine deciding what dropped is a machine the developer does not control. Moving loot generation onto Blizzard's servers made item provenance verifiable in the only way available: by never letting an untrusted machine make the roll in the first place.
The cost was substantial. No offline play, launch-day outages, and a permanent dependency on infrastructure staying up. The company decided provenance was worth it, which tells you how confident they were that client-side authority would be exploited.
Lockstep Needs No Authority At All
Deterministic lockstep deserves more attention than it gets, because it solves the trust problem by dissolving it.
If every client runs a bit-identical simulation from the same seed and the same input stream, no machine has privileged information and no machine can lie about an outcome without immediately diverging from everyone else. Divergence is detectable. That is why RTS titles historically transmitted inputs rather than world state, and why their replay files are tiny: a seed plus a list of commands reconstructs the entire match.
The reason co-op mostly avoids it is that bit-identical is genuinely hard. Floating-point arithmetic can differ across compilers, architectures and optimisation settings, and a single divergent least-significant bit compounds into two players watching different games within seconds. Fixing that means fixed-point maths or heavily constrained floating-point, which constrains physics and animation in ways action games resist. Detailed treatments of the tradeoff are available from Valve's developer documentation on the client-server approach and from Glenn Fiedler's networking writing on determinism.
So co-op took the easier road, and the easier road requires trusting a stranger's computer.
Why Nobody Built Verification For This
The honest answer is that the stakes never justified it.
Nobody is going to publish a hash commitment before your Deep Rock Galactic run so you can later prove the Bittergem placement was fair. No player would check it. The cryptography exists, it is not expensive, and the reason it has not crossed over is simply that a purple drop is not worth verifying and never has been.
That is a defensible position and it is probably the right one. It is still worth knowing that when the loot table disappoints you four runs in a row, the machine you are implicitly trusting belongs to whoever clicked Host. Every online co-op session on this site's database rests on that arrangement, mostly without anybody noticing, and the games are better for not having to prove themselves.
The one place it becomes worth arguing about is any co-op game with a player-to-player economy attached, which is precisely where the industry keeps rediscovering that host authority and tradeable items are a bad combination.