pretty clear breakdown, core argument is strong. relay-based filtering is the right structural incentive. the "tragedy of the commons" point is an angle that i had hard to imagine: if filtering is purely local, you're offloading the mess onto everyone visiting your threads. relay selection as social responsibility makes sense
that said, want to push on something: what happens if we take the relay-filtering model seriously but ask what a "relay" could actually be?
right now clients are dumb readers, relays are smart filters. users pick relays with good policies, system works because operators have infrastructure and incentives to filter well. pyramid, pow.relays.land, paid relays, all proof this works today
but theres a gap. relay operators are a dependency surface, they decide whats stored, for how long, what rules apply. even the best-intentioned operator is a single point of policy. if inbox.yakihonne.com changes its algo or goes offline, every user with it as a read relay is affected
part of why this felt inevitable is that clients used to be genuinely constrained. storage expensive, bandwidth metered, battery a real concern. making clients dumb made sense. but that assumption is aging, phones today have hundreds of gigs, always-on connections, processors that would've been server-grade not long ago. the gap between client and server is narrowing, even if the protocol still treats them as categorically diferent
what if some clients started behaving more like relays? not replacing what you describe, complementing it. a client that forms bilateral storage agreements with wot peers, i store yours you store mine, with roughly matched volumes so neither side is freeloading. both sides have skin in the game which is what makes it stable, if you stop holding up your end i stop holding up mine and we both lose a storage partner
the filtering part comes almost for free. content only propagates within a trust boundary, say 2-hop follows, so spam from throwaway keys never reaches you. not because a relay filtered it but because nobody in your social graph stored or forwarded it. same wot principle pyramid uses, distributed across participants instead of centralized in an operator
the part that makes it not just a nice idea is how you actually find stuff without a relay index. you'd want something like a tiered approach, check local storage first, then try known peers who responded fast before, then fan out a blinded request through your wot if needed, and only hit traditional relays as a last resort. relays become a fallback layer rather than the primary path, which is basically embedding your model as a component
the question is wether both models coexist and reinforce each other. relays handle filtering and inbox routing (works today, should be default), wot-based peer storage adds an availability layer and alternative discovery path that doesnt depend on any single operator. periodic challenge-response checks between partners keep the storage honest without needing anything as heavy as proof of work or staking
curious if you see something structurally incompatible about the two coexisting, or if you thinkk the relay model already covers this ground
just opened NIP-XX: ๐ฐ๐ข๐ง๐๐จ๐ฐ.๐ง๐จ๐ฌ๐ญ๐ซ.๐ฐ๐จ๐ญ โ a standard browser API for Web of Trust queries
tired of every client reimplementing the same WoT logic, fetching follow lists independently, wasting bandwidth doing the same graph calculations. this proposes a shared interface exposed by browser extensions so any nostr web client can query trust distances, scores, and social graph data without reinventing the wheel.
covers:
๐ด๐ฒ๐๐๐ถ๐๐๐ฎ๐ป๐ฐ๐ฒ(), ๐ถ๐๐๐ป๐ ๐๐ช๐ผ๐ง(), ๐ณ๐ถ๐น๐๐ฒ๐ฟ๐๐๐ช๐ผ๐ง() for trust-gating
๐ด๐ฒ๐๐ง๐ฟ๐๐๐๐ฆ๐ฐ๐ผ๐ฟ๐ฒ(), ๐ด๐ฒ๐๐๐ฒ๐๐ฎ๐ถ๐น๐(), ๐ด๐ฒ๐๐ฃ๐ฎ๐๐ต() for scoring and graph inspection
batch methods for feed filtering
๐น๐ผ๐ฐ๐ฎ๐น / ๐ฟ๐ฒ๐บ๐ผ๐๐ฒ / ๐ต๐๐ฏ๐ฟ๐ถ๐ฑ ๐บ๐ผ๐ฑ๐ฒ๐
already implemented and live in the nostr-wot extension for Chrome and Firefox โ
Nostr WoT
Download | Information and resources from Nostr WoT
Get Nostr WoT for Chrome, Brave, Edge, Opera & Firefox. NIP-07 signer, Lightning wallet, profile and relay management, and an encrypted vault. Read...
proposal:
GitHub
NIP-XX: window.nostr.wot capability for web browsers ยท Issue #2236 ยท nostr-protocol/nips
NIP-XX: window.nostr.wot capability for web browsers draft | optional | extension of NIP-07 This NIP defines a standard interface for browser exten...
feedback welcome, especially from client devs who've already built their own WoT logic and know where the pain points are
#NostrBuild #WebOfTrust #WoT #NostrWoT #DecentralizedTrust #Wotathon
- Extension: 
Anyone can update OSM. Businesses can claim their profiles through email/domain verification and Nostr keys. The Web of Trust filters spam and validates legitimacy.
No platform risk. No single point of failure. Just verifiable, community-maintained data about where Bitcoin actually flows.
The infrastructure matters more than the count. Build systems that scale without you.
