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
View article →
