Shard event catalog

The events a shard emits, and the mechanism that decides who may see them.

Not to be confused with a scheduled event. This page is about what the game tells the site, unprompted, as things happen in the world. An event in the sense of a thing you put on the calendar and run — phases, steps, a boss at eight o’clock — is Scheduled events. The two do meet: a kind listed below is exactly what a scheduled event’s phase can wait for.

The exact wire shapes are in the protocol specification and are not restated here — a copy of a wire format is a copy that will be wrong after the next bump. This page is the map and the security model.

What the shard can say

Nine groups, from the data catalog:

Group	Covers
Session & identity	Logins, logouts, account linking
Character state	Vitals, stats, skills, position
Economy & commerce	Gold movement, vendor sales, supply totals
Housing / IDOC	Decay stages, ownership, coordinates
Combat, death, PvP	Kills, deaths, notable fights
Progression & activity	Skill gains, points, leaderboards
Cheat detection & staff audit	Fastwalk and friends; staff property edits
Lifecycle	server.hello, shutdown, crash
Known gaps	Things ServUO offers no clean hook for

A representative line:

{"t":1752,"kind":"cheat.fastwalk","serial":"0x1A2B","acct":"PerryAdimn"}

Note that one. Cheat and audit events exist, and they are exactly what must never reach a public page.

How events are handled

Not all alike, and the difference is deliberate:

• State-changing kinds update tables. The current state is what a page renders.
• Notable kinds additionally append to an events log, because a history is worth keeping.
• High-frequency kinds only update state. Accumulating history for something that fires constantly buys nothing and costs a table that grows forever.

The visibility ladder

Five rungs, in order, least privileged first:

1. anonymous
2. logged_in
3. player
4. staff
5. admin

Every feature declares the rung it is visible from, and individual fields can require a higher rung than the feature that carries them — a character’s presence may be public while its location is staff-only.

This list and its order are checked against the module that enforces it on every build. Order matters as much as membership: reasoning about “staff and above” depends on the rungs being in the right sequence.

This is a security boundary, not a filter

It is applied in three places — at routes, at SSE subscribe time, and at the navigation. All three, because a surface filtered in only two of them leaks through the third.

Defaults fail closed: an unresolvable viewer is anonymous, not privileged, and a feature with no configuration is not public by accident.

Two SSE channels

Ingested events fan out to browsers over two streams:

• a public stream, carrying only allowlisted kinds;
• an admin stream, which additionally carries staff audit, cheat detection and login attempts with IP addresses.

The catalog is the module’s; the boundary is core’s. A module declares which of its kinds are public-safe, and core enforces the split — a sensitive kind cannot reach the public channel.

A viewer’s rung is resolved once, when the stream opens, and frozen for its life. A long-lived connection must not silently gain privilege because the session changed underneath it. Configuration changes, by contrast, do take effect live.

Administering it

The shard connection covers the admin screens, and the visibility ladder is administrator-configurable per feature and per field.

Canonical documents

link/PLAN.md §5 is the data catalog and §7 the wire protocol; link/v4.md is the current protocol; SHARD_VISIBILITY.md is the administrator’s guide to the ladder, and modules/uo/API.md §4 specifies it.