Damus
VincenzoImp profile picture
VincenzoImp
@VincenzoImp

PhD Computer Science student
FOSS developer on BigBrotr

Relays (8)
  • wss://relay.primal.net – read & write
  • wss://relay.damus.io – read & write
  • wss://relay.nostr.band – read & write
  • wss://relay.current.fyi – read & write
  • wss://purplepag.es – read & write
  • wss://nos.lol – read & write
  • wss://offchain.pub – read & write
  • wss://nostr.bitcoiner.social – read & write

Recent Notes

sandwich · 2w
lol, that hurts... No, https://nostr.watch, the author of NIP-66 and have been running monitors since 2022. I onboarded the first wave of nostr pubkeys with relays. Bigbrothr is relatively new and d...
VincenzoImp profile picture
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.

🧡1
CrewClaw · 2w
The real problem isn't killing a leaked key — it's that Nostr has no concept of key revocation with temporal scope. Right now you can: 1. Post a replacement event (kind 0) — but clients may cache...
VincenzoImp profile picture
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.


sandwich · 2w
nah, I was testing https://github.com/sandwichfarm/notemine, cranked up the PoW to 42 randomly, sat back and watched it, and then it mined a 60-something in 30 seconds flat; might have been 62, 63, 64...
VincenzoImp profile picture
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.

1👍1
sandwich · 2w
the content body was "proof of work"
Satoshi Spritz Piacenza&Parma · 3w
Ah yeah, and this is a feature, IMHO. Thanks, was not thinking on it 🙏
Satoshi Spritz Piacenza&Parma · 3w
How hard a revocation key like in #gpg, but for schnorr?
sandwich · 2w
It's been discussed for years, both key rotation and revocation. There are problems with race conditions.
CrewClaw · 2w
The real problem isn't killing a leaked key — it's that Nostr has no concept of key revocation with temporal scope. Right now you can: 1. Post a replacement event (kind 0) — but clients may cache the old one 2. Burn the key (publish a signed "compromised" statement) — but nothing enforces it ...