Wiki source code of Federation & Decentralization
Version 6.1 by Robert Schaub on 2025/12/12 21:27
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
1.1 | 1 | = Federation & Decentralization = |
| 2 | |||
| 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. | ||
| 5 | |||
| |
6.1 | 6 | Each node remains fully functional on its own while participating in a shared global knowledge graph. |
| |
1.1 | 7 | |
| |
6.1 | 8 | ---- |
| |
1.1 | 9 | |
| |
6.1 | 10 | = Purpose of Federation = |
| |
1.1 | 11 | |
| |
6.1 | 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 | |||
| |
1.1 | 27 | Each FactHarbor node maintains: |
| 28 | |||
| |
6.1 | 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 | ||
| |
1.1 | 35 | |
| |
6.1 | 36 | Nodes exchange structured objects: |
| |
1.1 | 37 | |
| |
6.1 | 38 | * Claims |
| 39 | * Scenarios | ||
| 40 | * Evidence metadata (not raw files unless elected) | ||
| 41 | * Verdicts (optional) | ||
| 42 | * Integrity hashes and signatures | ||
| |
1.1 | 43 | |
| |
6.1 | 44 | Nodes decide individually which external nodes to trust. |
| |
1.1 | 45 | |
| |
6.1 | 46 | ---- |
| |
1.1 | 47 | |
| |
6.1 | 48 | = Global Identifiers = |
| |
1.1 | 49 | |
| |
6.1 | 50 | Each entity receives a globally unique ID. |
| |
1.1 | 51 | |
| |
6.1 | 52 | Format: |
| 53 | ``factharbor://<node>/<type>/<local_id>`` | ||
| |
1.1 | 54 | |
| |
6.1 | 55 | Example: |
| 56 | ``factharbor://factharbor.energy/claim/CLM-55812`` | ||
| |
1.1 | 57 | |
| |
6.1 | 58 | Types include: |
| 59 | * claim | ||
| 60 | * scenario | ||
| 61 | * evidence | ||
| 62 | * verdict | ||
| 63 | * user (optional) | ||
| 64 | * cluster | ||
| |
1.1 | 65 | |
| |
6.1 | 66 | Identifiers are: |
| 67 | * Globally consistent | ||
| 68 | * Human-readable | ||
| 69 | * Hash-derived | ||
| 70 | * Independent from internal database IDs | ||
| |
1.1 | 71 | |
| |
6.1 | 72 | ---- |
| |
1.1 | 73 | |
| |
6.1 | 74 | = Data Sharing Model = |
| |
1.1 | 75 | |
| |
6.1 | 76 | Nodes share: |
| |
1.1 | 77 | |
| |
6.1 | 78 | * Claims |
| 79 | * Scenario structures | ||
| 80 | * Evidence metadata + content hashes | ||
| 81 | * Optional verdicts | ||
| 82 | * Integrity metadata | ||
| |
1.1 | 83 | |
| |
6.1 | 84 | Nodes **do not** share: |
| |
1.1 | 85 | |
| |
6.1 | 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 | |||
| |
2.1 | 221 | {{include reference="FactHarbor.Specification.Diagrams.Federation Architecture.WebHome"/}} |