Skip to Content

Federation & Decentralization

Version 1.1 by Robert Schaub on 2025/12/11 18:37

Federation & Decentralization

FactHarbor is designed as a network of independent nodes rather than a single centralized service.
This provides resilience, local autonomy, and virtually unlimited scalability.

Each node remains fully functional on its own while participating in a shared global knowledge graph.

Purpose of Federation

A federated architecture enables:

  • Resilience against censorship or political pressure
  • Local governance and moderation autonomy
  • Scalability by adding more nodes, not bigger servers
  • Shared knowledge structures without central authority
  • Domain specialization (e.g., health-focused node, energy-focused node)
  • Cross-node collaboration while preserving independence

FactHarbor takes inspiration from the Fediverse but uses stronger structure, integrity guarantees, and version lineage.

Federated Node Model

Each FactHarbor node maintains:

  • Its own PostgreSQL database
  • Its own vector database
  • Its own object storage
  • Its own AKEL instance
  • Its own reviewers, experts, and moderators
  • Its own trust and governance policies

Nodes exchange structured objects:

  • Claims
  • Scenarios
  • Evidence metadata (not raw files unless elected)
  • Verdicts (optional)
  • Integrity hashes and signatures

Nodes decide individually which external nodes to trust.

Global Identifiers

Each entity receives a globally unique ID.

Format:
``factharbor://<node>/<type>/<local_id>``

Example:
``factharbor://factharbor.energy/claim/CLM-55812``

Types include:

  • claim
  • scenario
  • evidence
  • verdict
  • user (optional)
  • cluster

Identifiers are:

  • Globally consistent
  • Human-readable
  • Hash-derived
  • Independent from internal database IDs

Data Sharing Model

Nodes share:

  • Claims  
  • Scenario structures  
  • Evidence metadata + content hashes  
  • Optional verdicts  
  • Integrity metadata  

Nodes do not share:

  • Local users  
  • Review discussions  
  • Internal moderation notes  
  • Private evidence  

Large assets may use:

  • Local object storage  
  • S3-compatible buckets  
  • IPFS for cross-node replication (optional)

Trust Model

Each node maintains a trust table:

  • Trusted nodes  
  • Neutral nodes  
  • Untrusted nodes  

Trust influences:

  • Whether claims are auto-imported  
  • Whether scenarios are accepted without re-review  
  • Whether evidence requires new validation  
  • Whether external verdicts are visible to users  

Reputation is local but can be mapped with trust-weighting.

Decentralized Processing

Each node independently performs:

  • AKEL processing  
  • Scenario drafting  
  • Evidence review  
  • Verdict calculation  
  • Summary generation  
  • Re-evaluation  

Nodes may specialize:

  • medical node  
  • psychology node  
  • climate node  
  • small node delegating expert review to trusted partners  

Optional cross-node data sharing includes:

  • Embeddings  
  • Claim clusters  
  • Scenario templates  
  • Verdict comparison metadata  
  • Contradiction alerts  

Cross-Node AI Knowledge Exchange

Nodes may exchange:

  • Embeddings for clustering  
  • Canonical claim forms  
  • Scenario templates  
  • Reliability hints  
  • Contradiction alerts  
  • Lightweight model insights (NOT weights)  

AKEL never:

  • Shares model weights  
  • Automatically replaces local reviewer decisions  
  • Accepts untrusted automated content  

Synchronization Protocol

Nodes periodically exchange version bundles:

  • Claims  
  • Scenarios  
  • Evidence metadata + hashes  
  • Optional verdicts  
  • Templates  
  • Embeddings (optional)  
  • AKEL distilled knowledge summaries (optional)  

Sync methods:

  • Push (webhook)  
  • Pull (cron)  
  • Subscription (WebSub-like)  

Large assets may be transferred via:

  • S3-compatible file transfer  
  • IPFS  
  • Peer-to-peer  

Scaling to Thousands of Users

Nodes scale independently:

  • horizontally scaled API servers  
  • background worker pools  
  • GPU queues for AKEL  
  • caching (Redis)  
  • sharded databases  

The network scales horizontally by adding more nodes.

Communities can form:

  • Domain-specific nodes  
  • Region/language nodes  
  • NGO/academic nodes  
  • Private organization nodes  

Nodes cooperate through:

  • Shared scenario libraries  
  • Overlapping claim clusters  
  • Expert delegation  
  • Distributed AKEL tasks  

Diagram References

Federation Architecture
This diagram shows the complete federated architecture with node components and communication layers.

graph LR
 FH1[FactHarbor
Instance 1] 
 FH2[FactHarbor
Instance 2]
 FH3[FactHarbor
Instance 3]
 FH1 -.->|V1.0+:
Sync claims| FH2
 FH2 -.->|V1.0+:
Sync claims| FH3
 FH3 -.->|V1.0+:
Sync claims| FH1
 U1[Users] --> FH1
 U2[Users] --> FH2
 U3[Users] --> FH3
 style FH1 fill:#e1f5ff
 style FH2 fill:#e1f5ff
 style FH3 fill:#e1f5ff

Federation Architecture - Future (V1.0+): Independent FactHarbor instances can sync claims for broader reach while maintaining local control.