The Problem with WoT Alone

Web of Trust (WoT) is the backbone of spam resistance on Nostr. If you’re not in someone’s trust graph, your posts simply don’t reach them. This works well for existing users — but it creates a brutal cold-start problem for newcomers.

A new user joins Nostr. They post thoughtful content. Nobody sees it. Not because their content is bad, but because they haven’t yet been woven into anyone’s WoT. They experience Nostr as a ghost town and leave. The irony is that WoT, designed to protect quality, ends up suppressing it.

This is not a bug in WoT. It’s a structural limitation. WoT is a horizontal trust model — it asks “who vouches for you?” But there’s another dimension of trust that WoT cannot capture: temporal trust — “how long have you shown up?”

---

Introducing Proof of Presence (PoP)

Proof of Presence is a complementary trust signal based on a simple observation:

Spammers are cheap. Persistence is expensive.

Creating a throwaway keypair costs nothing. But maintaining a consistent posting history over weeks and months — while avoiding mutes and reports from the community — has a real cost. It requires genuine engagement.

PoP measures exactly that. It is a vertical trust model that asks not “who knows you?” but “how long have you survived?”

---

How It Works

A PoP score for any given pubkey is derived from three signals:

1. Accumulated Presence The number of days between a pubkey’s first and most recent kind:1 event. A pubkey that has been posting for 180 days has demonstrated sustained commitment that a fresh spam key cannot fake.

2. Survival Under Pressure The relationship between visibility and adversarial pressure is asymmetric: the more a pubkey posts, the more exposed it becomes to reports and mutes. An account that remains active despite this exposure demonstrates something meaningful. High post volume combined with low report rate is a strong positive signal.

3. Community Reports (kind:1984) Unlike mute lists — which are local and private — reports are public events. This makes them aggregatable. A pubkey that accumulates reports from multiple independent sources in the trust graph is likely problematic. Crucially, reports can be weighted by WoT distance: a report from someone two hops away carries more weight than a report from a stranger.

The composite score looks roughly like this:

PoP Score =
  (days_active × w1)
  + (survived_posts × w2)
  - (weighted_report_count × w3)

Where weights are tunable per client.

---

Why Reports Instead of Mutes?

Mute lists (kind:10000) are private by design. They’re great for personal UX but useless as a collective signal — you can’t aggregate what you can’t see.

kind:1984 (Report) events are public. One report per pubkey per reporter, published to relays, queryable by anyone. This means:

• Clients can aggregate reports across the trust graph without any central coordinator
• Report patterns are transparent and auditable
• A “community immune system” emerges organically — if enough trusted accounts report a pubkey, it surfaces as a signal without anyone having to maintain a shared blacklist

The local mute and the public report serve different purposes and complement each other:

Mute (kind:10000) Report (kind:1984) Visibility Private Public Effect Local UX only Aggregatable signal Purpose Personal comfort Community health

---

PoP + WoT: Horizontal × Vertical Trust

WoT and PoP answer different questions and are strongest in combination:

WoT  → "Who vouches for this pubkey?"    (horizontal, social graph)
PoP  → "How long has this pubkey survived?" (vertical, time + community)

A new user with zero WoT connections but 90 days of consistent posting and zero reports should be surfaced — not silenced. PoP gives clients a principled basis for doing this without compromising spam resistance.

Conversely, a pubkey with strong WoT connections but a sudden spike in reports can be down-ranked. PoP acts as a check on WoT, not a replacement.

---

Client-Side Implementation

PoP requires no protocol changes. It is entirely computable from existing event kinds:

• kind:1 — Post history (first/last timestamps, total count)
• kind:1984 — Reports (aggregated, weighted by WoT distance)
• kind:3 — Follow lists (for WoT distance calculation)

A client implementation could:

1. On startup, load the user’s follow graph and compute WoT distances
2. Maintain a local SQLite cache of PoP scores, updated incrementally
3. When rendering a feed that includes unknown pubkeys (e.g. a relay’s global stream filtered by topic), rank by PoP score
4. Surface high-PoP unknowns as “you might want to follow this person”

The scoring computation is lightweight enough to run entirely on-device — no external API, no central server, fully in the spirit of Nostr’s decentralized architecture.

---

Resistance to Manipulation

Can spammers game PoP by posting consistently for months? Yes, but the cost is the point. Running a long-lived, low-report-rate account at scale requires either genuine human engagement or significant infrastructure investment. The economics favor legitimate users.

Can bad actors coordinate report-bombing a legitimate account? This is the main attack vector. It is mitigated by WoT-weighted report scoring — a coordinated attack from a single cluster has diminished effect compared to reports distributed across independent parts of the trust graph. The weight function can be tuned to be conservative (require high WoT proximity) or liberal depending on client preferences.

Can someone buy an aged account? Possibly. But aged accounts with clean report histories have genuine value, which means the market price acts as a cost floor. This is no different from the economics of aged social media accounts on other platforms — and notably, it doesn’t undermine WoT, which requires actual human relationships.

---

Summary

Proof of Presence proposes that time and community survival are trust signals, complementary to but distinct from WoT. It addresses the cold-start problem for new users, creates an organic community immune system via public reports, and requires no protocol changes to implement.

WoT asks: who do you know? PoP asks: how long have you been here, and are you still welcome?

Together, they cover the two dimensions of trust that matter most in an open, permissionless network.

---

Conceived by Reishi Saza, drafted by Claude.