Your Trust Neighborhood
Who can reach you, and who you can reach — Web4 creates context boundaries through relationships, so you see what's relevant and nothing more.
The formal name is "Markov Relevancy Horizon" (MRH) — a math-flavored term we keep for spec-level work; you don't need it to use the idea.
↓ Try the context boundaries explorer below
The Key Insight
Traditional systems: Either everyone sees everything (overwhelming) or strict access control (fragmented)
Web4 Trust Neighborhoods: What you can see and do emerges from relationships (you see your connections, their connections, and their connections — nothing more)
The Problem: Context Isn't Global
❌ Traditional Web: Global Visibility or Nothing
- •Social media: Everyone sees everything (or algorithmic black box decides)
- •Access control lists: Rigid permissions, manually managed
- •Result: Information overload OR fragmentation, no emergent context
✅ Web4 Trust Neighborhoods: Context Through Relationships
- •Automatic boundaries: You see what's relevant to your relationships
- •Fractal composition: Same principle scales from personal to planetary
- •Result: Right amount of context, emergent relevance, no overload
Wait — Isn't This Just a Social Graph?
Fair question. A trust neighborhood looks like a social graph at first glance — nodes and edges, friends of friends. But the similarities are surface-level. Here's what's actually different:
- One flat "friends" list for all contexts
- Edges are binary: connected or not
- Algorithm decides what you see
- No boundary — the platform sees everything
- Free to traverse (spam is free)
- You are the product
- Separate graph per role (you-as-doctor ≠ you-as-neighbor)
- Edges carry trust scores across 3 dimensions
- Your relationships define what you see — no algorithm
- Hard 3-hop boundary — beyond it, you don't exist to them
- Crossing boundaries costs ATP (spam costs real energy)
- You own your graph — it lives on your device
How Your Trust Neighborhood Works
Your trust neighborhood is a relationship network — a map of entities and their connections. Each entity you interact with creates a relationship edge in the network. Context emerges from who you're connected to, not from abstract metrics.
Why the formal name "Markov Relevancy Horizon"? The Markov part just says your decisions depend only on nearby entities, not the full network — beyond depth 3 (you → connections → their connections → third degree), entities become irrelevant. This keeps your neighborhood locally focused and computationally efficient.
Bound
Permanent hardware/identity binding
- • Device to owner
- • Parent to child identity
Paired
Authorized operational pairing
- • Energy management
- • Data exchange
- • Service provision
Witnessed
Attestation and validation
- • Time server
- • Audit witness
- • Oracle data
Explore Your Trust Neighborhood
You + connections + their connections (default)
At depth 2 (default), Alice sees friends and friends-of-friends. This creates rich context while maintaining computational efficiency and privacy boundaries.
Why a 3-Hop Limit?
Think of how trust works in real life: you trust your friends, you somewhat trust friends-of-friends, and beyond that, people are strangers. Web4 formalizes this as the Markov Relevancy Horizon — your decisions depend only on entities within your horizon, not the entire network.
Is the horizon enforced or just calculated? Both, and that's the point. The horizon is a structural property of how trust is computed — entities outside it aren't inputs to your trust math, so they can't influence your decisions even if they wanted to. That same structure is what keeps your relationship graph private from them: there's no "global view" for anyone to query. Enforcement isn't a separate access-control layer bolted on top — it falls out of the math.
Key principle: Beyond 3 hops, relationships become irrelevant to your trust decisions. This mirrors how social networks actually work — you rarely act on information from a friend-of-a-friend-of-a-friend-of-a-friend.
Keeps Things Fast
Because each entity only looks 3 hops deep, trust calculations stay fast regardless of network size. Even a billion-entity Web4 network works smoothly because each entity only considers about 1,000 relationships — not the whole network.
Privacy Preservation
Neighborhood boundaries naturally create privacy zones. Entities outside your horizon can't see your relationships, and you can't see theirs. No global visibility needed for trust to emerge — only local relationship graphs.
Works at Every Scale
The same 3-hop principle works at every level: personal relationships, team dynamics, organizational structure, ecosystem collaborations, even planetary governance. The pattern repeats from small to large.
Emergent Context
Context isn't specified centrally - it emerges from relationship patterns. High-trust clusters form naturally. Information flows through trust paths. No algorithm decides what's relevant - your relationships do.
How Trust Spreads Through Connections
Trust doesn't exist in isolation — it propagates through relationship graphs. If you trust Alice and Alice trusts Bob, you have some basis to trust Bob, but weaker than direct experience.
How Trust Fades With Distance
Trust decays 0.7× per hop. At 3 hops, only 34% of trust remains. Beyond that — nothing. This natural boundary keeps the network manageable and private.
Why 0.7? (Not 0.5 or 0.9)
The decay factor is a design choice in a narrow goldilocks zone. The two extremes don't work:
0.7 also roughly tracks how humans actually weight trust in practice — you act on a direct friend's word, you check a friend-of-a-friend's claim carefully, and by the fourth hop you're treating them as a stranger.
Honest caveat: 0.7 is a design parameter, not a physical constant. Different communities might tune it — higher decay for privacy-sensitive contexts, lower for open discovery. The right values will emerge from real-world testing. See the fuller discussion in the FAQ.
Each Hop Weakens Trust
Every hop costs 30% of the remaining trust. Like a game of telephone — each retelling loses fidelity:
Formula
Multiple Paths Strengthen Trust
If two separate people vouch for someone, that's stronger than one person vouching. Multiple independent trust paths combine to create stronger connections:
Example: Two friends independently trust Bob at 0.7 each. Your combined trust in Bob: 0.91 — much stronger than either path alone.
Formula
What Shapes Tell Us
Trust patterns reveal different kinds of reputation:
- • Many connections → widely trusted
- • Long-term partnerships → operational reliability
- • Tight-knit groups → institutional trust
- • Well-connected position → community influence
Different Roles, Different Contexts
Critical principle: your neighborhood is role-specific. You don't just have a relationship with Alice — you have a relationship with Alice-as-surgeon and a separate relationship with Alice-as-researcher.
This means your trust neighborhood changes based on what you're doing. When seeking medical advice, you see medical relationships. When collaborating on research, you see research relationships.
Example: Alice's Role-Specific Neighborhoods
Same person, different contexts, completely different neighborhood graphs and trust scores. This prevents inappropriate trust transfer across domains.
What about privacy between roles?
Role contexts are separate by default. Someone who knows Alice as a surgeon cannot discover her car-owner trust score — those are different neighborhoods with different relationship sets. You only see the roles where you share a context. Alice can choose to link roles (e.g., proving she's both a surgeon and a researcher), but the system never reveals cross-role trust without consent.
What happens when you join a new community?
Your trust doesn't reset to zero — but it doesn't transfer at full value either. When communities federate, your trust from Community A travels to Community B at a discount (typically ~65% weight). Think of it like transferring schools: your grades come with you, but you still need to prove yourself to new teachers.
Who sets the discount? The receiving community does — it's part of their federation policy. A tight-knit medical community might only accept 40% of your external trust; a casual hobby group might accept 80%. The discount reflects how much Community B trusts Community A's standards. This is negotiated when communities federate, not imposed by a central authority. See the full walkthrough →
Real-World Applications
Social Networks Without Algorithms
No algorithmic feed needed — your trust neighborhood defines what you see. Posts from direct connections appear prominently, posts from second-degree with context, third-degree only if highly relevant. Natural information flow.
Organizational Structure
Trust neighborhoods naturally model org charts, project teams, and collaboration networks. Each person's neighborhood reflects their actual working context — no manual permission management needed.
Spam and Bot Prevention
Spam from entities outside your neighborhood is automatically low-trust and high-cost (ATP). Bots can't fake relationship histories. Sybil attacks require building independent relationship graphs for each fake presence.
Discovery and Recommendations
Find entities through trust paths in your neighborhood. "People in your network who are surgeons" or "Mechanics trusted by people you trust" — structured queries on your relationship graph.
Federated Societies
Different societies have different neighborhood boundaries. Some are open (anyone can join), some are closed (invitation only). These boundaries let societies maintain identity while interacting with others.
Zero-Knowledge Context
Prove you're within someone's neighborhood without revealing the full relationship path. Selective disclosure of relationship graph for privacy-preserving trust.
Integration with Other Web4 Pillars
MRH + LCT (Identity Constellation)
Each device in your identity constellation maintains its own MRH. Your laptop sees different relationships than your phone. Cross-device witnessing happens within MRH boundaries, creating local trust verification.
MRH + ATP Economics
ATP costs depend on recipient's position in your MRH. Messaging someone in depth 1 costs little ATP (high relevance). Messaging someone in depth 3 costs more (lower relevance). Outside MRH? Very expensive (spam prevention).
MRH + T3 (Trust Tensor)
Your T3 trust scores (Talent, Training, Temperament) travel along your relationship connections. When trust spreads through friends-of-friends, each dimension propagates independently and within the relevant role context.
MRH + CI (Coherence Index)
One of CI's four dimensions checks whether your claimed relationships match reality. If you say you know someone but your connection history doesn't support it, your coherence score drops — a natural lie detector for relationship fraud.
You've got the conceptual model — that's enough to use the idea. What follows is spec-level detail for developers, and you can stop here.
▶Technical Implementation
For developers · RDF, SPARQL, graph internals · skippable
MRH uses two web standards under the hood: RDF (Resource Description Framework — a standard way to describe relationships as subject-verb-object triples) and SPARQL (a query language for searching those relationships, like SQL for graphs).
RDF Graph Structure
MRH is implemented as an RDF graph where entities are nodes and relationships are typed edges:
# Turtle RDF syntax
@prefix web4: <https://web4.io/ontology#> .
@prefix lct: <https://web4.io/lct/> .
# Relationship triples
lct:alice web4:boundTo lct:hospital .
lct:alice web4:pairedWith lct:bob .
lct:alice web4:witnessedBy lct:timeserver .
# Relationship metadata
_:rel1 web4:subject lct:alice ;
web4:predicate web4:pairedWith ;
web4:object lct:bob ;
web4:trustScore 0.85 ;
web4:relationshipType "colleague" .SPARQL Queries
Query your MRH using SPARQL to find entities, paths, and trust patterns:
# Find entities within horizon depth 3
SELECT ?entity ?distance WHERE {
# Depth 1
{ <lct:alice> web4:hasRelationship ?entity .
BIND(1 AS ?distance) }
UNION
# Depth 2
{ <lct:alice> web4:hasRelationship ?hop1 .
?hop1 web4:hasRelationship ?entity .
BIND(2 AS ?distance) }
UNION
# Depth 3
{ <lct:alice> web4:hasRelationship ?hop1 .
?hop1 web4:hasRelationship ?hop2 .
?hop2 web4:hasRelationship ?entity .
BIND(3 AS ?distance) }
FILTER(?distance <= 3)
}Graph Updates
MRH updates automatically through interactions:
- • Binding established → Add permanent edge
- • Pairing initiated → Add operational edge
- • Witness attestation → Update edge weight
- • Relationship revoked → Remove edge
Horizon Pruning
Maintain efficiency through automatic pruning:
- • Depth limit: Max 3 hops from origin
- • Weak edges: Prune trust < threshold
- • Stale relationships: Remove inactive edges
- • Graph size: Cap at ~1000 entities
Key Takeaways
Where to Go Next
Doesn't the 3-hop limit create filter bubbles?+
MRH limits trust influence, not visibility. You can see content from anyone — MRH determines how much weight you give it. Strangers aren't invisible; they're unverified.
Several mechanisms prevent echo chambers:
- Bridge agents — people in multiple communities connect separate trust networks
- Federation — cross-community trust transfers create visibility beyond your local graph
- Role diversity — your MRH as a developer is a different graph than your MRH as a cook; you exist in many neighborhoods simultaneously
- Visible boundaries — unlike algorithmic bubbles, you can see where your MRH ends, making the boundary a conscious choice rather than a hidden filter
Honest caveat: Any trust-based system risks insularity. The difference is that MRH bubbles are transparent and permeable, while social media bubbles are invisible and algorithmically reinforced. See the full discussion in the FAQ.