Skip to Content

Federation & Decentralization

Version 3.1 by Robert Schaub on 2025/12/12 09:32

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.

Purpose of Federation

  • Resilience: Against censorship or political pressure.
  • Autonomy: Local governance and moderation.
  • Scalability: Adding more nodes, not bigger servers.
  • Shared Knowledge: Distributed structures without central authority.
  • Specialization: Domain-specific nodes (e.g., Health, Climate).

Federated Node Model

Each FactHarbor node maintains:

  • Local PostgreSQL database, Vector DB, and Object Storage.
  • Local AKEL instance.
  • Local Reviewers and Governance policies.

Nodes exchange structured objects (Claims, Scenarios, Evidence metadata, Verdicts) via signed bundles.

Global Identifiers

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

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

Identifiers are globally consistent, human-readable, and hash-derived.

Data Sharing Model

  • Shared: Claims, Scenario structures, Evidence metadata, Verdicts, Integrity hashes.
  • Not Shared: Local users, Review discussions, Internal notes, Private evidence.

Trust Model

Nodes maintain a trust table (Trusted, Neutral, Untrusted). This influences auto-import rules, re-review requirements, and visibility.

Decentralized Processing

Each node performs its own AKEL processing, drafting, and verdict calculation. Nodes may specialize in specific domains (e.g., Medical Node).

Synchronization Protocol

Nodes exchange Version Bundles containing:

  • Claims, Scenarios, Metadata.
  • Merkle-tree lineage.
  • Cryptographic signatures.

Methods: Push (Webhook), Pull (Cron), Subscription.

Scaling

  • Vertical: API servers, Workers, Caching.
  • Horizontal: Adding more nodes to the federation.

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.