Skip to Content
Last modified by Robert Schaub on 2025/12/24 20:33
From version 4.1
edited by Robert Schaub
on 2025/12/12 15:41
Change comment: Imported from XAR
To version 5.1
edited by Robert Schaub
on 2025/12/12 19:37
Change comment: Imported from XAR

Summary

Details

Page properties
Content
... ... @@ -3,219 +3,56 @@
3 3  FactHarbor is designed as a network of independent nodes rather than a single centralized service.
4 4  This provides resilience, local autonomy, and virtually unlimited scalability.
5 5  
6 -Each node remains fully functional on its own while participating in a shared global knowledge graph.
6 +== Purpose of Federation ==
7 7  
8 -----
8 +* **Resilience**: Against censorship or political pressure.
9 +* **Autonomy**: Local governance and moderation.
10 +* **Scalability**: Adding more nodes, not bigger servers.
11 +* **Shared Knowledge**: Distributed structures without central authority.
12 +* **Specialization**: Domain-specific nodes (e.g., Health, Climate).
9 9  
10 -= Purpose of Federation =
14 +== Federated Node Model ==
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 -----
24 -
25 -= Federated Node Model =
26 -
27 27  Each FactHarbor node maintains:
17 +* Local PostgreSQL database, Vector DB, and Object Storage.
18 +* Local AKEL instance.
19 +* Local Reviewers and Governance policies.
28 28  
29 -* Its own PostgreSQL database
30 -* Its own vector database
31 -* Its own object storage
32 -* Its own AKEL instance
33 -* Its own reviewers, experts, and moderators
34 -* Its own trust and governance policies
21 +Nodes exchange structured objects (Claims, Scenarios, Evidence metadata, Verdicts) via signed bundles.
35 35  
36 -Nodes exchange structured objects:
23 +== Global Identifiers ==
37 37  
38 -* Claims
39 -* Scenarios
40 -* Evidence metadata (not raw files unless elected)
41 -* Verdicts (optional)
42 -* Integrity hashes and signatures
25 +Format: ``factharbor://<node>/<type>/<local_id>``
43 43  
44 -Nodes decide individually which external nodes to trust.
27 +Example: ``factharbor://factharbor.energy/claim/CLM-55812``
45 45  
46 -----
29 +Identifiers are globally consistent, human-readable, and hash-derived.
47 47  
48 -= Global Identifiers =
31 +== Data Sharing Model ==
49 49  
50 -Each entity receives a globally unique ID.
33 +* **Shared**: Claims, Scenario structures, Evidence metadata, Verdicts, Integrity hashes.
34 +* **Not Shared**: Local users, Review discussions, Internal notes, Private evidence.
51 51  
52 -Format:
53 -``factharbor://<node>/<type>/<local_id>``
36 +== Trust Model ==
54 54  
55 -Example:
56 -``factharbor://factharbor.energy/claim/CLM-55812``
38 +Nodes maintain a **trust table** (Trusted, Neutral, Untrusted). This influences auto-import rules, re-review requirements, and visibility.
57 57  
58 -Types include:
59 -* claim
60 -* scenario
61 -* evidence
62 -* verdict
63 -* user (optional)
64 -* cluster
40 +== Decentralized Processing ==
65 65  
66 -Identifiers are:
67 -* Globally consistent
68 -* Human-readable
69 -* Hash-derived
70 -* Independent from internal database IDs
42 +Each node performs its own AKEL processing, drafting, and verdict calculation. Nodes may specialize in specific domains (e.g., Medical Node).
71 71  
72 -----
44 +== Synchronization Protocol ==
73 73  
74 -= Data Sharing Model =
46 +Nodes exchange **Version Bundles** containing:
47 +* Claims, Scenarios, Metadata.
48 +* Merkle-tree lineage.
49 +* Cryptographic signatures.
75 75  
76 -Nodes share:
51 +Methods: Push (Webhook), Pull (Cron), Subscription.
77 77  
78 -* Claims
79 -* Scenario structures
80 -* Evidence metadata + content hashes
81 -* Optional verdicts
82 -* Integrity metadata
53 +== Scaling ==
83 83  
84 -Nodes **do not** share:
55 +* **Vertical**: API servers, Workers, Caching.
56 +* **Horizontal**: Adding more nodes to the federation.
85 85  
86 -* Local users
87 -* Review discussions
88 -* Internal moderation notes
89 -* Private evidence
90 -
91 -Large assets may use:
92 -
93 -* Local object storage
94 -* S3-compatible buckets
95 -* IPFS for cross-node replication (optional)
96 -
97 -----
98 -
99 -= Trust Model =
100 -
101 -Each node maintains a **trust table**:
102 -
103 -* Trusted nodes
104 -* Neutral nodes
105 -* Untrusted nodes
106 -
107 -Trust influences:
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
113 -
114 -Reputation is local but can be mapped with trust-weighting.
115 -
116 -----
117 -
118 -= Decentralized Processing =
119 -
120 -Each node independently performs:
121 -
122 -* AKEL processing
123 -* Scenario drafting
124 -* Evidence review
125 -* Verdict calculation
126 -* Summary generation
127 -* Re-evaluation
128 -
129 -Nodes may specialize:
130 -
131 -* medical node
132 -* psychology node
133 -* climate node
134 -* small node delegating expert review to trusted partners
135 -
136 -Optional cross-node data sharing includes:
137 -
138 -* Embeddings
139 -* Claim clusters
140 -* Scenario templates
141 -* Verdict comparison metadata
142 -* Contradiction alerts
143 -
144 -----
145 -
146 -= Cross-Node AI Knowledge Exchange =
147 -
148 -Nodes may exchange:
149 -
150 -* Embeddings for clustering
151 -* Canonical claim forms
152 -* Scenario templates
153 -* Reliability hints
154 -* Contradiction alerts
155 -* Lightweight model insights (NOT weights)
156 -
157 -AKEL **never**:
158 -
159 -* Shares model weights
160 -* Automatically replaces local reviewer decisions
161 -* Accepts untrusted automated content
162 -
163 -----
164 -
165 -= Synchronization Protocol =
166 -
167 -Nodes periodically exchange version bundles:
168 -
169 -* Claims
170 -* Scenarios
171 -* Evidence metadata + hashes
172 -* Optional verdicts
173 -* Templates
174 -* Embeddings (optional)
175 -* AKEL distilled knowledge summaries (optional)
176 -
177 -Sync methods:
178 -
179 -* Push (webhook)
180 -* Pull (cron)
181 -* Subscription (WebSub-like)
182 -
183 -Large assets may be transferred via:
184 -
185 -* S3-compatible file transfer
186 -* IPFS
187 -* Peer-to-peer
188 -
189 -----
190 -
191 -= Scaling to Thousands of Users =
192 -
193 -Nodes scale independently:
194 -
195 -* horizontally scaled API servers
196 -* background worker pools
197 -* GPU queues for AKEL
198 -* caching (Redis)
199 -* sharded databases
200 -
201 -The network scales horizontally by adding more nodes.
202 -
203 -Communities can form:
204 -
205 -* Domain-specific nodes
206 -* Region/language nodes
207 -* NGO/academic nodes
208 -* Private organization nodes
209 -
210 -Nodes cooperate through:
211 -
212 -* Shared scenario libraries
213 -* Overlapping claim clusters
214 -* Expert delegation
215 -* Distributed AKEL tasks
216 -
217 -----
218 -
219 -= Diagram References =
220 -
221 221  {{include reference="FactHarbor.Specification.Diagrams.Federation Architecture.WebHome"/}}