Networking, Permissions, and the Sinking of Social Functions

This chapter's thesis: the "standard legal code" a multiplayer survival server needs — land-claim protection, backup and rollback, replay arbitration, permission tiers — is highly uniform in demand, deeply kernel-dependent in implementation, and has been rewritten as plugins for over a decade by the people with the least engineering resources; these social functions should sink into the engine as first-class functions (the engine provides the primitives and the default clauses; server owners keep the right to amend). If the sunk primitives cannot cover the core function of any mainstream survival-server law plugin, this thesis is wrong.

1The problem

A new server owner's first day with a server on the rack: what to install? For a decade and more the answer has been eerily consistent — a land-claim plugin (protect the builds), an economy plugin (currency and shops), a backup plugin (the undo button), a rollback plugin (the time machine for after a raid), a teleport plugin, an announcements plugin, a permissions plugin. Volume II chapter 12 named this routine "server-owner legislation"; chapter 16 audited its operating costs. This chapter answers the question that the day-after-day repetition has buried: why are these functions not in the engine?

A word in vanilla's defense first: it is not that nobody thought of it — it is that nobody dared. Every owner's law differs slightly, and any legal code the engine ships might "decide on players' behalf." The concern is valid, but it is a concern about implementation, not about "whether." The right way to sink something is "the engine provides primitives and a default code of law; clauses can be amended, overridden, or switched off wholesale" — not "the engine decrees one way to run a server." Working in that posture, this chapter walks the sink-list item by item, and then answers its upstream question: what should ownership and permissions — the two things all these functions jointly depend on — grow into inside the engine.

2Every server owner rewrites the same law

First, the three conditions that make sinking valid; the evidence for each is already on file in earlier chapters.

