Wiki source code of Federation & Decentralization
Version 5.1 by Robert Schaub on 2025/12/12 19:37
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
1.1 | 1 | = Federation & Decentralization = |
| 2 | |||
| 3 | FactHarbor is designed as a network of independent nodes rather than a single centralized service. | ||
| 4 | This provides resilience, local autonomy, and virtually unlimited scalability. | ||
| 5 | |||
| |
5.1 | 6 | == Purpose of Federation == |
| |
1.1 | 7 | |
| |
5.1 | 8 | * **Resilience**: Against censorship or political pressure. |
| 9 | * **Autonomy**: Local governance and moderation. | ||
| 10 | * **Scalability**: Adding more nodes, not bigger servers. | ||
| 11 | * **Shared Knowledge**: Distributed structures without central authority. | ||
| 12 | * **Specialization**: Domain-specific nodes (e.g., Health, Climate). | ||
| |
1.1 | 13 | |
| |
5.1 | 14 | == Federated Node Model == |
| |
1.1 | 15 | |
| 16 | Each FactHarbor node maintains: | ||
| |
5.1 | 17 | * Local PostgreSQL database, Vector DB, and Object Storage. |
| 18 | * Local AKEL instance. | ||
| 19 | * Local Reviewers and Governance policies. | ||
| |
1.1 | 20 | |
| |
5.1 | 21 | Nodes exchange structured objects (Claims, Scenarios, Evidence metadata, Verdicts) via signed bundles. |
| |
1.1 | 22 | |
| |
5.1 | 23 | == Global Identifiers == |
| |
1.1 | 24 | |
| |
5.1 | 25 | Format: ``factharbor://<node>/<type>/<local_id>`` |
| |
1.1 | 26 | |
| |
5.1 | 27 | Example: ``factharbor://factharbor.energy/claim/CLM-55812`` |
| |
1.1 | 28 | |
| |
5.1 | 29 | Identifiers are globally consistent, human-readable, and hash-derived. |
| |
1.1 | 30 | |
| |
5.1 | 31 | == Data Sharing Model == |
| |
1.1 | 32 | |
| |
5.1 | 33 | * **Shared**: Claims, Scenario structures, Evidence metadata, Verdicts, Integrity hashes. |
| 34 | * **Not Shared**: Local users, Review discussions, Internal notes, Private evidence. | ||
| |
1.1 | 35 | |
| |
5.1 | 36 | == Trust Model == |
| |
1.1 | 37 | |
| |
5.1 | 38 | Nodes maintain a **trust table** (Trusted, Neutral, Untrusted). This influences auto-import rules, re-review requirements, and visibility. |
| |
1.1 | 39 | |
| |
5.1 | 40 | == Decentralized Processing == |
| |
1.1 | 41 | |
| |
5.1 | 42 | Each node performs its own AKEL processing, drafting, and verdict calculation. Nodes may specialize in specific domains (e.g., Medical Node). |
| |
1.1 | 43 | |
| |
5.1 | 44 | == Synchronization Protocol == |
| |
1.1 | 45 | |
| |
5.1 | 46 | Nodes exchange **Version Bundles** containing: |
| 47 | * Claims, Scenarios, Metadata. | ||
| 48 | * Merkle-tree lineage. | ||
| 49 | * Cryptographic signatures. | ||
| |
1.1 | 50 | |
| |
5.1 | 51 | Methods: Push (Webhook), Pull (Cron), Subscription. |
| |
1.1 | 52 | |
| |
5.1 | 53 | == Scaling == |
| |
1.1 | 54 | |
| |
5.1 | 55 | * **Vertical**: API servers, Workers, Caching. |
| 56 | * **Horizontal**: Adding more nodes to the federation. | ||
| |
1.1 | 57 | |
| |
2.1 | 58 | {{include reference="FactHarbor.Specification.Diagrams.Federation Architecture.WebHome"/}} |