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

From version 1.2
edited by Robert Schaub
on 2025/12/11 21:34
Change comment: Renamed back-links.
To version 3.1
edited by Robert Schaub
on 2025/12/12 09:32
Change comment: Imported from XAR

Summary

Details

Page properties
Content
... ... @@ -3,221 +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:
40 +== Decentralized Processing ==
59 59  
60 -* claim
61 -* scenario
62 -* evidence
63 -* verdict
64 -* user (optional)
65 -* cluster
42 +Each node performs its own AKEL processing, drafting, and verdict calculation. Nodes may specialize in specific domains (e.g., Medical Node).
66 66  
67 -Identifiers are:
44 +== Synchronization Protocol ==
68 68  
69 -* Globally consistent
70 -* Human-readable
71 -* Hash-derived
72 -* Independent from internal database IDs
46 +Nodes exchange **Version Bundles** containing:
47 +* Claims, Scenarios, Metadata.
48 +* Merkle-tree lineage.
49 +* Cryptographic signatures.
73 73  
74 -----
51 +Methods: Push (Webhook), Pull (Cron), Subscription.
75 75  
76 -= Data Sharing Model =
53 +== Scaling ==
77 77  
78 -Nodes share:
55 +* **Vertical**: API servers, Workers, Caching.
56 +* **Horizontal**: Adding more nodes to the federation.
79 79  
80 -* Claims
81 -* Scenario structures
82 -* Evidence metadata + content hashes
83 -* Optional verdicts
84 -* Integrity metadata
85 -
86 -Nodes **do not** share:
87 -
88 -* Local users
89 -* Review discussions
90 -* Internal moderation notes
91 -* Private evidence
92 -
93 -Large assets may use:
94 -
95 -* Local object storage
96 -* S3-compatible buckets
97 -* IPFS for cross-node replication (optional)
98 -
99 -----
100 -
101 -= Trust Model =
102 -
103 -Each node maintains a **trust table**:
104 -
105 -* Trusted nodes
106 -* Neutral nodes
107 -* Untrusted nodes
108 -
109 -Trust influences:
110 -
111 -* Whether claims are auto-imported
112 -* Whether scenarios are accepted without re-review
113 -* Whether evidence requires new validation
114 -* Whether external verdicts are visible to users
115 -
116 -Reputation is local but can be mapped with trust-weighting.
117 -
118 -----
119 -
120 -= Decentralized Processing =
121 -
122 -Each node independently performs:
123 -
124 -* AKEL processing
125 -* Scenario drafting
126 -* Evidence review
127 -* Verdict calculation
128 -* Summary generation
129 -* Re-evaluation
130 -
131 -Nodes may specialize:
132 -
133 -* medical node
134 -* psychology node
135 -* climate node
136 -* small node delegating expert review to trusted partners
137 -
138 -Optional cross-node data sharing includes:
139 -
140 -* Embeddings
141 -* Claim clusters
142 -* Scenario templates
143 -* Verdict comparison metadata
144 -* Contradiction alerts
145 -
146 -----
147 -
148 -= Cross-Node AI Knowledge Exchange =
149 -
150 -Nodes may exchange:
151 -
152 -* Embeddings for clustering
153 -* Canonical claim forms
154 -* Scenario templates
155 -* Reliability hints
156 -* Contradiction alerts
157 -* Lightweight model insights (NOT weights)
158 -
159 -AKEL **never**:
160 -
161 -* Shares model weights
162 -* Automatically replaces local reviewer decisions
163 -* Accepts untrusted automated content
164 -
165 -----
166 -
167 -= Synchronization Protocol =
168 -
169 -Nodes periodically exchange version bundles:
170 -
171 -* Claims
172 -* Scenarios
173 -* Evidence metadata + hashes
174 -* Optional verdicts
175 -* Templates
176 -* Embeddings (optional)
177 -* AKEL distilled knowledge summaries (optional)
178 -
179 -Sync methods:
180 -
181 -* Push (webhook)
182 -* Pull (cron)
183 -* Subscription (WebSub-like)
184 -
185 -Large assets may be transferred via:
186 -
187 -* S3-compatible file transfer
188 -* IPFS
189 -* Peer-to-peer
190 -
191 -----
192 -
193 -= Scaling to Thousands of Users =
194 -
195 -Nodes scale independently:
196 -
197 -* horizontally scaled API servers
198 -* background worker pools
199 -* GPU queues for AKEL
200 -* caching (Redis)
201 -* sharded databases
202 -
203 -The network scales horizontally by adding more nodes.
204 -
205 -Communities can form:
206 -
207 -* Domain-specific nodes
208 -* Region/language nodes
209 -* NGO/academic nodes
210 -* Private organization nodes
211 -
212 -Nodes cooperate through:
213 -
214 -* Shared scenario libraries
215 -* Overlapping claim clusters
216 -* Expert delegation
217 -* Distributed AKEL tasks
218 -
219 -----
220 -
221 -= Diagram References =
222 -
223 -{{include reference="FactHarbor.Archive.Diagrams v0\.8q.Federation Architecture.WebHome"/}}
58 +{{include reference="FactHarbor.Specification.Diagrams.Federation Architecture.WebHome"/}}