Changes for page Federation & Decentralization
Last modified by Robert Schaub on 2025/12/24 20:33
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -3,221 +3,56 @@ 3 3 FactHarbor is designed as a network of independent nodes rather than a single centralized service. 4 4 This provides resilience, local autonomy, and virtually unlimited scalability. 5 5 6 - Eachnode remains fully functional on its ownwhileparticipating in a shared global knowledgegraph.6 +== Purpose of Federation == 7 7 8 ----- 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). 9 9 10 -= Purpose ofFederation=14 +== Federated Node Model == 11 11 12 -A federated architecture enables: 13 - 14 -* Resilience against censorship or political pressure 15 -* Local governance and moderation autonomy 16 -* Scalability by adding more nodes, not bigger servers 17 -* Shared knowledge structures without central authority 18 -* Domain specialization (e.g., health-focused node, energy-focused node) 19 -* Cross-node collaboration while preserving independence 20 - 21 -FactHarbor takes inspiration from the Fediverse but uses stronger structure, integrity guarantees, and version lineage. 22 - 23 ----- 24 - 25 -= Federated Node Model = 26 - 27 27 Each FactHarbor node maintains: 17 +* Local PostgreSQL database, Vector DB, and Object Storage. 18 +* Local AKEL instance. 19 +* Local Reviewers and Governance policies. 28 28 29 -* Its own PostgreSQL database 30 -* Its own vector database 31 -* Its own object storage 32 -* Its own AKEL instance 33 -* Its own reviewers, experts, and moderators 34 -* Its own trust and governance policies 21 +Nodes exchange structured objects (Claims, Scenarios, Evidence metadata, Verdicts) via signed bundles. 35 35 36 - Nodesexchangestructuredobjects:23 +== Global Identifiers == 37 37 38 -* Claims 39 -* Scenarios 40 -* Evidence metadata (not raw files unless elected) 41 -* Verdicts (optional) 42 -* Integrity hashes and signatures 25 +Format: ``factharbor://<node>/<type>/<local_id>`` 43 43 44 - Nodes decide individuallywhich external nodestotrust.27 +Example: ``factharbor://factharbor.energy/claim/CLM-55812`` 45 45 46 --- --29 +Identifiers are globally consistent, human-readable, and hash-derived. 47 47 48 -= GlobalIdentifiers=31 +== Data Sharing Model == 49 49 50 -Each entity receives a globally unique ID. 33 +* **Shared**: Claims, Scenario structures, Evidence metadata, Verdicts, Integrity hashes. 34 +* **Not Shared**: Local users, Review discussions, Internal notes, Private evidence. 51 51 52 -Format: 53 -``factharbor://<node>/<type>/<local_id>`` 36 +== Trust Model == 54 54 55 -Example: 56 -``factharbor://factharbor.energy/claim/CLM-55812`` 38 +Nodes maintain a **trust table** (Trusted, Neutral, Untrusted). This influences auto-import rules, re-review requirements, and visibility. 57 57 58 - Typesinclude:40 +== Decentralized Processing == 59 59 60 -* claim 61 -* scenario 62 -* evidence 63 -* verdict 64 -* user (optional) 65 -* cluster 42 +Each node performs its own AKEL processing, drafting, and verdict calculation. Nodes may specialize in specific domains (e.g., Medical Node). 66 66 67 - Identifiersare:44 +== Synchronization Protocol == 68 68 69 - * Globallyconsistent70 -* Human-readable71 -* Hash-derived72 -* Independentfrominternal databaseIDs46 +Nodes exchange **Version Bundles** containing: 47 +* Claims, Scenarios, Metadata. 48 +* Merkle-tree lineage. 49 +* Cryptographic signatures. 73 73 74 - ----51 +Methods: Push (Webhook), Pull (Cron), Subscription. 75 75 76 -= DataSharingModel=53 +== Scaling == 77 77 78 -Nodes share: 55 +* **Vertical**: API servers, Workers, Caching. 56 +* **Horizontal**: Adding more nodes to the federation. 79 79 80 -* Claims 81 -* Scenario structures 82 -* Evidence metadata + content hashes 83 -* Optional verdicts 84 -* Integrity metadata 85 - 86 -Nodes **do not** share: 87 - 88 -* Local users 89 -* Review discussions 90 -* Internal moderation notes 91 -* Private evidence 92 - 93 -Large assets may use: 94 - 95 -* Local object storage 96 -* S3-compatible buckets 97 -* IPFS for cross-node replication (optional) 98 - 99 ----- 100 - 101 -= Trust Model = 102 - 103 -Each node maintains a **trust table**: 104 - 105 -* Trusted nodes 106 -* Neutral nodes 107 -* Untrusted nodes 108 - 109 -Trust influences: 110 - 111 -* Whether claims are auto-imported 112 -* Whether scenarios are accepted without re-review 113 -* Whether evidence requires new validation 114 -* Whether external verdicts are visible to users 115 - 116 -Reputation is local but can be mapped with trust-weighting. 117 - 118 ----- 119 - 120 -= Decentralized Processing = 121 - 122 -Each node independently performs: 123 - 124 -* AKEL processing 125 -* Scenario drafting 126 -* Evidence review 127 -* Verdict calculation 128 -* Summary generation 129 -* Re-evaluation 130 - 131 -Nodes may specialize: 132 - 133 -* medical node 134 -* psychology node 135 -* climate node 136 -* small node delegating expert review to trusted partners 137 - 138 -Optional cross-node data sharing includes: 139 - 140 -* Embeddings 141 -* Claim clusters 142 -* Scenario templates 143 -* Verdict comparison metadata 144 -* Contradiction alerts 145 - 146 ----- 147 - 148 -= Cross-Node AI Knowledge Exchange = 149 - 150 -Nodes may exchange: 151 - 152 -* Embeddings for clustering 153 -* Canonical claim forms 154 -* Scenario templates 155 -* Reliability hints 156 -* Contradiction alerts 157 -* Lightweight model insights (NOT weights) 158 - 159 -AKEL **never**: 160 - 161 -* Shares model weights 162 -* Automatically replaces local reviewer decisions 163 -* Accepts untrusted automated content 164 - 165 ----- 166 - 167 -= Synchronization Protocol = 168 - 169 -Nodes periodically exchange version bundles: 170 - 171 -* Claims 172 -* Scenarios 173 -* Evidence metadata + hashes 174 -* Optional verdicts 175 -* Templates 176 -* Embeddings (optional) 177 -* AKEL distilled knowledge summaries (optional) 178 - 179 -Sync methods: 180 - 181 -* Push (webhook) 182 -* Pull (cron) 183 -* Subscription (WebSub-like) 184 - 185 -Large assets may be transferred via: 186 - 187 -* S3-compatible file transfer 188 -* IPFS 189 -* Peer-to-peer 190 - 191 ----- 192 - 193 -= Scaling to Thousands of Users = 194 - 195 -Nodes scale independently: 196 - 197 -* horizontally scaled API servers 198 -* background worker pools 199 -* GPU queues for AKEL 200 -* caching (Redis) 201 -* sharded databases 202 - 203 -The network scales horizontally by adding more nodes. 204 - 205 -Communities can form: 206 - 207 -* Domain-specific nodes 208 -* Region/language nodes 209 -* NGO/academic nodes 210 -* Private organization nodes 211 - 212 -Nodes cooperate through: 213 - 214 -* Shared scenario libraries 215 -* Overlapping claim clusters 216 -* Expert delegation 217 -* Distributed AKEL tasks 218 - 219 ----- 220 - 221 -= Diagram References = 222 - 223 -{{include reference="FactHarbor.Archive.Diagrams v0\.8q.Federation Architecture.WebHome"/}} 58 +{{include reference="FactHarbor.Specification.Diagrams.Federation Architecture.WebHome"/}}