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