Skip to Content
Last modified by Robert Schaub on 2025/12/24 20:33
From version 3.1
edited by Robert Schaub
on 2025/12/12 09:32
Change comment: Imported from XAR
To version 1.2
edited by Robert Schaub
on 2025/12/11 21:34
Change comment: Renamed back-links.

Summary

Details

Page properties
Content
... ... @@ -3,56 +3,221 @@
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 -== Purpose of Federation ==
6 +Each node remains fully functional on its own while participating in a shared global knowledge graph.
7 7  
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).
8 +----
13 13  
14 -== Federated Node Model ==
10 += Purpose of Federation =
15 15  
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 +
16 16  Each FactHarbor node maintains:
17 -* Local PostgreSQL database, Vector DB, and Object Storage.
18 -* Local AKEL instance.
19 -* Local Reviewers and Governance policies.
20 20  
21 -Nodes exchange structured objects (Claims, Scenarios, Evidence metadata, Verdicts) via signed bundles.
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
22 22  
23 -== Global Identifiers ==
36 +Nodes exchange structured objects:
24 24  
25 -Format: ``factharbor://<node>/<type>/<local_id>``
38 +* Claims
39 +* Scenarios
40 +* Evidence metadata (not raw files unless elected)
41 +* Verdicts (optional)
42 +* Integrity hashes and signatures
26 26  
27 -Example: ``factharbor://factharbor.energy/claim/CLM-55812``
44 +Nodes decide individually which external nodes to trust.
28 28  
29 -Identifiers are globally consistent, human-readable, and hash-derived.
46 +----
30 30  
31 -== Data Sharing Model ==
48 += Global Identifiers =
32 32  
33 -* **Shared**: Claims, Scenario structures, Evidence metadata, Verdicts, Integrity hashes.
34 -* **Not Shared**: Local users, Review discussions, Internal notes, Private evidence.
50 +Each entity receives a globally unique ID.
35 35  
36 -== Trust Model ==
52 +Format:
53 +``factharbor://<node>/<type>/<local_id>``
37 37  
38 -Nodes maintain a **trust table** (Trusted, Neutral, Untrusted). This influences auto-import rules, re-review requirements, and visibility.
55 +Example:
56 +``factharbor://factharbor.energy/claim/CLM-55812``
39 39  
40 -== Decentralized Processing ==
58 +Types include:
41 41  
42 -Each node performs its own AKEL processing, drafting, and verdict calculation. Nodes may specialize in specific domains (e.g., Medical Node).
60 +* claim
61 +* scenario
62 +* evidence
63 +* verdict
64 +* user (optional)
65 +* cluster
43 43  
44 -== Synchronization Protocol ==
67 +Identifiers are:
45 45  
46 -Nodes exchange **Version Bundles** containing:
47 -* Claims, Scenarios, Metadata.
48 -* Merkle-tree lineage.
49 -* Cryptographic signatures.
69 +* Globally consistent
70 +* Human-readable
71 +* Hash-derived
72 +* Independent from internal database IDs
50 50  
51 -Methods: Push (Webhook), Pull (Cron), Subscription.
74 +----
52 52  
53 -== Scaling ==
76 += Data Sharing Model =
54 54  
55 -* **Vertical**: API servers, Workers, Caching.
56 -* **Horizontal**: Adding more nodes to the federation.
78 +Nodes share:
57 57  
58 -{{include reference="FactHarbor.Specification.Diagrams.Federation Architecture.WebHome"/}}
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"/}}