Changes for page Federation & Decentralization
Last modified by Robert Schaub on 2025/12/24 20:35
Summary
-
Page properties (2 modified, 0 added, 0 removed)
Details
- Page properties
-
- Parent
-
... ... @@ -1,1 +1,1 @@ 1 -Test.FactHarborV09.Specification.WebHome 1 +Test.FactHarbor V0\.9\.23 Lost Data.Specification.WebHome - Content
-
... ... @@ -3,6 +3,7 @@ 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 + 6 6 * **Resilience** against censorship or political pressure 7 7 * **Autonomy** for local governance and moderation 8 8 * **Scalability** across many independent communities ... ... @@ -15,6 +15,7 @@ 15 15 == 1. Federated FactHarbor Nodes == 16 16 17 17 Each FactHarbor instance ("node") maintains: 19 + 18 18 * Its own database 19 19 * Its own AKEL instance 20 20 * Its own reviewers, experts, and contributors ... ... @@ -21,6 +21,7 @@ 21 21 * Its own governance rules 22 22 23 23 Nodes exchange structured information: 26 + 24 24 * Claims 25 25 * Scenarios 26 26 * Evidence metadata (not necessarily full files) ... ... @@ -41,6 +41,7 @@ 41 41 `factharbor://factharbor.energy/claim/CLM-55812` 42 42 43 43 **Supported types**: 47 + 44 44 * `claim` 45 45 * `scenario` 46 46 * `evidence` ... ... @@ -49,6 +49,7 @@ 49 49 * `cluster` 50 50 51 51 **Properties**: 56 + 52 52 * Globally consistent 53 53 * Human-readable 54 54 * Hash-derived ... ... @@ -65,6 +65,7 @@ 65 65 === 3.1 Trust Levels === 66 66 67 67 **Trusted Nodes**: 73 + 68 68 * Claims auto-imported 69 69 * Scenarios accepted without re-review 70 70 * Evidence considered valid ... ... @@ -72,6 +72,7 @@ 72 72 * High synchronization priority 73 73 74 74 **Neutral Nodes**: 81 + 75 75 * Claims imported but flagged for review 76 76 * Scenarios require local validation 77 77 * Evidence requires re-assessment ... ... @@ -79,6 +79,7 @@ 79 79 * Normal synchronization priority 80 80 81 81 **Untrusted Nodes**: 89 + 82 82 * Claims quarantined, manual import only 83 83 * Scenarios rejected by default 84 84 * Evidence not accepted ... ... @@ -96,6 +96,7 @@ 96 96 === 3.3 Local Trust Authority === 97 97 98 98 Each node's governance team decides: 107 + 99 99 * Which nodes to trust 100 100 * Trust level criteria 101 101 * Trust escalation/degradation rules ... ... @@ -109,6 +109,7 @@ 109 109 === 4.1 What Nodes Share === 110 110 111 111 **Always shared** (if federation enabled): 121 + 112 112 * Claims and claim clusters 113 113 * Scenario structures 114 114 * Evidence metadata and content hashes ... ... @@ -115,6 +115,7 @@ 115 115 * Integrity signatures 116 116 117 117 **Optionally shared**: 128 + 118 118 * Full evidence files (large documents) 119 119 * Verdicts (nodes may choose to keep verdicts local) 120 120 * Vector embeddings ... ... @@ -122,6 +122,7 @@ 122 122 * AKEL distilled knowledge 123 123 124 124 **Never shared**: 136 + 125 125 * Internal user lists 126 126 * Reviewer comments and internal discussions 127 127 * Governance decisions and meeting notes ... ... @@ -131,6 +131,7 @@ 131 131 === 4.2 Large Evidence Files === 132 132 133 133 Evidence files are: 146 + 134 134 * Stored locally by default 135 135 * Referenced via global content hash 136 136 * Optionally served through IPFS ... ... @@ -137,7 +137,6 @@ 137 137 * Accessible via direct peer-to-peer transfer 138 138 * Can be stored in S3-compatible object storage 139 139 140 - 141 141 == 5. Synchronization Protocol == 142 142 143 143 Nodes exchange data using multiple synchronization methods: ... ... @@ -147,6 +147,7 @@ 147 147 **Mechanism**: Webhooks 148 148 149 149 When local content changes: 162 + 150 150 1. Node builds signed bundle 151 151 2. Sends webhook notification to subscribed nodes 152 152 3. Remote nodes fetch bundle ... ... @@ -159,6 +159,7 @@ 159 159 **Mechanism**: Scheduled polling 160 160 161 161 Nodes periodically: 175 + 162 162 1. Query partner nodes for updates 163 163 2. Fetch changed entities since last sync 164 164 3. Validate and import ... ... @@ -171,6 +171,7 @@ 171 171 **Mechanism**: WebSub-like protocol 172 172 173 173 Nodes subscribe to: 188 + 174 174 * Specific claim clusters 175 175 * Specific domains (medical, energy, etc.) 176 176 * Specific scenario types ... ... @@ -183,12 +183,12 @@ 183 183 === 5.4 Large Asset Transfer === 184 184 185 185 For files >10MB: 201 + 186 186 * S3-compatible object storage 187 187 * IPFS (content-addressed) 188 188 * Direct peer-to-peer transfer 189 189 * Chunked HTTP transfer with resume support 190 190 191 - 192 192 == 6. Federation Sync Workflow == 193 193 194 194 Complete synchronization sequence for creating and sharing new content: ... ... @@ -196,6 +196,7 @@ 196 196 === 6.1 Step 1: Local Node Creates New Versions === 197 197 198 198 User or AKEL creates: 214 + 199 199 * New claim version 200 200 * New scenario version 201 201 * New evidence version ... ... @@ -202,6 +202,7 @@ 202 202 * New verdict version 203 203 204 204 All changes tracked with: 221 + 205 205 * VersionID 206 206 * ParentVersionID 207 207 * AuthorType ... ... @@ -211,6 +211,7 @@ 211 211 === 6.2 Step 2: Federation Layer Builds Signed Bundle === 212 212 213 213 Federation layer packages: 231 + 214 214 * Entity data (claim, scenario, evidence metadata, verdict) 215 215 * Version lineage (ParentVersionID chain) 216 216 * Cryptographic signatures ... ... @@ -218,6 +218,7 @@ 218 218 * Trust metadata 219 219 220 220 Bundle format: 239 + 221 221 * JSON-LD for structured data 222 222 * Content-addressed hashes 223 223 * Digital signatures for integrity ... ... @@ -225,6 +225,7 @@ 225 225 === 6.3 Step 3: Bundle Includes Required Data === 226 226 227 227 Each bundle contains: 247 + 228 228 * **Claims**: Full claim text, classification, domain 229 229 * **Scenarios**: Definitions, assumptions, boundaries 230 230 * **Evidence metadata**: Source URLs, hashes, reliability scores (not always full files) ... ... @@ -235,11 +235,13 @@ 235 235 === 6.4 Step 4: Bundle Pushed to Trusted Neighbor Nodes === 236 236 237 237 Based on trust table: 258 + 238 238 * Push to **trusted nodes** immediately 239 239 * Queue for **neutral nodes** (batched) 240 240 * Skip **untrusted nodes** 241 241 242 242 Push methods: 264 + 243 243 * Webhook notification 244 244 * Direct API call 245 245 * Pub/Sub message queue ... ... @@ -247,6 +247,7 @@ 247 247 === 6.5 Step 5: Remote Nodes Validate Lineage and Signatures === 248 248 249 249 Receiving node: 272 + 250 250 1. Verifies cryptographic signatures 251 251 2. Validates version lineage (ParentVersionID chain) 252 252 3. Checks for conflicts with local data ... ... @@ -258,6 +258,7 @@ 258 258 === 6.6 Step 6: Accept or Branch Versions === 259 259 260 260 **Accept** (if validation passes): 284 + 261 261 * Import new versions 262 262 * Maintain provenance metadata 263 263 * Link to local related entities ... ... @@ -264,6 +264,7 @@ 264 264 * Update local indices 265 265 266 266 **Branch** (if conflict detected): 291 + 267 267 * Create parallel version tree 268 268 * Mark as "external branch" 269 269 * Allow local reviewers to merge or reject ... ... @@ -270,6 +270,7 @@ 270 270 * Preserve both version histories 271 271 272 272 **Reject** (if validation fails): 298 + 273 273 * Log rejection reason 274 274 * Notify source node (optional) 275 275 * Quarantine for manual review (optional) ... ... @@ -277,17 +277,18 @@ 277 277 === 6.7 Step 7: Local Re-evaluation Runs if Required === 278 278 279 279 After import, local node checks: 306 + 280 280 * Does new evidence affect existing verdicts? 281 281 * Do new scenarios require re-assessment? 282 282 * Are there contradictions with local content? 283 283 284 284 If yes: 312 + 285 285 * Trigger AKEL re-evaluation 286 286 * Queue for reviewer attention 287 287 * Update affected verdicts 288 288 * Notify users following related content 289 289 290 - 291 291 == 7. Cross-Node AI Knowledge Exchange == 292 292 293 293 Each node runs its own AKEL instance and may exchange AI-derived knowledge: ... ... @@ -295,26 +295,31 @@ 295 295 === 7.1 What Can Be Shared === 296 296 297 297 **Vector embeddings**: 325 + 298 298 * For cross-node claim clustering 299 299 * For semantic search alignment 300 300 * Never includes training data 301 301 302 302 **Canonical claim forms**: 331 + 303 303 * Normalized claim text 304 304 * Standard phrasing templates 305 305 * Domain-specific formulations 306 306 307 307 **Scenario templates**: 337 + 308 308 * Reusable scenario structures 309 309 * Common assumption patterns 310 310 * Evaluation method templates 311 311 312 312 **Contradiction alerts**: 343 + 313 313 * Detected conflicts between claims 314 314 * Evidence conflicts across nodes 315 315 * Scenario incompatibilities 316 316 317 317 **Metadata and insights**: 349 + 318 318 * Aggregate quality metrics 319 319 * Reliability signal extraction 320 320 * Bubble detection patterns ... ... @@ -347,10 +347,10 @@ 347 347 * No external AI control over local content 348 348 * Privacy-preserving knowledge exchange 349 349 350 - 351 351 == 8. Decentralized Processing == 352 352 353 353 Each node independently performs: 385 + 354 354 * AKEL processing 355 355 * Scenario drafting and validation 356 356 * Evidence review ... ... @@ -358,6 +358,7 @@ 358 358 * Truth landscape summarization 359 359 360 360 Nodes can specialize: 393 + 361 361 * Health-focused node with medical experts 362 362 * Energy-focused node with domain knowledge 363 363 * Small node delegating scenario libraries to partners ... ... @@ -364,15 +364,16 @@ 364 364 * Regional node with language/culture specialization 365 365 366 366 Optional data sharing includes: 400 + 367 367 * Embeddings for clustering 368 368 * Claim clusters for alignment 369 369 * Scenario templates for efficiency 370 370 * Verdict comparison metadata 371 371 372 - 373 373 == 9. Scaling to Thousands of Users == 374 374 375 375 Nodes scale independently through: 409 + 376 376 * Horizontally scalable API servers 377 377 * Worker pools for AKEL tasks 378 378 * Hybrid storage (local + S3/IPFS) ... ... @@ -382,6 +382,7 @@ 382 382 Federation allows effectively unlimited horizontal scaling by adding new nodes. 383 383 384 384 Communities may form: 419 + 385 385 * Domain-specific nodes (epidemiology, energy, climate) 386 386 * Language or region-based nodes 387 387 * NGO or institutional nodes ... ... @@ -389,6 +389,7 @@ 389 389 * Academic research nodes 390 390 391 391 Nodes cooperate through: 427 + 392 392 * Scenario library sharing 393 393 * Shared or overlapping claim clusters 394 394 * Expert delegation between nodes ... ... @@ -395,7 +395,6 @@ 395 395 * Distributed AKEL task support 396 396 * Cross-node quality audits 397 397 398 - 399 399 == 10. Federation and Release 1.0 == 400 400 401 401 **POC**: Single node, optional federation experiments ... ... @@ -403,6 +403,7 @@ 403 403 **Beta 0**: 2-3 nodes, basic federation protocol 404 404 405 405 **Release 1.0**: Full federation support with: 441 + 406 406 * Robust synchronization protocol 407 407 * Trust model implementation 408 408 * Cross-node AI knowledge exchange ... ... @@ -410,11 +410,9 @@ 410 410 * Distributed audit collaboration 411 411 * Inter-node expert consultation 412 412 413 - 414 414 == 11. Related Pages == 415 415 416 -* [[AKEL (AI Knowledge Extraction Layer)>>Test.FactHarborV09.Specification.AI Knowledge Extraction Layer (AKEL).WebHome]] 417 -* [[Data Model>>Test.FactHarborV09.Specification.Data Model.WebHome]] 418 -* [[Architecture>>Test.FactHarborV09.Specification.Architecture.WebHome]] 419 -* [[Workflows>>Test.FactHarborV09.Specification.Workflows.WebHome]] 420 - 451 +* [[AKEL (AI Knowledge Extraction Layer)>>FactHarbor.Archive.FactHarbor V0\.9\.23 Lost Data.Specification.AI Knowledge Extraction Layer (AKEL).WebHome]] 452 +* [[Data Model>>Test.FactHarbor V0\.9\.23 Lost Data.Specification.Data Model.WebHome]] 453 +* [[Architecture>>FactHarbor.Archive.FactHarbor V0\.9\.23 Lost Data.Specification.Architecture.WebHome]] 454 +* [[Workflows>>Test.FactHarbor V0\.9\.23 Lost Data.Specification.Workflows.WebHome]]