Skip to Content
Last modified by Robert Schaub on 2025/12/24 20:33
From version 5.1
edited by Robert Schaub
on 2025/12/12 19:37
Change comment: Imported from XAR
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
Content
... ... @@ -3,56 +3,219 @@
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:
59 +* claim
60 +* scenario
61 +* evidence
62 +* verdict
63 +* user (optional)
64 +* cluster
41 41  
42 -Each node performs its own AKEL processing, drafting, and verdict calculation. Nodes may specialize in specific domains (e.g., Medical Node).
66 +Identifiers are:
67 +* Globally consistent
68 +* Human-readable
69 +* Hash-derived
70 +* Independent from internal database IDs
43 43  
44 -== Synchronization Protocol ==
72 +----
45 45  
46 -Nodes exchange **Version Bundles** containing:
47 -* Claims, Scenarios, Metadata.
48 -* Merkle-tree lineage.
49 -* Cryptographic signatures.
74 += Data Sharing Model =
50 50  
51 -Methods: Push (Webhook), Pull (Cron), Subscription.
76 +Nodes share:
52 52  
53 -== Scaling ==
78 +* Claims
79 +* Scenario structures
80 +* Evidence metadata + content hashes
81 +* Optional verdicts
82 +* Integrity metadata
54 54  
55 -* **Vertical**: API servers, Workers, Caching.
56 -* **Horizontal**: Adding more nodes to the federation.
84 +Nodes **do not** share:
57 57  
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 +
58 58  {{include reference="FactHarbor.Specification.Diagrams.Federation Architecture.WebHome"/}}