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 (Future)

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

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

Target Features

Current Implementation

• Single-instance deployment only
• No inter-instance communication
• All data stored locally in SQLite