Every Time Your Identity Was Presented: the Activity Log

The heading above is our content plan's, and it promises something this log does not contain. It does not record presentations. It records sign-ins, your DID registration, and the moment you created a share, not that anyone used one, when, or who.

The rest of this page is what is actually in it.

What the log contains

Five kinds of event get written, and we enumerated the call sites rather than guessing:

event	written when
`auth.login`	you sign in
`auth.google_login`	you sign in with Google
`auth.github_login`	you sign in with GitHub
`did.registered`	your identifier is registered during onboarding
`credential.shared`	you create a share

Three of the five are sign-ins. In practice this is a login history with two identity events attached, and describing it as a presentation record would be wrong.

credential.shared is the one that gets misread, so to be exact: it fires when you make a share, not when a verifier opens it. The log knows what you offered. It does not know what anybody looked at.

What is not in it, checked properly

No presentation event exists anywhere in this product. A search across every backend module for a presentation or verification log entry returns nothing, and there is no presentation module in the backend at all. A control confirmed the search reaches this code.

So the questions the title invites, who verified my identity? when was my credential used?, have no answer here. Not a partial answer. No answer.

The second thing to know: the log is best-effort

Writes are fire-and-forget, and failures are swallowed on purpose. The writer's own comment says so: "Never throws — errors are swallowed so they don't break the main request." A failed insert is printed to a server console and dropped.

That is a defensible engineering choice and we are not going to pretend otherwise: it means a logging problem can never stop you signing in or creating a share. The user-facing action always wins.

The cost is completeness. This log is not a guaranteed record. If a write fails, the event is simply missing, nothing tells you, and there is no reconciliation pass that would notice. For an audit trail, something you could rely on to prove what happened: that is disqualifying, and a page describing it as one would be doing the thing this site exists to avoid.

What is genuinely right about it

It is per-user and authenticated. The endpoint scopes to your own account.
It supports filtering by event type, so the login noise can be set aside.
The failure mode is the safe one. Choosing to lose a log line rather than break a sign-in is the correct trade for this product: it is only the description of the result that has to stay honest.

What you cannot check yourself

The surface is behind authentication. /activity redirects to login, and a deliberately fake path returns 404, so the redirect means something, but you still need an account to see anything. This page is code-read evidence, not the run-it-yourself kind, and we would rather grade it than imply otherwise.