2 Home
mikebrandon edited this page 2026-09-04 11:53:48 +00:00

here-telemetry

Work-session telemetry that runs on people's own machines, gates every byte locally before anything can reach the network, and makes what it captures visible to the person being captured.

Two clients exist and both are complete: Windows (the reference) and macOS. Linux has the transport and the paths and nothing else. Nothing server-side is built here — that belongs to the platform team.

Find your way by what you came for

You want to Go to
Understand what this thing actually does to a byte How a byte becomes a record
Know what each signal captures, and what it refuses to The seven signals
Understand why it is four processes instead of one The four processes
Implement the server side For the platform team
Port the client to another OS Porting and platform support
Build it and run the tests Building and verifying
Download a build Releases
Argue with a design choice Decisions not to relitigate — check here first
Avoid a day lost to the environment Environment gotchas
Know what running it on real machines taught us What running it taught us

The short version of the argument

Telemetry that verifies paid work is, by construction, surveillance software. The only thing separating it from spyware is whether the person being captured can see and control what is taken. So the design decisions here resolve toward observability by the subject, even when that costs capability:

  • The person can see it. An always-visible indicator reports what is being captured right now, and content capture stops if that indicator cannot prove it is on screen and recent. Not a courtesy — an enforced precondition.
  • Absence is recorded. A denied app is not masked or dropped silently; it produces a timing-only row marked suppressed, so gaps are legible instead of invisible. Suppression is a record, not a hole.
  • Deletion is real. Deleting a record propagates to frames, blobs, digests and the upload queue, and if the row was already uploaded, a deletion is queued ahead of new traffic and retried until the server confirms. A refusal is a distinct state from a confirmation.
  • The collectors cannot leak. Each signal is its own process with no network path, blocked by an outbound firewall rule applied before it starts. One that could not be blocked is not started at all.
  • Nothing is captured that nobody declared. Event types come from a generated registry, and the gate refuses anything not in it, over the wire.

The full list of claims — thirty of them, each with the name of the test that defends it — is the invariants table in README.md. That table is canonical. This wiki explains the shape; the README makes the promises.

The one rule for changing anything here

Every claim the UI makes has a test behind it. If you change what a screen says, change or add the test that holds it true. A claim the person it is about cannot check is not a feature of this product — it is a liability.