The demand is highly uniform. Volume I chapter 5 listed the server owner's three states of existence — creative, survival, minigame (see The Server Is the New Game) — and whichever it is, the top five legal demands barely move: property (don't break my stuff), possessions (don't steal my stuff), recovery (when things go wrong, go back), admission (who may enter), tiers (who may govern). Uniformity of demand is the precondition of standardization — precisely because everyone needs the same code, it is worth writing into the engine rather than rewriting thousands of times in plugins.

The implementation runs deep on the kernel. A land-claim plugin works by "pre-emptively taking a position on every block event" (chapter 16's event listening); backup and rollback live by scanning the entire save; replay arbitration simply cannot be done today (the event-sourcing proposal in World Representation). All of these functions are "porters of engine capability": the performance cost is paid in the porting (every broken block passes through a plugin filter), and the functional ceiling is stuck at whatever hooks the kernel exposes. Sinking into the kernel means writing the law into the constitution, instead of having every city hire someone to stand beside every brick and shout.

Those with the heaviest consequences have the fewest resources. Today's arrangement: the costs of performance and security fall on server owners, and server owners are mostly unpaid hobbyists (Volume I chapter 5). An engine that ships an optimized set of legal primitives converges thousands of repeated, unevenly made folk implementations into one polished official implementation — the ecosystem's most expensive redundant labor, bought out in a single transaction.

3Authority, synchronization, and ownership

The common ground beneath all social functions is a concept vanilla never modeled explicitly: ownership.

Chapter 10's authority model (see The Network Protocol) settles "who adjudicates" — the server. Ownership answers a different layer: "the things in the world — whose are they, and who may touch them." Vanilla's world is blank on ownership: blocks have no owner, anyone may dig (the state of nature of Volume II chapter 12), and every sense of belonging rests on after-the-fact plugin legislation or verbal custom. The rewrite's proposal is to promote ownership to a first-class concept: blocks, entities, and regions can carry owner and permission metadata (who may interact, who may break, who may enter, who may inherit), and ownership and permissions, as part of the world's data, travel with the save, synchronize over the protocol, and replay with the recording.

Once ownership is naturalized, a whole shelf of "plugin magic" collapses back into "data operations." Land-claim protection = the region's owner is not you, so your break request is overruled by the authority (one more precedent in chapter 10's ledger); a warp point = a coordinate record published by its owner; a shared chest = your name added to a container's permission list. The politics of Volume II chapter 11 — legislation in three layers (engine, server, unwritten constitution) — gains a new division of labor here: the engine's legislative layer widens from "rules of physics" to "ownership primitives"; the server owner's legislation drops from "rewriting property law in plugins" to "amending the default clauses"; and the unwritten constitution keeps running on the human layer as before. Each layer steps back half a pace, and each layer's redundant labor shrinks by a chunk.

4Anticheat as system design

Chapter 10 ruled anticheat's predicament "congenital": the client knows everything, movement authority sits with the client, and freedom is the cheat surface. The rewrite volume cannot pretend those three layers will vanish — but it can change the war's cost structure. Anticheat is not a piece of software that scans for hacks; it is system structure that makes lying unprofitable. Three structural changes.

One, replay arbitration (chapter 4's event sourcing): cheat forensics moves from statistical guessing to replay-and-check. Two, tiered movement authority: new accounts and low-trust accounts get the stricter server adjudication (server-authoritative movement), veteran accounts keep the smoothness of client rehearsal — "trust" becomes an accumulable, revocable parameter, not a one-size default. Three, the capability list: the ownership and permission matrix (next section) naturally seals off most of cheating's payoff — the chest a hack could break already has a declared owner, and the items it could dupe are reconciled line by line in the container's ledger. Anticheat's ultimate form is not catching more people; it is turning the overwhelming majority of cheats from "violations" into "invalid operations": what the structure makes impossible needs no detection.

5Sinking the social checklist: primitives, not a platform

The sink list, item by item, stating "what the engine provides, what plugins keep." The list doubles as this chapter's acceptance test.

Land claims and protection → the engine provides ownership primitives (regions, owners, permission matrices); plugins keep the upper institutions: transfer, leasing, nations and war. Backup and rollback → the engine provides snapshot and point-in-time-recovery primitives (the world as an object, plus event sourcing — see World Representation); plugins keep scheduling policy and off-site storage. Replay arbitration → the engine provides logging and replay for contested regions (World Representation); plugins keep the appeals interface. Teleports and points of interest → the engine provides named-coordinate primitives; plugins keep pricing, cooldowns, and permission rules. Permission tiers → the engine provides the "subject × capability" matrix (next section); plugins keep rank systems and progression gameplay. Economy → the engine provides only atomic operations on "tradable things" (the atomicity of ownership transfer); currency itself stays in plugins — the economy is the one institution the engine should least decree.

The list's uniform sentence pattern exposes what sinking really means: what the engine provides are primitives (legal operations that cannot be decomposed further), not finished products (a decreed institution). Chapter 13's absorption principle — verbs into the main game, systems left to the community — applies here perfectly: land's "ownership check" is a verb; sink it. "Which server ought to have war" is a system; leave it. Sinking is not the engine eating the plugin industry's lunch; it is the ground-works every plugin shared being brought into public ownership, raising the whole industry's floor by one story — from then on, plugin authors write "institutional difference," not "the same law, again."

6Generalizing the permission model: from four notches to one matrix

The chapter's last piece of the puzzle generalizes Volume II chapter 4's "modes are permissions" (see Creative Mode Is Not a Level Editor) into its complete form.

Chapter 4's four modes (Survival / Creative / Adventure / Spectator) are four factory presets of a "player × capability" matrix; difficulty, gamerules, and command permissions are extra knobs scattered around them. The rewrite's proposal is to promote this implicit table into an explicit institution: permissions = an editable matrix of subjects (players, groups, regions, entities) × capabilities (mining, placing, interacting, flight, damage, and so on). The four modes are demoted to the matrix's four factory presets — you still switch between them in one click, but any single cell can be edited alone: open interaction rights on one tower for visitors, permanent flight for one group, a no-PVP flag on one region. In the three-layer legislation, the engine's lawmaking thus advances from coarse-grained (switch the mode) to fine-grained (edit a matrix cell), and the server owner's legislation no longer starts "from zero" — it starts "from the matrix."

The matrix's boundary must also be written down: it governs capability, not goals. Chapter 10's principle (leave the endgame blank; do not choose goals on the player's behalf) finds this expression at the permission layer: the matrix answers "who may do what," and never answers "who should do what" — the latter belongs to chapter 12's social legislation, and the engine oversteps the moment it reaches for it. The complete posture of permission-sinking: bring the cost of enforcement into the engine; leave the soul of legislation to the community.

7What this chapter leaves behind

• For players: that "land claims plus rollback" standard kit in your server is, in fact, the same homework thousands of server owners have been copying from one another for a decade and more — the future engine prints it as the standard exam paper, and server owners finally get to answer only the bonus questions.
• For developers: what you can take away are the three sinking criteria (uniform demand, kernel-dependent implementation, consequences landing on owners) and the restraint formula "primitives, not a platform" — the engine provides the atoms of legal operations, and institutions stay with the community forever. What you cannot take away is the timing: today's plugin landscape is the best demand research there is — absorb the folk code after it has been stable for ten years, and what you absorb is consensus; decree it on day one, and what you absorb is resentment.