Markov Relevancy Horizon (MRH)
How Web4 creates context boundaries through relationships β you see what's relevant, nothing more.
β Try the MRH explorer below
The Key Insight
Traditional systems: Either everyone sees everything (overwhelming) or strict access control (fragmented)
Web4 MRH: Context 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 MRH: 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. MRH 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 MRH Works: Relationship Graphs
Your MRH is an RDF graph - a network of entities and their relationships. Each entity you interact with creates a relationship edge in the graph. Context emerges from who you're connected to, not from abstract metrics.
The "Markov" property: Beyond depth 3 (you β connections β their connections β third degree), entities become irrelevant. This maintains local focus and computational efficiency.
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
Interactive MRH Explorer
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 "Markov"? The Horizon Boundary
In probability theory, a Markov property means the future depends only on the present state, not the full history. In Web4, the Markov Relevancy Horizon means your decisions depend only on entities within your horizon, not the entire network.
Key principle: Beyond depth 3, relationships become statistically irrelevant to your trust decisions. This isn't arbitrary - it's based on small-world network properties and information theory.
Computational Efficiency
Limiting horizon depth means trust calculations scale O(dΒ³) where d is depth, not O(n) where n is total network size. A billion-entity Web4 network remains computationally tractable because each entity only considers ~1000 relationships.
Privacy Preservation
MRH 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.
Fractal Composition
The same MRH principle works at every scale: personal relationships, team dynamics, organizational structure, ecosystem collaborations, planetary governance. Context boundaries compose fractally.
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.
Trust Propagation Through MRH
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.
Multiplicative Decay
Trust along a path decays multiplicatively:
Canonical decay factor: 0.7 per hop. Self = 1.0, direct = 0.7, 2 hops = 0.49, 3 hops = 0.34, beyond = 0.
A path with three 0.9 trust edges: 0.9Β³ Γ 0.7Β³ = 0.25 effective trust
Multiple Paths
Multiple trust paths combine probabilistically:
Two independent 0.7 trust paths: 1 - (0.3 Γ 0.3) = 0.91 combined
Graph Patterns
Trust emerges from graph structure:
- β’ High in-degree β Reliable
- β’ Stable pairings β Operational trust
- β’ Binding clusters β Institutional trust
- β’ Central position β Network authority
Role-Based MRH: Context Is Specific
Critical principle: MRH relationships are 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 MRH 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 MRH
Same person, different contexts, completely different MRH graphs and trust scores. This prevents inappropriate trust transfer across domains.
Real-World Applications
Social Networks Without Algorithms
No algorithmic feed needed - your MRH 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
MRH naturally models org charts, project teams, and collaboration networks. Each person's MRH reflects their actual working context - no manual permission management needed.
Spam and Bot Prevention
Spam from entities outside your MRH 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 MRH. "People in your network who are surgeons" or "Mechanics trusted by people you trust" - SPARQL queries on your relationship graph.
Federated Societies
Different societies have different MRH boundaries. Some are open (anyone can join), some are closed (invitation only). MRH enables societies to maintain identity while interacting with others.
Zero-Knowledge Context
Prove you're within someone's MRH 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 (Attention 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)
T3 trust scores exist as edge weights in MRH graph. Multi-dimensional trust (Talent, Training, Temperament per role) flows through relationship paths. Trust propagation respects dimension-specific and role-specific relevance.
MRH + CI (Coherence Index)
Relational coherence (one of CI's 4 dimensions) checks MRH consistency. If you claim relationships that aren't in your MRH graph, relational coherence drops. CI modulates trust based on relationship graph integrity.
Technical Implementation
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