morpheus/docs/web-of-trust.md

Morpheus — Web of Trust

Core Concept

The Morpheus relay only accepts events from pubkeys that are followed by at least N existing members on the relay. This uses the follow graph that already exists in Nostr (NIP-02 contact lists) — no custom NIPs, no invite tokens, no special vouch events.

How It Works

1. User A publishes a NIP-02 contact list that includes User B's pubkey
2. The relay counts how many existing members follow User B
3. If the count reaches the threshold (e.g., 3), the relay starts accepting events from User B
4. If User B's follower count drops below the threshold (unfollows), the relay stops accepting new events from them

Relay receives event from pubkey X
  → Count NIP-02 contact lists on this relay that include X
  → If count >= N: accept event
  → If count < N: reject with auth-required or closed message

Why This Works

• Spam dies naturally — bots cannot accumulate real follows from established members, so they never reach the threshold
• No moderation overhead — the follow graph is the moderation layer; no admin has to manually approve or ban users
• Community stays coherent — the seed community is Russian-speaking, and follows propagate through real social ties, so the network stays culturally and linguistically coherent without explicit language filters
• Irrelevant noise disappears — the relay only serves events from the member set, so random global Nostr traffic never enters the feed
• Zero custom protocol — uses only NIP-01 (events) and NIP-02 (contact lists), which every Nostr client already supports
• Decentralized trust — no single gatekeeper; trust is distributed across the follow graph

Threshold Tuning

N	Effect
1	Minimal gate — one follow from any member lets you in. Easy growth, weak spam protection.
3	Balanced — requires a small social cluster. Good for early growth phase.
5+	Tight community — harder to get in, strong spam resistance. Good for mature network.

The threshold can be dynamic — lower during early growth, raised as the network matures. It can also differ per event kind (e.g., posting requires 3 follows, but DMs only require 1).

Edge Cases

• Bootstrap problem — the first N users must be manually allowlisted (seed set). This is the founding community.
• Lurkers — users who read but don't post still need follows to interact. Read access can optionally be open.
• Cross-relay — users can still connect to public relays alongside the Morpheus relay. The WoT gate only applies to the Morpheus relay feed.
• Sybil resistance — creating fake accounts to follow yourself is possible but costly at scale (each fake needs N real followers itself). The recursion makes sybil attacks exponentially harder.
• Follower loss — if someone unfollows you and your count drops below N, your existing events stay on the relay, but new events are rejected until count recovers.

Implementation Notes

• The relay maintains a materialized view of the follow graph (NIP-02 kind:3 events)
• On each incoming event, it checks the author's inbound follow count against the threshold
• The count updates in real-time as NIP-02 contact lists are published
• The seed set (manually allowlisted pubkeys) is configured at relay startup