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.Specification.WebHome 1 +FactHarbor.Archive.FactHarbor V0\.9\.18.Specification.WebHome - Content
-
... ... @@ -1,221 +1,472 @@ 1 1 = Federation & Decentralization = 2 2 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. 3 +FactHarbor is designed to operate as a **federated network of nodes** rather than a single central server. 5 5 6 - Each noderemains fully functionalonitsownwhileparticipating in a sharedglobal knowledge graph.5 +Decentralization provides: 7 7 8 ----- 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.) 9 9 10 - = Purposeof Federation=13 +FactHarbor draws inspiration from the Fediverse but uses stronger structure, versioning, and integrity guarantees. 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 23 ---- 24 24 25 -= Federated NodeModel=17 +== Federated FactHarbor Nodes == 26 26 27 -Each FactHarbor node maintains: 19 +Each FactHarbor instance ("node") maintains: 28 28 29 -* Its own PostgreSQL database 30 -* Its own vector database 31 -* Its own object storage 21 +* Its own database 32 32 * Its own AKEL instance 33 -* Its own reviewers, experts, and moderators34 -* Its own trust andgovernancepolicies23 +* Its own reviewers, experts, and contributors 24 +* Its own governance rules 35 35 36 -Nodes exchange structured o bjects:26 +Nodes exchange structured information: 37 37 38 38 * Claims 39 39 * Scenarios 40 -* Evidence metadata (not raw filesunlesselected)30 +* Evidence metadata (not necessarily full files) 41 41 * Verdicts (optional) 42 -* Integrity hashes and signatures32 +* Hashes and signatures for integrity 43 43 44 -Nodes decideindividuallywhich external nodes totrust.34 +Nodes choose which external nodes they trust. 45 45 46 46 ---- 47 47 48 -= Global Identifiers = 38 +== Global Identifiers == 49 49 50 -E achentity receives a globally uniqueID.40 +Every entity receives a globally unique, linkable identifier. 51 51 52 -Format: 53 -` `factharbor://<node>/<type>/<local_id>``42 +**Format**: 43 +`factharbor://node_url/type/local_id` 54 54 55 -Example: 56 -` `factharbor://factharbor.energy/claim/CLM-55812``45 +**Example**: 46 +`factharbor://factharbor.energy/claim/CLM-55812` 57 57 58 -Types include: 59 -* claim 60 -* scenario 61 -* evidence 62 -* verdict 63 -* user (optional) 64 -* cluster 48 +**Supported types**: 65 65 66 -Identifiers are: 50 +* `claim` 51 +* `scenario` 52 +* `evidence` 53 +* `verdict` 54 +* `user` (optional) 55 +* `cluster` 56 + 57 +**Properties**: 58 + 67 67 * Globally consistent 68 68 * Human-readable 69 69 * Hash-derived 70 -* Independent from internal database IDs 62 +* Independent of database internals 63 +* URL-resolvable (future enhancement) 71 71 65 +This allows cross-node references and prevents identifier collisions in federated environments. 66 + 72 72 ---- 73 73 74 -= DataSharingModel =69 +== Trust Model == 75 75 76 - Nodes share:71 +Each node maintains a **trust table** defining relationships with other nodes: 77 77 78 -* Claims 79 -* Scenario structures 80 -* Evidence metadata + content hashes 81 -* Optional verdicts 82 -* Integrity metadata 73 +=== Trust Levels === 83 83 84 -Nodes **do not** share:75 +**Trusted Nodes**: 85 85 86 -* Local users 87 -* Review discussions 88 -* Internal moderation notes 89 -* Private evidence 77 +* Claims auto-imported 78 +* Scenarios accepted without re-review 79 +* Evidence considered valid 80 +* Verdicts displayed to users 81 +* High synchronization priority 90 90 91 - Largeassets mayuse:83 +**Neutral Nodes**: 92 92 93 -* Local object storage 94 -* S3-compatible buckets 95 -* IPFS for cross-node replication (optional) 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 96 96 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 + 97 97 ---- 98 98 99 -= Trust Model =120 +== Data Sharing Model == 100 100 101 - Eachnodemaintains a**trust table**:122 +=== What Nodes Share === 102 102 103 -* Trusted nodes 104 -* Neutral nodes 105 -* Untrusted nodes 124 +**Always shared** (if federation enabled): 106 106 107 -Trust influences: 126 +* Claims and claim clusters 127 +* Scenario structures 128 +* Evidence metadata and content hashes 129 +* Integrity signatures 108 108 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 131 +**Optionally shared**: 113 113 114 -Reputation is local but can be mapped with trust-weighting. 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 115 115 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 + 116 116 ---- 117 117 118 -= DecentralizedProcessing=159 +== Synchronization Protocol == 119 119 120 - Eachnode independentlyperforms:161 +Nodes exchange data using multiple synchronization methods: 121 121 122 -* AKEL processing 123 -* Scenario drafting 124 -* Evidence review 125 -* Verdict calculation 126 -* Summary generation 127 -* Re-evaluation 163 +=== Push-Based Synchronization === 128 128 129 - Nodes may specialize:165 +**Mechanism**: Webhooks 130 130 131 -* medical node 132 -* psychology node 133 -* climate node 134 -* small node delegating expert review to trusted partners 167 +When local content changes: 135 135 136 -Optional cross-node data sharing includes: 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 137 137 138 -* Embeddings 139 -* Claim clusters 140 -* Scenario templates 141 -* Verdict comparison metadata 142 -* Contradiction alerts 174 +**Use case**: Real-time updates for trusted partners 143 143 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 + 144 144 ---- 145 145 146 -= Cross-NodeAI KnowledgeExchange=215 +== Federation Sync Workflow == 147 147 148 - Nodesmay exchange:217 +Complete synchronization sequence for creating and sharing new content: 149 149 150 -* Embeddings for clustering 151 -* Canonical claim forms 152 -* Scenario templates 153 -* Reliability hints 154 -* Contradiction alerts 155 -* Lightweight model insights (NOT weights) 219 +=== Step 1: Local Node Creates New Versions === 156 156 157 -AKEL **never**:221 +User or AKEL creates: 158 158 159 -* Shares model weights 160 -* Automatically replaces local reviewer decisions 161 -* Accepts untrusted automated content 223 +* New claim version 224 +* New scenario version 225 +* New evidence version 226 +* New verdict version 162 162 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 + 163 163 ---- 164 164 165 -= SynchronizationProtocol =328 +== Cross-Node AI Knowledge Exchange == 166 166 167 - Nodesperiodically exchangeversionbundles:330 +Each node runs its own AKEL instance and may exchange AI-derived knowledge: 168 168 169 -* Claims 170 -* Scenarios 171 -* Evidence metadata + hashes 172 -* Optional verdicts 173 -* Templates 174 -* Embeddings (optional) 175 -* AKEL distilled knowledge summaries (optional) 332 +=== What Can Be Shared === 176 176 177 - Sync methods:334 +**Vector embeddings**: 178 178 179 -* Push(webhook)180 -* Pull(cron)181 -* Subscription(WebSub-like)336 +* For cross-node claim clustering 337 +* For semantic search alignment 338 +* Never includes training data 182 182 183 - Largeassetsmaybe transferred via:340 +**Canonical claim forms**: 184 184 185 -* S3-compatiblefiletransfer186 -* IPFS187 -* Peer-to-peer342 +* Normalized claim text 343 +* Standard phrasing templates 344 +* Domain-specific formulations 188 188 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 + 189 189 ---- 190 190 191 -= Scalingto Thousandsof Users =394 +== Decentralized Processing == 192 192 193 - Nodesscaleindependently:396 +Each node independently performs: 194 194 195 -* horizontally scaled APIservers196 -* backgroundworkerpools197 -* GPU queuesforAKEL198 -* cac hing (Redis)199 -* shardeddatabases398 +* AKEL processing 399 +* Scenario drafting and validation 400 +* Evidence review 401 +* Verdict calculation 402 +* Truth landscape summarization 200 200 201 - The networkscales horizontally by adding morenodes.404 +Nodes can specialize: 202 202 203 -Communities can form: 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 204 204 205 -* Domain-specific nodes 206 -* Region/language nodes 207 -* NGO/academic nodes 208 -* Private organization nodes 411 +Optional data sharing includes: 209 209 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 + 210 210 Nodes cooperate through: 211 211 212 -* Shared scenario libraries 213 -* Overlapping claim clusters 214 -* Expert delegation 215 -* Distributed AKEL tasks 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 216 216 217 217 ---- 218 218 219 -= DiagramReferences =450 +== Federation and Release 1.0 == 220 220 221 -{{include reference="FactHarbor.Specification.Diagrams.Federation Architecture.WebHome"/}} 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.Architecture.WebHome]] 472 +* [[Workflows>>FactHarbor.Specification.Workflows.WebHome]]