Last modified by Robert Schaub on 2025/12/24 20:33

From version 7.5
edited by Robert Schaub
on 2025/12/16 21:40
Change comment: Update document after refactoring.
To version 6.1
edited by Robert Schaub
on 2025/12/12 21:27
Change comment: Rollback to version 4.1

Summary

Details

Page properties
Parent
... ... @@ -1,1 +1,1 @@
1 -FactHarbor.Specification V0\.9\.18.WebHome
1 +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 -FactHarbor draws inspiration from the Fediverse but uses 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 -== Federated FactHarbor Nodes ==
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 contributors
24 -* Its own governance rules
33 +* 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 necessarily full files)
40 +* Evidence metadata (not raw files unless elected)
31 31  * Verdicts (optional)
32 -* Hashes and signatures for integrity
42 +* Integrity hashes and signatures
33 33  
34 -Nodes choose which external nodes they trust.
44 +Nodes decide individually which external nodes to trust.
35 35  
36 36  ----
37 37  
38 -== Global Identifiers ==
48 += Global Identifiers =
39 39  
40 -Every entity 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 node maintains a **trust table** defining relationships 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 -**Trusted Nodes**:
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 -**Neutral Nodes**:
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 -== Data Sharing Model ==
99 += Trust Model =
121 121  
122 -=== What Nodes Share ===
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 -== Synchronization Protocol ==
118 += Decentralized Processing =
160 160  
161 -Nodes exchange data using multiple synchronization methods:
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**: Webhooks
129 +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 -== Federation Sync Workflow ==
146 += Cross-Node AI Knowledge Exchange =
216 216  
217 -Complete synchronization sequence for creating and sharing new 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 or AKEL creates:
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 Knowledge Exchange ==
165 += Synchronization Protocol =
329 329  
330 -Each node runs its own AKEL instance and may exchange AI-derived knowledge:
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 -**Vector embeddings**:
177 +Sync methods:
335 335  
336 -* For cross-node claim clustering
337 -* For semantic search alignment
338 -* Never includes training data
179 +* Push (webhook)
180 +* Pull (cron)
181 +* Subscription (WebSub-like)
339 339  
340 -**Canonical claim forms**:
183 +Large assets may be transferred via:
341 341  
342 -* Normalized claim text
343 -* Standard phrasing templates
344 -* Domain-specific formulations
185 +* 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 -== Decentralized Processing ==
191 += Scaling to Thousands of Users =
395 395  
396 -Each node independently performs:
193 +Nodes scale independently:
397 397  
398 -* AKEL processing
399 -* Scenario drafting and validation
400 -* Evidence review
401 -* Verdict calculation
402 -* Truth landscape summarization
195 +* horizontally scaled API servers
196 +* background worker pools
197 +* GPU queues for AKEL
198 +* caching (Redis)
199 +* sharded databases
403 403  
404 -Nodes can 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 -== Federation and Release 1.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 V0\.9\.18.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"/}}