Reading the operator console

First: the numbers on the public preview are not real

The console preview on relay.solidus.network renders sample data, and the page says so. The connection counts, queue depths and message IDs you see there are illustrative, they exist to show the shape of the surface, not the state of a network.

Do not cite any figure from that preview as a metric, ours or anyone's. If you have seen a number attributed to Solidus Relay's traffic, it came from a sample.

This page explains what the panels mean, so that when you sign in and see your own data you know what you are looking at.

What the console is for

A mediator operator has four questions, and the console is organised around them:

1. Who is mediated?, which agents hold a grant.
2. Is anything stuck?, queue depth, and what is not draining.
3. Did routing resolve?, whether we could find where to deliver.
4. Why was something refused?, policy decisions, with a reason.

Mediations

Each row is an agent that asked to be mediated and what was decided. A grant is not a single event so much as a standing relationship: the routing key it issued, and the keylist attached to it, are what actually govern delivery. See Coordinate Mediation 2.0 and keylist management in practice.

A denied mediation carries a reason, and the reason distinguishes why: no credential presented, a credential that did not satisfy the policy, or the verifier being unreachable, an infrastructure fault, not a verdict about the agent. That distinction is deliberate and it is the subject of credential-gated mediation.

Queue and delivery

Queue depth is messages accepted but not yet collected. A non-zero queue is normal: it is the mediator doing its job for an agent that is offline. What matters is whether it drains when the agent reconnects.

A queue that never drains usually means one of two things, and the console cannot tell you which: the agent is not coming back, or it is collecting without acknowledging. The second is the more common bug and it is covered in Pickup Protocol 3.0, acknowledge after durable storage, and the mediator can drop its copy.

Limits and what happens at them are queue depth and backpressure.

Resolutions

Each routing resolution reports how it was answered, not just what: resolved live from the chain, served from cache, or failed outright. A cached answer keeps its original block height and timestamp rather than being re-stamped as fresh, so "resolved 40 minutes ago" on this panel means exactly that. See chain-anchored routing resolution.

What the console does not show you

Message contents. It cannot: the mediator holds no key that opens the inner envelope. Every panel above is built from metadata, timings, sizes, routing keys, decisions, and that is the whole of what exists to display.

Which is also the point worth taking away: the console is a fair picture of what a mediator knows about you. If you want to understand relay's privacy properties, read it as a specimen, then read what a mediator can and cannot see.

Getting your own

The operator plane is authenticated:

curl -s -o /dev/null -w '%{http_code}\n' https://relay.solidus.network/v1/mediations
# 401

Sign in at relay.solidus.network for a key. Programmatic access to the same data, including push rather than polling, is webhooks and delivery logs.

Relay implements Coordinate Mediation 2.0 and Pickup 3.0; no independent DIDComm conformance suite has been run, so "implements" is the claim and "conformant" is not.