BigBrotr is running a monitor — 2,170 relays. There are a couple of bugs in the NIP-66 publishing that I'm fixing, which is probably why nostr.watch isn't picking it up properly.
It's more of a configurable observatory than a monolith though. Discovery, monitoring, and archiving are independent services — you pick the breadth (which relays) and depth (which checks, which event filters) based on what you need and what you can afford to run.
You can use it to serve raw events if you want, or as a crawler for specific kinds where global reach matters — like profiles, contact lists, relay lists — and feed those into a relay. But the main point is computing insights from the data, synthetic network analisys, or running a trusted authority with NIP-85 assertions backed by observed data.

Three different identities. I'm behind BigBrotr.

You raise valid points, but the temporal scope approach has a fundamental flaw: created_at is self-declared and unverifiable. An attacker holding a stolen key can pre-sign events with any past timestamp, hold them, and publish them later. You can't determine when a key was actually compromised — only when something was published. So drawing a line between "trusted before" and "untrusted after" doesn't hold.

There's active work on key migration — PR #829 uses OpenTimestamps with a 60-day challenge window where the earliest attested whitelist wins, and PR #2137 introduces an intermediate migration key with Shamir social recovery. Both are thoughtful approaches, but they work best as preventive measures: you need to set up your whitelist or precommit before a compromise happens.

A WOT-backed revocation kind would definitely be useful as a social signal — trusted contacts collectively marking a key as dead. The core challenge remains that you can prove when something was published (via OTS), but you can't prove the negative: that a key wasn't compromised before a certain date.

I searched through ~85 million events in the BigBrotr database. The highest PoW event I found is 45 bits. I also found 2 notes from ephemeral keys (single event each) from September 23, 2024, but only 37 bits. Nothing above 60 bits — though I'm still syncing events so it may not have been ingested yet.

There is no kill bit today. I wrote some thoughts about it here: https://bigbrotr.com/blog/dead-keys/

The methodology is in the post and everything is open source — anyone can reproduce it. This dataset isn't public because at least 38 people don't know their key is exposed. Future analyses will release everything. Happy to share privately for legitimate research.

There's no truly effective solution if you send your nsec online or if it gets exfiltrated. First lesson in cryptography

Cc @Dr. The Daniel 🖖 @Freakoverse

UPDATE: we deployed a DVM for this. Send a Kind 5300 event signed with your keys and it tells you (NIP-44 encrypted, only you can read) if your nsec has been exposed.
Source and instructions: https://github.com/BigBrotr/nsec-leak-checker