79 lines
3.3 KiB
Markdown
79 lines
3.3 KiB
Markdown
# 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
|
|
|
|
```text
|
|
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
|