DPC Zettelkasten Open in the explorer

DPC API Faction Sync

A running server can push its faction roster to the community API on a timer — the one code path where a Minecraft server writes to shared public data.

A Medieval Factions server can be configured to POST its faction roster to the community API, which is how live in-game data reaches dansplugins.com. It is off by default.

The wire format

Each faction becomes a DpcFactionPayload: name, serverId, memberCount, description, and optionally serverIp and discordLink. The whole roster is sent as one JSON array with an X-API-Key header, on a timer whose interval is configurable with a one-minute floor.

Notably absent: Faction Power, Claimed Chunk counts, player names, UUIDs. The payload is a public directory listing, not a data export.

The empty-roster guard

The most important nine lines in the file refuse to send an empty array, and the reasoning is written into the comment beside them.

The provider already treats an empty array as a no-op, so sending one accomplishes nothing. Skipping it here is defence in depth: a transient empty read — faction data not yet loaded during startup, or a reload landing mid-cycle — can then never reach the wire at all, rather than reaching it and depending on the provider's guards to avoid what the comment calls a faction wipe.

The shape of the risk is what makes this worth a note. A POST carries the server's whole roster, so a bad read is not a bad row — it is a bad replacement set, and the blast radius is a shared registry other people's servers appear in. Two independent guards for one failure is proportionate when the failure is someone else's data.

Other guards in the same file

Threading

Collection runs on the main thread, dispatch runs asynchronously — see Main Thread Safety, for which this file is the reference example.

The receiving end is a separate dpc-api service that also backs dansplugins.com; the website reads from it rather than from Minecraft.

Sources

Linked from