Changes for page Federation & Decentralization
Last modified by Robert Schaub on 2026/02/08 08:26
Summary
-
Page properties (2 modified, 0 added, 0 removed)
Details
- Page properties
-
- Parent
-
... ... @@ -1,1 +1,1 @@ 1 - Archive.FactHarbor0\.9\.40.Specification.WebHome1 +FactHarbor.Specification.WebHome - Content
-
... ... @@ -3,7 +3,6 @@ 3 3 FactHarbor is designed to operate as a **federated network of nodes** rather than a single central server. 4 4 5 5 Decentralization provides: 6 - 7 7 * **Resilience** against censorship or political pressure 8 8 * **Autonomy** for local governance and moderation 9 9 * **Scalability** across many independent communities ... ... @@ -23,7 +23,6 @@ 23 23 == 2. Federated FactHarbor Nodes == 24 24 25 25 Each FactHarbor instance ("node") maintains: 26 - 27 27 * Its own database 28 28 * Its own AKEL instance 29 29 * Its own reviewers, experts, and contributors ... ... @@ -30,7 +30,6 @@ 30 30 * Its own governance rules 31 31 32 32 Nodes exchange structured information: 33 - 34 34 * Claims 35 35 * Scenarios 36 36 * Evidence metadata (not necessarily full files) ... ... @@ -44,14 +44,13 @@ 44 44 45 45 Every entity receives a globally unique, linkable identifier. 46 46 47 -**Format**: 44 +**Format**: 48 48 `factharbor://node_url/type/local_id` 49 49 50 -**Example**: 47 +**Example**: 51 51 `factharbor://factharbor.energy/claim/CLM-55812` 52 52 53 53 **Supported types**: 54 - 55 55 * `claim` 56 56 * `scenario` 57 57 * `evidence` ... ... @@ -60,7 +60,6 @@ 60 60 * `cluster` 61 61 62 62 **Properties**: 63 - 64 64 * Globally consistent 65 65 * Human-readable 66 66 * Hash-derived ... ... @@ -77,7 +77,6 @@ 77 77 === 4.1 Trust Levels === 78 78 79 79 **Trusted Nodes**: 80 - 81 81 * Claims auto-imported 82 82 * Scenarios accepted without re-review 83 83 * Evidence considered valid ... ... @@ -85,7 +85,6 @@ 85 85 * High synchronization priority 86 86 87 87 **Neutral Nodes**: 88 - 89 89 * Claims imported but flagged for review 90 90 * Scenarios require local validation 91 91 * Evidence requires re-assessment ... ... @@ -93,7 +93,6 @@ 93 93 * Normal synchronization priority 94 94 95 95 **Untrusted Nodes**: 96 - 97 97 * Claims quarantined, manual import only 98 98 * Scenarios rejected by default 99 99 * Evidence not accepted ... ... @@ -111,7 +111,6 @@ 111 111 === 4.3 Local Trust Authority === 112 112 113 113 Each node's governance team decides: 114 - 115 115 * Which nodes to trust 116 116 * Trust level criteria 117 117 * Trust escalation/degradation rules ... ... @@ -125,7 +125,6 @@ 125 125 === 5.1 What Nodes Share === 126 126 127 127 **Always shared** (if federation enabled): 128 - 129 129 * Claims and claim clusters 130 130 * Scenario structures 131 131 * Evidence metadata and content hashes ... ... @@ -132,7 +132,6 @@ 132 132 * Integrity signatures 133 133 134 134 **Optionally shared**: 135 - 136 136 * Full evidence files (large documents) 137 137 * Verdicts (nodes may choose to keep verdicts local) 138 138 * Vector embeddings ... ... @@ -140,7 +140,6 @@ 140 140 * AKEL distilled knowledge 141 141 142 142 **Never shared**: 143 - 144 144 * Internal user lists 145 145 * Reviewer comments and internal discussions 146 146 * Governance decisions and meeting notes ... ... @@ -150,7 +150,6 @@ 150 150 === 5.2 Large Evidence Files === 151 151 152 152 Evidence files are: 153 - 154 154 * Stored locally by default 155 155 * Referenced via global content hash 156 156 * Optionally served through IPFS ... ... @@ -157,6 +157,7 @@ 157 157 * Accessible via direct peer-to-peer transfer 158 158 * Can be stored in S3-compatible object storage 159 159 147 + 160 160 == 6. Synchronization Protocol == 161 161 162 162 Nodes exchange data using multiple synchronization methods: ... ... @@ -166,7 +166,6 @@ 166 166 **Mechanism**: Webhooks 167 167 168 168 When local content changes: 169 - 170 170 1. Node builds signed bundle 171 171 2. Sends webhook notification to subscribed nodes 172 172 3. Remote nodes fetch bundle ... ... @@ -179,7 +179,6 @@ 179 179 **Mechanism**: Scheduled polling 180 180 181 181 Nodes periodically: 182 - 183 183 1. Query partner nodes for updates 184 184 2. Fetch changed entities since last sync 185 185 3. Validate and import ... ... @@ -192,7 +192,6 @@ 192 192 **Mechanism**: WebSub-like protocol 193 193 194 194 Nodes subscribe to: 195 - 196 196 * Specific claim clusters 197 197 * Specific domains (medical, energy, etc.) 198 198 * Specific scenario types ... ... @@ -205,12 +205,12 @@ 205 205 === 6.4 Large Asset Transfer === 206 206 207 207 For files >10MB: 208 - 209 209 * S3-compatible object storage 210 210 * IPFS (content-addressed) 211 211 * Direct peer-to-peer transfer 212 212 * Chunked HTTP transfer with resume support 213 213 198 + 214 214 == 7. Federation Sync Workflow == 215 215 216 216 Complete synchronization sequence for creating and sharing new content: ... ... @@ -218,7 +218,6 @@ 218 218 === 7.1 Step 1: Local Node Creates New Versions === 219 219 220 220 User or AKEL creates: 221 - 222 222 * New claim version 223 223 * New scenario version 224 224 * New evidence version ... ... @@ -225,7 +225,6 @@ 225 225 * New verdict version 226 226 227 227 All changes tracked with: 228 - 229 229 * VersionID 230 230 * ParentVersionID 231 231 * AuthorType ... ... @@ -235,7 +235,6 @@ 235 235 === 7.2 Step 2: Federation Layer Builds Signed Bundle === 236 236 237 237 Federation layer packages: 238 - 239 239 * Entity data (claim, scenario, evidence metadata, verdict) 240 240 * Version lineage (ParentVersionID chain) 241 241 * Cryptographic signatures ... ... @@ -243,7 +243,6 @@ 243 243 * Trust metadata 244 244 245 245 Bundle format: 246 - 247 247 * JSON-LD for structured data 248 248 * Content-addressed hashes 249 249 * Digital signatures for integrity ... ... @@ -251,7 +251,6 @@ 251 251 === 7.3 Step 3: Bundle Includes Required Data === 252 252 253 253 Each bundle contains: 254 - 255 255 * **Claims**: Full claim text, classification, domain 256 256 * **Scenarios**: Definitions, assumptions, boundaries 257 257 * **Evidence metadata**: Source URLs, hashes, reliability scores (not always full files) ... ... @@ -262,13 +262,11 @@ 262 262 === 7.4 Step 4: Bundle Pushed to Trusted Neighbor Nodes === 263 263 264 264 Based on trust table: 265 - 266 266 * Push to **trusted nodes** immediately 267 267 * Queue for **neutral nodes** (batched) 268 268 * Skip **untrusted nodes** 269 269 270 270 Push methods: 271 - 272 272 * Webhook notification 273 273 * Direct API call 274 274 * Pub/Sub message queue ... ... @@ -276,7 +276,6 @@ 276 276 === 7.5 Step 5: Remote Nodes Validate Lineage and Signatures === 277 277 278 278 Receiving node: 279 - 280 280 1. Verifies cryptographic signatures 281 281 2. Validates version lineage (ParentVersionID chain) 282 282 3. Checks for conflicts with local data ... ... @@ -288,7 +288,6 @@ 288 288 === 7.6 Step 6: Accept or Branch Versions === 289 289 290 290 **Accept** (if validation passes): 291 - 292 292 * Import new versions 293 293 * Maintain provenance metadata 294 294 * Link to local related entities ... ... @@ -295,7 +295,6 @@ 295 295 * Update local indices 296 296 297 297 **Branch** (if conflict detected): 298 - 299 299 * Create parallel version tree 300 300 * Mark as "external branch" 301 301 * Allow local reviewers to merge or reject ... ... @@ -302,7 +302,6 @@ 302 302 * Preserve both version histories 303 303 304 304 **Reject** (if validation fails): 305 - 306 306 * Log rejection reason 307 307 * Notify source node (optional) 308 308 * Quarantine for manual review (optional) ... ... @@ -310,18 +310,17 @@ 310 310 === 7.7 Step 7: Local Re-evaluation Runs if Required === 311 311 312 312 After import, local node checks: 313 - 314 314 * Does new evidence affect existing verdicts? 315 315 * Do new scenarios require re-assessment? 316 316 * Are there contradictions with local content? 317 317 318 318 If yes: 319 - 320 320 * Trigger AKEL re-evaluation 321 321 * Queue for reviewer attention 322 322 * Update affected verdicts 323 323 * Notify users following related content 324 324 297 + 325 325 == 8. Cross-Node AI Knowledge Exchange == 326 326 327 327 Each node runs its own AKEL instance and may exchange AI-derived knowledge: ... ... @@ -329,31 +329,26 @@ 329 329 === 8.1 What Can Be Shared === 330 330 331 331 **Vector embeddings**: 332 - 333 333 * For cross-node claim clustering 334 334 * For semantic search alignment 335 335 * Never includes training data 336 336 337 337 **Canonical claim forms**: 338 - 339 339 * Normalized claim text 340 340 * Standard phrasing templates 341 341 * Domain-specific formulations 342 342 343 343 **Scenario templates**: 344 - 345 345 * Reusable scenario structures 346 346 * Common assumption patterns 347 347 * Evaluation method templates 348 348 349 349 **Contradiction alerts**: 350 - 351 351 * Detected conflicts between claims 352 352 * Evidence conflicts across nodes 353 353 * Scenario incompatibilities 354 354 355 355 **Metadata and insights**: 356 - 357 357 * Aggregate quality metrics 358 358 * Reliability signal extraction 359 359 * Bubble detection patterns ... ... @@ -386,10 +386,10 @@ 386 386 * No external AI control over local content 387 387 * Privacy-preserving knowledge exchange 388 388 357 + 389 389 == 9. Decentralized Processing == 390 390 391 391 Each node independently performs: 392 - 393 393 * AKEL processing 394 394 * Scenario drafting and validation 395 395 * Evidence review ... ... @@ -397,7 +397,6 @@ 397 397 * Truth landscape summarization 398 398 399 399 Nodes can specialize: 400 - 401 401 * Health-focused node with medical experts 402 402 * Energy-focused node with domain knowledge 403 403 * Small node delegating scenario libraries to partners ... ... @@ -404,16 +404,15 @@ 404 404 * Regional node with language/culture specialization 405 405 406 406 Optional data sharing includes: 407 - 408 408 * Embeddings for clustering 409 409 * Claim clusters for alignment 410 410 * Scenario templates for efficiency 411 411 * Verdict comparison metadata 412 412 379 + 413 413 == 10. Scaling to Thousands of Users == 414 414 415 415 Nodes scale independently through: 416 - 417 417 * Horizontally scalable API servers 418 418 * Worker pools for AKEL tasks 419 419 * Hybrid storage (local + S3/IPFS) ... ... @@ -423,7 +423,6 @@ 423 423 Federation allows effectively unlimited horizontal scaling by adding new nodes. 424 424 425 425 Communities may form: 426 - 427 427 * Domain-specific nodes (epidemiology, energy, climate) 428 428 * Language or region-based nodes 429 429 * NGO or institutional nodes ... ... @@ -431,7 +431,6 @@ 431 431 * Academic research nodes 432 432 433 433 Nodes cooperate through: 434 - 435 435 * Scenario library sharing 436 436 * Shared or overlapping claim clusters 437 437 * Expert delegation between nodes ... ... @@ -438,6 +438,7 @@ 438 438 * Distributed AKEL task support 439 439 * Cross-node quality audits 440 440 405 + 441 441 == 11. Federation and Release 1.0 == 442 442 443 443 **POC**: Single node, optional federation experiments ... ... @@ -445,7 +445,6 @@ 445 445 **Beta 0**: 2-3 nodes, basic federation protocol 446 446 447 447 **Release 1.0**: Full federation support with: 448 - 449 449 * Robust synchronization protocol 450 450 * Trust model implementation 451 451 * Cross-node AI knowledge exchange ... ... @@ -453,9 +453,11 @@ 453 453 * Distributed audit collaboration 454 454 * Inter-node expert consultation 455 455 420 + 456 456 == 12. Related Pages == 457 457 458 -* [[AKEL (AI Knowledge Extraction Layer)>> Archive.FactHarbor.Specification.AI Knowledge Extraction Layer (AKEL).WebHome]]423 +* [[AKEL (AI Knowledge Extraction Layer)>>FactHarbor.Specification.AI Knowledge Extraction Layer (AKEL).WebHome]] 459 459 * [[Data Model>>FactHarbor.Specification.Data Model.WebHome]] 460 460 * [[Architecture>>FactHarbor.Specification.Architecture.WebHome]] 461 461 * [[Workflows>>FactHarbor.Specification.Workflows.WebHome]] 427 +