Wiki source code of Federation & Decentralization
Last modified by Robert Schaub on 2025/12/24 20:33
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
1.1 | 1 | = Federation & Decentralization = |
| 2 | |||
| |
7.1 | 3 | FactHarbor is designed to operate as a **federated network of nodes** rather than a single central server. |
| |
1.1 | 4 | |
| |
7.1 | 5 | Decentralization provides: |
| |
7.4 | 6 | |
| |
7.1 | 7 | * **Resilience** against censorship or political pressure |
| 8 | * **Autonomy** for local governance and moderation | ||
| 9 | * **Scalability** across many independent communities | ||
| 10 | * **Trust** without centralized control | ||
| 11 | * **Domain specialization** (health-focused nodes, energy-focused nodes, etc.) | ||
| |
1.1 | 12 | |
| |
7.1 | 13 | FactHarbor draws inspiration from the Fediverse but uses stronger structure, versioning, and integrity guarantees. |
| |
1.1 | 14 | |
| |
6.1 | 15 | ---- |
| 16 | |||
| |
7.1 | 17 | == Federated FactHarbor Nodes == |
| |
6.1 | 18 | |
| |
7.1 | 19 | Each FactHarbor instance ("node") maintains: |
| |
7.4 | 20 | |
| |
7.1 | 21 | * Its own database |
| |
6.1 | 22 | * Its own AKEL instance |
| |
7.1 | 23 | * Its own reviewers, experts, and contributors |
| 24 | * Its own governance rules | ||
| |
1.1 | 25 | |
| |
7.1 | 26 | Nodes exchange structured information: |
| |
7.4 | 27 | |
| |
6.1 | 28 | * Claims |
| 29 | * Scenarios | ||
| |
7.1 | 30 | * Evidence metadata (not necessarily full files) |
| |
6.1 | 31 | * Verdicts (optional) |
| |
7.1 | 32 | * Hashes and signatures for integrity |
| |
1.1 | 33 | |
| |
7.1 | 34 | Nodes choose which external nodes they trust. |
| |
1.1 | 35 | |
| |
6.1 | 36 | ---- |
| |
1.1 | 37 | |
| |
7.1 | 38 | == Global Identifiers == |
| |
1.1 | 39 | |
| |
7.1 | 40 | Every entity receives a globally unique, linkable identifier. |
| |
1.1 | 41 | |
| |
7.1 | 42 | **Format**: |
| 43 | `factharbor://node_url/type/local_id` | ||
| |
1.1 | 44 | |
| |
7.1 | 45 | **Example**: |
| 46 | `factharbor://factharbor.energy/claim/CLM-55812` | ||
| |
1.1 | 47 | |
| |
7.1 | 48 | **Supported types**: |
| |
7.4 | 49 | |
| |
7.1 | 50 | * `claim` |
| 51 | * `scenario` | ||
| 52 | * `evidence` | ||
| 53 | * `verdict` | ||
| 54 | * `user` (optional) | ||
| 55 | * `cluster` | ||
| |
1.1 | 56 | |
| |
7.1 | 57 | **Properties**: |
| |
7.4 | 58 | |
| |
6.1 | 59 | * Globally consistent |
| 60 | * Human-readable | ||
| 61 | * Hash-derived | ||
| |
7.1 | 62 | * Independent of database internals |
| 63 | * URL-resolvable (future enhancement) | ||
| |
1.1 | 64 | |
| |
7.1 | 65 | This allows cross-node references and prevents identifier collisions in federated environments. |
| 66 | |||
| |
6.1 | 67 | ---- |
| |
1.1 | 68 | |
| |
7.1 | 69 | == Trust Model == |
| |
1.1 | 70 | |
| |
7.1 | 71 | Each node maintains a **trust table** defining relationships with other nodes: |
| |
1.1 | 72 | |
| |
7.1 | 73 | === Trust Levels === |
| |
1.1 | 74 | |
| |
7.1 | 75 | **Trusted Nodes**: |
| |
7.4 | 76 | |
| |
7.1 | 77 | * Claims auto-imported |
| 78 | * Scenarios accepted without re-review | ||
| 79 | * Evidence considered valid | ||
| 80 | * Verdicts displayed to users | ||
| 81 | * High synchronization priority | ||
| |
1.1 | 82 | |
| |
7.1 | 83 | **Neutral Nodes**: |
| |
7.4 | 84 | |
| |
7.1 | 85 | * Claims imported but flagged for review |
| 86 | * Scenarios require local validation | ||
| 87 | * Evidence requires re-assessment | ||
| 88 | * Verdicts shown with "external node" disclaimer | ||
| 89 | * Normal synchronization priority | ||
| |
6.1 | 90 | |
| |
7.1 | 91 | **Untrusted Nodes**: |
| |
7.4 | 92 | |
| |
7.1 | 93 | * Claims quarantined, manual import only |
| 94 | * Scenarios rejected by default | ||
| 95 | * Evidence not accepted | ||
| 96 | * Verdicts not displayed | ||
| 97 | * No automatic synchronization | ||
| |
6.1 | 98 | |
| |
7.1 | 99 | === Trust Affects === |
| |
6.1 | 100 | |
| |
7.1 | 101 | * **Auto-import**: Whether claims/scenarios are automatically added |
| 102 | * **Re-review requirements**: Whether local reviewers must validate | ||
| 103 | * **Verdict display**: Whether external verdicts are shown to users | ||
| 104 | * **Synchronization frequency**: How often data is exchanged | ||
| 105 | * **Reputation signals**: How external reputation is interpreted | ||
| 106 | |||
| 107 | === Local Trust Authority === | ||
| 108 | |||
| 109 | Each node's governance team decides: | ||
| |
7.4 | 110 | |
| |
7.1 | 111 | * Which nodes to trust |
| 112 | * Trust level criteria | ||
| 113 | * Trust escalation/degradation rules | ||
| 114 | * Dispute resolution with partner nodes | ||
| 115 | |||
| 116 | Trust is **local and autonomous** - no global trust registry exists. | ||
| 117 | |||
| |
6.1 | 118 | ---- |
| 119 | |||
| |
7.1 | 120 | == Data Sharing Model == |
| |
6.1 | 121 | |
| |
7.1 | 122 | === What Nodes Share === |
| |
6.1 | 123 | |
| |
7.1 | 124 | **Always shared** (if federation enabled): |
| |
7.4 | 125 | |
| |
7.1 | 126 | * Claims and claim clusters |
| 127 | * Scenario structures | ||
| 128 | * Evidence metadata and content hashes | ||
| 129 | * Integrity signatures | ||
| |
6.1 | 130 | |
| |
7.1 | 131 | **Optionally shared**: |
| |
7.4 | 132 | |
| |
7.1 | 133 | * Full evidence files (large documents) |
| 134 | * Verdicts (nodes may choose to keep verdicts local) | ||
| 135 | * Vector embeddings | ||
| 136 | * Scenario templates | ||
| 137 | * AKEL distilled knowledge | ||
| |
6.1 | 138 | |
| |
7.1 | 139 | **Never shared**: |
| |
7.4 | 140 | |
| |
7.1 | 141 | * Internal user lists |
| 142 | * Reviewer comments and internal discussions | ||
| 143 | * Governance decisions and meeting notes | ||
| 144 | * Access control data | ||
| 145 | * Private or sensitive content marked as local-only | ||
| |
6.1 | 146 | |
| |
7.1 | 147 | === Large Evidence Files === |
| |
6.1 | 148 | |
| |
7.1 | 149 | Evidence files are: |
| |
7.4 | 150 | |
| |
7.1 | 151 | * Stored locally by default |
| 152 | * Referenced via global content hash | ||
| 153 | * Optionally served through IPFS | ||
| 154 | * Accessible via direct peer-to-peer transfer | ||
| 155 | * Can be stored in S3-compatible object storage | ||
| 156 | |||
| |
6.1 | 157 | ---- |
| 158 | |||
| |
7.1 | 159 | == Synchronization Protocol == |
| |
6.1 | 160 | |
| |
7.1 | 161 | Nodes exchange data using multiple synchronization methods: |
| |
6.1 | 162 | |
| |
7.1 | 163 | === Push-Based Synchronization === |
| |
6.1 | 164 | |
| |
7.1 | 165 | **Mechanism**: Webhooks |
| |
6.1 | 166 | |
| |
7.1 | 167 | When local content changes: |
| |
7.4 | 168 | |
| |
7.1 | 169 | 1. Node builds signed bundle |
| 170 | 2. Sends webhook notification to subscribed nodes | ||
| 171 | 3. Remote nodes fetch bundle | ||
| 172 | 4. Remote nodes validate and import | ||
| |
6.1 | 173 | |
| |
7.1 | 174 | **Use case**: Real-time updates for trusted partners |
| |
6.1 | 175 | |
| |
7.1 | 176 | === Pull-Based Synchronization === |
| |
6.1 | 177 | |
| |
7.1 | 178 | **Mechanism**: Scheduled polling |
| 179 | |||
| 180 | Nodes periodically: | ||
| |
7.4 | 181 | |
| |
7.1 | 182 | 1. Query partner nodes for updates |
| 183 | 2. Fetch changed entities since last sync | ||
| 184 | 3. Validate and import | ||
| 185 | 4. Store sync checkpoint | ||
| 186 | |||
| 187 | **Use case**: Regular batch updates, lower trust nodes | ||
| 188 | |||
| 189 | === Subscription-Based Synchronization === | ||
| 190 | |||
| 191 | **Mechanism**: WebSub-like protocol | ||
| 192 | |||
| 193 | Nodes subscribe to: | ||
| |
7.4 | 194 | |
| |
7.1 | 195 | * Specific claim clusters |
| 196 | * Specific domains (medical, energy, etc.) | ||
| 197 | * Specific scenario types | ||
| 198 | * Verdict updates | ||
| 199 | |||
| 200 | Publisher pushes updates only to subscribers. | ||
| 201 | |||
| 202 | **Use case**: Selective federation, domain specialization | ||
| 203 | |||
| 204 | === Large Asset Transfer === | ||
| 205 | |||
| 206 | For files >10MB: | ||
| |
7.4 | 207 | |
| |
7.1 | 208 | * S3-compatible object storage |
| 209 | * IPFS (content-addressed) | ||
| 210 | * Direct peer-to-peer transfer | ||
| 211 | * Chunked HTTP transfer with resume support | ||
| 212 | |||
| |
6.1 | 213 | ---- |
| 214 | |||
| |
7.1 | 215 | == Federation Sync Workflow == |
| |
6.1 | 216 | |
| |
7.1 | 217 | Complete synchronization sequence for creating and sharing new content: |
| |
6.1 | 218 | |
| |
7.1 | 219 | === Step 1: Local Node Creates New Versions === |
| |
6.1 | 220 | |
| |
7.1 | 221 | User or AKEL creates: |
| |
7.4 | 222 | |
| |
7.1 | 223 | * New claim version |
| 224 | * New scenario version | ||
| 225 | * New evidence version | ||
| 226 | * New verdict version | ||
| |
6.1 | 227 | |
| |
7.1 | 228 | All changes tracked with: |
| |
7.4 | 229 | |
| |
7.1 | 230 | * VersionID |
| 231 | * ParentVersionID | ||
| 232 | * AuthorType | ||
| 233 | * Timestamp | ||
| 234 | * JustificationText | ||
| |
6.1 | 235 | |
| |
7.1 | 236 | === Step 2: Federation Layer Builds Signed Bundle === |
| 237 | |||
| 238 | Federation layer packages: | ||
| |
7.4 | 239 | |
| |
7.1 | 240 | * Entity data (claim, scenario, evidence metadata, verdict) |
| 241 | * Version lineage (ParentVersionID chain) | ||
| 242 | * Cryptographic signatures | ||
| 243 | * Node provenance information | ||
| 244 | * Trust metadata | ||
| 245 | |||
| 246 | Bundle format: | ||
| |
7.4 | 247 | |
| |
7.1 | 248 | * JSON-LD for structured data |
| 249 | * Content-addressed hashes | ||
| 250 | * Digital signatures for integrity | ||
| 251 | |||
| 252 | === Step 3: Bundle Includes Required Data === | ||
| 253 | |||
| 254 | Each bundle contains: | ||
| |
7.4 | 255 | |
| |
7.1 | 256 | * **Claims**: Full claim text, classification, domain |
| 257 | * **Scenarios**: Definitions, assumptions, boundaries | ||
| 258 | * **Evidence metadata**: Source URLs, hashes, reliability scores (not always full files) | ||
| 259 | * **Verdicts**: Likelihood ranges, uncertainty, reasoning chains | ||
| 260 | * **Lineage**: Version history, parent relationships | ||
| 261 | * **Signatures**: Cryptographic proof of origin | ||
| 262 | |||
| 263 | === Step 4: Bundle Pushed to Trusted Neighbor Nodes === | ||
| 264 | |||
| 265 | Based on trust table: | ||
| |
7.4 | 266 | |
| |
7.1 | 267 | * Push to **trusted nodes** immediately |
| 268 | * Queue for **neutral nodes** (batched) | ||
| 269 | * Skip **untrusted nodes** | ||
| 270 | |||
| 271 | Push methods: | ||
| |
7.4 | 272 | |
| |
7.1 | 273 | * Webhook notification |
| 274 | * Direct API call | ||
| 275 | * Pub/Sub message queue | ||
| 276 | |||
| 277 | === Step 5: Remote Nodes Validate Lineage and Signatures === | ||
| 278 | |||
| 279 | Receiving node: | ||
| |
7.4 | 280 | |
| |
7.1 | 281 | 1. Verifies cryptographic signatures |
| 282 | 2. Validates version lineage (ParentVersionID chain) | ||
| 283 | 3. Checks for conflicts with local data | ||
| 284 | 4. Validates data structure and required fields | ||
| 285 | 5. Applies local trust policies | ||
| 286 | |||
| 287 | Validation failures → reject or quarantine bundle | ||
| 288 | |||
| 289 | === Step 6: Accept or Branch Versions === | ||
| 290 | |||
| 291 | **Accept** (if validation passes): | ||
| |
7.4 | 292 | |
| |
7.1 | 293 | * Import new versions |
| 294 | * Maintain provenance metadata | ||
| 295 | * Link to local related entities | ||
| 296 | * Update local indices | ||
| 297 | |||
| 298 | **Branch** (if conflict detected): | ||
| |
7.4 | 299 | |
| |
7.1 | 300 | * Create parallel version tree |
| 301 | * Mark as "external branch" | ||
| 302 | * Allow local reviewers to merge or reject | ||
| 303 | * Preserve both version histories | ||
| 304 | |||
| 305 | **Reject** (if validation fails): | ||
| |
7.4 | 306 | |
| |
7.1 | 307 | * Log rejection reason |
| 308 | * Notify source node (optional) | ||
| 309 | * Quarantine for manual review (optional) | ||
| 310 | |||
| 311 | === Step 7: Local Re-evaluation Runs if Required === | ||
| 312 | |||
| 313 | After import, local node checks: | ||
| |
7.4 | 314 | |
| |
7.1 | 315 | * Does new evidence affect existing verdicts? |
| 316 | * Do new scenarios require re-assessment? | ||
| 317 | * Are there contradictions with local content? | ||
| 318 | |||
| 319 | If yes: | ||
| |
7.4 | 320 | |
| |
7.1 | 321 | * Trigger AKEL re-evaluation |
| 322 | * Queue for reviewer attention | ||
| 323 | * Update affected verdicts | ||
| 324 | * Notify users following related content | ||
| 325 | |||
| |
6.1 | 326 | ---- |
| 327 | |||
| |
7.1 | 328 | == Cross-Node AI Knowledge Exchange == |
| |
6.1 | 329 | |
| |
7.1 | 330 | Each node runs its own AKEL instance and may exchange AI-derived knowledge: |
| |
6.1 | 331 | |
| |
7.1 | 332 | === What Can Be Shared === |
| |
6.1 | 333 | |
| |
7.1 | 334 | **Vector embeddings**: |
| |
7.4 | 335 | |
| |
7.1 | 336 | * For cross-node claim clustering |
| 337 | * For semantic search alignment | ||
| 338 | * Never includes training data | ||
| |
6.1 | 339 | |
| |
7.1 | 340 | **Canonical claim forms**: |
| |
7.4 | 341 | |
| |
7.1 | 342 | * Normalized claim text |
| 343 | * Standard phrasing templates | ||
| 344 | * Domain-specific formulations | ||
| |
6.1 | 345 | |
| |
7.1 | 346 | **Scenario templates**: |
| |
7.4 | 347 | |
| |
7.1 | 348 | * Reusable scenario structures |
| 349 | * Common assumption patterns | ||
| 350 | * Evaluation method templates | ||
| |
6.1 | 351 | |
| |
7.1 | 352 | **Contradiction alerts**: |
| |
7.4 | 353 | |
| |
7.1 | 354 | * Detected conflicts between claims |
| 355 | * Evidence conflicts across nodes | ||
| 356 | * Scenario incompatibilities | ||
| |
6.1 | 357 | |
| |
7.1 | 358 | **Metadata and insights**: |
| |
7.4 | 359 | |
| |
7.1 | 360 | * Aggregate quality metrics |
| 361 | * Reliability signal extraction | ||
| 362 | * Bubble detection patterns | ||
| 363 | |||
| 364 | === What Can NEVER Be Shared === | ||
| 365 | |||
| 366 | **Model weights**: No sharing of trained model parameters | ||
| 367 | |||
| 368 | **Training data**: No sharing of full training datasets | ||
| 369 | |||
| 370 | **Local governance overrides**: AKEL suggestions can be overridden locally | ||
| 371 | |||
| 372 | **User behavior data**: No cross-node tracking | ||
| 373 | |||
| 374 | **Internal review discussions**: Private content stays private | ||
| 375 | |||
| 376 | === Benefits of AI Knowledge Exchange === | ||
| 377 | |||
| 378 | * Reduced duplication across nodes | ||
| 379 | * Improved claim clustering accuracy | ||
| 380 | * Faster contradiction detection | ||
| 381 | * Shared scenario libraries | ||
| 382 | * Cross-node quality improvements | ||
| 383 | |||
| 384 | === Local Control Maintained === | ||
| 385 | |||
| 386 | * Nodes accept or reject shared AI knowledge | ||
| 387 | * Human reviewers can override any AKEL suggestion | ||
| 388 | * Local governance always has final authority | ||
| 389 | * No external AI control over local content | ||
| 390 | * Privacy-preserving knowledge exchange | ||
| 391 | |||
| |
6.1 | 392 | ---- |
| 393 | |||
| |
7.1 | 394 | == Decentralized Processing == |
| |
6.1 | 395 | |
| |
7.1 | 396 | Each node independently performs: |
| |
7.4 | 397 | |
| |
7.1 | 398 | * AKEL processing |
| 399 | * Scenario drafting and validation | ||
| 400 | * Evidence review | ||
| 401 | * Verdict calculation | ||
| 402 | * Truth landscape summarization | ||
| |
6.1 | 403 | |
| |
7.1 | 404 | Nodes can specialize: |
| |
7.4 | 405 | |
| |
7.1 | 406 | * Health-focused node with medical experts |
| 407 | * Energy-focused node with domain knowledge | ||
| 408 | * Small node delegating scenario libraries to partners | ||
| 409 | * Regional node with language/culture specialization | ||
| |
6.1 | 410 | |
| |
7.1 | 411 | Optional data sharing includes: |
| |
7.4 | 412 | |
| |
7.1 | 413 | * Embeddings for clustering |
| 414 | * Claim clusters for alignment | ||
| 415 | * Scenario templates for efficiency | ||
| 416 | * Verdict comparison metadata | ||
| |
6.1 | 417 | |
| |
7.1 | 418 | ---- |
| |
6.1 | 419 | |
| |
7.1 | 420 | == Scaling to Thousands of Users == |
| |
6.1 | 421 | |
| |
7.1 | 422 | Nodes scale independently through: |
| |
7.4 | 423 | |
| |
7.1 | 424 | * Horizontally scalable API servers |
| 425 | * Worker pools for AKEL tasks | ||
| 426 | * Hybrid storage (local + S3/IPFS) | ||
| 427 | * Redis caching for performance | ||
| 428 | * Sharded or partitioned databases | ||
| 429 | |||
| 430 | Federation allows effectively unlimited horizontal scaling by adding new nodes. | ||
| 431 | |||
| 432 | Communities may form: | ||
| |
7.4 | 433 | |
| |
7.1 | 434 | * Domain-specific nodes (epidemiology, energy, climate) |
| 435 | * Language or region-based nodes | ||
| 436 | * NGO or institutional nodes | ||
| 437 | * Private organizational nodes | ||
| 438 | * Academic research nodes | ||
| 439 | |||
| |
6.1 | 440 | Nodes cooperate through: |
| |
7.4 | 441 | |
| |
7.1 | 442 | * Scenario library sharing |
| 443 | * Shared or overlapping claim clusters | ||
| 444 | * Expert delegation between nodes | ||
| 445 | * Distributed AKEL task support | ||
| 446 | * Cross-node quality audits | ||
| |
6.1 | 447 | |
| |
7.1 | 448 | ---- |
| |
6.1 | 449 | |
| |
7.1 | 450 | == Federation and Release 1.0 == |
| 451 | |||
| 452 | **POC**: Single node, optional federation experiments | ||
| 453 | |||
| 454 | **Beta 0**: 2-3 nodes, basic federation protocol | ||
| 455 | |||
| 456 | **Release 1.0**: Full federation support with: | ||
| |
7.4 | 457 | |
| |
7.1 | 458 | * Robust synchronization protocol |
| 459 | * Trust model implementation | ||
| 460 | * Cross-node AI knowledge exchange | ||
| 461 | * Federated search and discovery | ||
| 462 | * Distributed audit collaboration | ||
| 463 | * Inter-node expert consultation | ||
| 464 | |||
| |
6.1 | 465 | ---- |
| 466 | |||
| |
7.1 | 467 | == Related Pages == |
| |
6.1 | 468 | |
| |
7.13 | 469 | * [[AKEL (AI Knowledge Extraction Layer)>>Archive.FactHarbor V0\.9\.18 copy.Specification.AI Knowledge Extraction Layer (AKEL).WebHome]] |
| |
7.15 | 470 | * [[Data Model>>Archive.FactHarbor V0\.9\.18 copy.Specification.Data Model.WebHome]] |
| |
7.14 | 471 | * [[Architecture>>Archive.FactHarbor V0\.9\.18 copy.Specification.Architecture.WebHome]] |
| |
7.16 | 472 | * [[Workflows>>Archive.FactHarbor V0\.9\.18 copy.Specification.Workflows.WebHome]] |