Changes for page Federation & Decentralization
Last modified by Robert Schaub on 2025/12/24 20:33
Summary
-
Page properties (2 modified, 0 added, 0 removed)
Details
- Page properties
-
- Parent
-
... ... @@ -1,1 +1,1 @@ 1 -FactHarbor. Archive.FactHarbor V0\.9\.18.Specification.WebHome1 +FactHarbor.Specification.WebHome - Content
-
... ... @@ -1,472 +1,221 @@ 1 1 = Federation & Decentralization = 2 2 3 -FactHarbor is designed to operate as a **federated network of nodes** rather than a single central server. 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. 4 4 5 - Decentralization provides:6 +Each node remains fully functional on its own while participating in a shared global knowledge graph. 6 6 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.) 8 +---- 12 12 13 - FactHarbordraws inspirationfromtheFediverse butuses stronger structure, versioning,and integrity guarantees.10 += Purpose of Federation = 14 14 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 + 15 15 ---- 16 16 17 -= =FederatedFactHarborNodes==25 += Federated Node Model = 18 18 19 -Each FactHarbor instance ("node")maintains:27 +Each FactHarbor node maintains: 20 20 21 -* Its own database 29 +* Its own PostgreSQL database 30 +* Its own vector database 31 +* Its own object storage 22 22 * Its own AKEL instance 23 -* Its own reviewers, experts, and contributors24 -* Its own governance rules33 +* Its own reviewers, experts, and moderators 34 +* Its own trust and governance policies 25 25 26 -Nodes exchange structured information:36 +Nodes exchange structured objects: 27 27 28 28 * Claims 29 29 * Scenarios 30 -* Evidence metadata (not necessarilyfullfiles)40 +* Evidence metadata (not raw files unless elected) 31 31 * Verdicts (optional) 32 -* Hashes and signaturesfor integrity42 +* Integrity hashes and signatures 33 33 34 -Nodes c hoose which external nodes theytrust.44 +Nodes decide individually which external nodes to trust. 35 35 36 36 ---- 37 37 38 -= =Global Identifiers ==48 += Global Identifiers = 39 39 40 -E veryentity receives a globally unique,linkable identifier.50 +Each entity receives a globally unique ID. 41 41 42 - **Format**:43 -`factharbor://node _url/type/local_id`52 +Format: 53 +``factharbor://<node>/<type>/<local_id>`` 44 44 45 - **Example**:46 -`factharbor://factharbor.energy/claim/CLM-55812` 55 +Example: 56 +``factharbor://factharbor.energy/claim/CLM-55812`` 47 47 48 -**Supported types**: 58 +Types include: 59 +* claim 60 +* scenario 61 +* evidence 62 +* verdict 63 +* user (optional) 64 +* cluster 49 49 50 -* `claim` 51 -* `scenario` 52 -* `evidence` 53 -* `verdict` 54 -* `user` (optional) 55 -* `cluster` 56 - 57 -**Properties**: 58 - 66 +Identifiers are: 59 59 * Globally consistent 60 60 * Human-readable 61 61 * Hash-derived 62 -* Independent of database internals 63 -* URL-resolvable (future enhancement) 70 +* Independent from internal database IDs 64 64 65 -This allows cross-node references and prevents identifier collisions in federated environments. 66 - 67 67 ---- 68 68 69 -= =Trust Model ==74 += Data Sharing Model = 70 70 71 - Each nodemaintainsa **trust table** definingrelationships with other nodes:76 +Nodes share: 72 72 73 -=== Trust Levels === 78 +* Claims 79 +* Scenario structures 80 +* Evidence metadata + content hashes 81 +* Optional verdicts 82 +* Integrity metadata 74 74 75 - **TrustedNodes**:84 +Nodes **do not** share: 76 76 77 -* Claims auto-imported 78 -* Scenarios accepted without re-review 79 -* Evidence considered valid 80 -* Verdicts displayed to users 81 -* High synchronization priority 86 +* Local users 87 +* Review discussions 88 +* Internal moderation notes 89 +* Private evidence 82 82 83 - **NeutralNodes**:91 +Large assets may use: 84 84 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 93 +* Local object storage 94 +* S3-compatible buckets 95 +* IPFS for cross-node replication (optional) 90 90 91 -**Untrusted Nodes**: 92 - 93 -* Claims quarantined, manual import only 94 -* Scenarios rejected by default 95 -* Evidence not accepted 96 -* Verdicts not displayed 97 -* No automatic synchronization 98 - 99 -=== Trust Affects === 100 - 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: 110 - 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 - 118 118 ---- 119 119 120 -= =DataSharingModel ==99 += Trust Model = 121 121 122 - === WhatNodesShare===101 +Each node maintains a **trust table**: 123 123 124 -**Always shared** (if federation enabled): 103 +* Trusted nodes 104 +* Neutral nodes 105 +* Untrusted nodes 125 125 126 -* Claims and claim clusters 127 -* Scenario structures 128 -* Evidence metadata and content hashes 129 -* Integrity signatures 107 +Trust influences: 130 130 131 -**Optionally shared**: 109 +* Whether claims are auto-imported 110 +* Whether scenarios are accepted without re-review 111 +* Whether evidence requires new validation 112 +* Whether external verdicts are visible to users 132 132 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 114 +Reputation is local but can be mapped with trust-weighting. 138 138 139 -**Never shared**: 140 - 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 146 - 147 -=== Large Evidence Files === 148 - 149 -Evidence files are: 150 - 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 - 157 157 ---- 158 158 159 -= =SynchronizationProtocol==118 += Decentralized Processing = 160 160 161 - Nodes exchangedata using multiplesynchronizationmethods:120 +Each node independently performs: 162 162 163 -=== Push-Based Synchronization === 122 +* AKEL processing 123 +* Scenario drafting 124 +* Evidence review 125 +* Verdict calculation 126 +* Summary generation 127 +* Re-evaluation 164 164 165 - **Mechanism**:Webhooks129 +Nodes may specialize: 166 166 167 -When local content changes: 131 +* medical node 132 +* psychology node 133 +* climate node 134 +* small node delegating expert review to trusted partners 168 168 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 136 +Optional cross-node data sharing includes: 173 173 174 -**Use case**: Real-time updates for trusted partners 138 +* Embeddings 139 +* Claim clusters 140 +* Scenario templates 141 +* Verdict comparison metadata 142 +* Contradiction alerts 175 175 176 -=== Pull-Based Synchronization === 177 - 178 -**Mechanism**: Scheduled polling 179 - 180 -Nodes periodically: 181 - 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: 194 - 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: 207 - 208 -* S3-compatible object storage 209 -* IPFS (content-addressed) 210 -* Direct peer-to-peer transfer 211 -* Chunked HTTP transfer with resume support 212 - 213 213 ---- 214 214 215 -= =FederationSyncWorkflow ==146 += Cross-Node AI Knowledge Exchange = 216 216 217 - Completesynchronizationsequence for creating and sharingnew content:148 +Nodes may exchange: 218 218 219 -=== Step 1: Local Node Creates New Versions === 150 +* Embeddings for clustering 151 +* Canonical claim forms 152 +* Scenario templates 153 +* Reliability hints 154 +* Contradiction alerts 155 +* Lightweight model insights (NOT weights) 220 220 221 - User orAKELcreates:157 +AKEL **never**: 222 222 223 -* New claim version 224 -* New scenario version 225 -* New evidence version 226 -* New verdict version 159 +* Shares model weights 160 +* Automatically replaces local reviewer decisions 161 +* Accepts untrusted automated content 227 227 228 -All changes tracked with: 229 - 230 -* VersionID 231 -* ParentVersionID 232 -* AuthorType 233 -* Timestamp 234 -* JustificationText 235 - 236 -=== Step 2: Federation Layer Builds Signed Bundle === 237 - 238 -Federation layer packages: 239 - 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: 247 - 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: 255 - 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: 266 - 267 -* Push to **trusted nodes** immediately 268 -* Queue for **neutral nodes** (batched) 269 -* Skip **untrusted nodes** 270 - 271 -Push methods: 272 - 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: 280 - 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): 292 - 293 -* Import new versions 294 -* Maintain provenance metadata 295 -* Link to local related entities 296 -* Update local indices 297 - 298 -**Branch** (if conflict detected): 299 - 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): 306 - 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: 314 - 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: 320 - 321 -* Trigger AKEL re-evaluation 322 -* Queue for reviewer attention 323 -* Update affected verdicts 324 -* Notify users following related content 325 - 326 326 ---- 327 327 328 -= =Cross-Node AI KnowledgeExchange==165 += Synchronization Protocol = 329 329 330 - Each noderuns itsown AKELinstanceand may exchangeAI-derivedknowledge:167 +Nodes periodically exchange version bundles: 331 331 332 -=== What Can Be Shared === 169 +* Claims 170 +* Scenarios 171 +* Evidence metadata + hashes 172 +* Optional verdicts 173 +* Templates 174 +* Embeddings (optional) 175 +* AKEL distilled knowledge summaries (optional) 333 333 334 - **Vectorembeddings**:177 +Sync methods: 335 335 336 -* Forcross-nodeclaimclustering337 -* Forsemanticsearch alignment338 -* Never includestrainingdata179 +* Push (webhook) 180 +* Pull (cron) 181 +* Subscription (WebSub-like) 339 339 340 - **Canonicalclaimforms**:183 +Large assets may be transferred via: 341 341 342 -* Normalizedclaimtext343 -* S tandardphrasingtemplates344 -* Domain-specific formulations185 +* S3-compatible file transfer 186 +* IPFS 187 +* Peer-to-peer 345 345 346 -**Scenario templates**: 347 - 348 -* Reusable scenario structures 349 -* Common assumption patterns 350 -* Evaluation method templates 351 - 352 -**Contradiction alerts**: 353 - 354 -* Detected conflicts between claims 355 -* Evidence conflicts across nodes 356 -* Scenario incompatibilities 357 - 358 -**Metadata and insights**: 359 - 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 - 392 392 ---- 393 393 394 -= =DecentralizedProcessing==191 += Scaling to Thousands of Users = 395 395 396 - Each node independentlyperforms:193 +Nodes scale independently: 397 397 398 -* AKEL processing399 -* Scenariodrafting andvalidation400 -* Evidence review401 -* Verdict calculation402 -* Truthlandscapesummarization195 +* horizontally scaled API servers 196 +* background worker pools 197 +* GPU queues for AKEL 198 +* caching (Redis) 199 +* sharded databases 403 403 404 - Nodescan specialize:201 +The network scales horizontally by adding more nodes. 405 405 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 203 +Communities can form: 410 410 411 -Optional data sharing includes: 205 +* Domain-specific nodes 206 +* Region/language nodes 207 +* NGO/academic nodes 208 +* Private organization nodes 412 412 413 -* Embeddings for clustering 414 -* Claim clusters for alignment 415 -* Scenario templates for efficiency 416 -* Verdict comparison metadata 417 - 418 ----- 419 - 420 -== Scaling to Thousands of Users == 421 - 422 -Nodes scale independently through: 423 - 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: 433 - 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 - 440 440 Nodes cooperate through: 441 441 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 212 +* Shared scenario libraries 213 +* Overlapping claim clusters 214 +* Expert delegation 215 +* Distributed AKEL tasks 447 447 448 448 ---- 449 449 450 -= =FederationandRelease1.0==219 += Diagram References = 451 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: 457 - 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 - 465 ----- 466 - 467 -== Related Pages == 468 - 469 -* [[AKEL (AI Knowledge Extraction Layer)>>FactHarbor.Specification V0\.9\.18.AI Knowledge Extraction Layer (AKEL).WebHome]] 470 -* [[Data Model>>FactHarbor.Specification.Data Model.WebHome]] 471 -* [[Architecture>>FactHarbor.Specification V0\.9\.18.Architecture.WebHome]] 472 -* [[Workflows>>FactHarbor.Specification.Workflows.WebHome]] 221 +{{include reference="FactHarbor.Specification.Diagrams.Federation Architecture.WebHome"/}}