Federation & Decentralization
Federation & Decentralization
FactHarbor is designed as a network of independent nodes rather than a single centralized service.
This provides resilience, local autonomy, and virtually unlimited scalability.
Each node remains fully functional on its own while participating in a shared global knowledge graph.
Purpose of Federation
A federated architecture enables:
- Resilience against censorship or political pressure
- Local governance and moderation autonomy
- Scalability by adding more nodes, not bigger servers
- Shared knowledge structures without central authority
- Domain specialization (e.g., health-focused node, energy-focused node)
- Cross-node collaboration while preserving independence
FactHarbor takes inspiration from the Fediverse but uses stronger structure, integrity guarantees, and version lineage.
Federated Node Model
Each FactHarbor node maintains:
- Its own PostgreSQL database
- Its own vector database
- Its own object storage
- Its own AKEL instance
- Its own reviewers, experts, and moderators
- Its own trust and governance policies
Nodes exchange structured objects:
- Claims
- Scenarios
- Evidence metadata (not raw files unless elected)
- Verdicts (optional)
- Integrity hashes and signatures
Nodes decide individually which external nodes to trust.
Global Identifiers
Each entity receives a globally unique ID.
Format:
``factharbor://<node>/<type>/<local_id>``
Example:
``factharbor://factharbor.energy/claim/CLM-55812``
Types include:
- claim
- scenario
- evidence
- verdict
- user (optional)
- cluster
Identifiers are:
- Globally consistent
- Human-readable
- Hash-derived
- Independent from internal database IDs
Data Sharing Model
Nodes share:
- Claims
- Scenario structures
- Evidence metadata + content hashes
- Optional verdicts
- Integrity metadata
Nodes do not share:
- Local users
- Review discussions
- Internal moderation notes
- Private evidence
Large assets may use:
- Local object storage
- S3-compatible buckets
- IPFS for cross-node replication (optional)
Trust Model
Each node maintains a trust table:
- Trusted nodes
- Neutral nodes
- Untrusted nodes
Trust influences:
- Whether claims are auto-imported
- Whether scenarios are accepted without re-review
- Whether evidence requires new validation
- Whether external verdicts are visible to users
Reputation is local but can be mapped with trust-weighting.
Decentralized Processing
Each node independently performs:
- AKEL processing
- Scenario drafting
- Evidence review
- Verdict calculation
- Summary generation
- Re-evaluation
Nodes may specialize:
- medical node
- psychology node
- climate node
- small node delegating expert review to trusted partners
Optional cross-node data sharing includes:
- Embeddings
- Claim clusters
- Scenario templates
- Verdict comparison metadata
- Contradiction alerts
Cross-Node AI Knowledge Exchange
Nodes may exchange:
- Embeddings for clustering
- Canonical claim forms
- Scenario templates
- Reliability hints
- Contradiction alerts
- Lightweight model insights (NOT weights)
AKEL never:
- Shares model weights
- Automatically replaces local reviewer decisions
- Accepts untrusted automated content
Synchronization Protocol
Nodes periodically exchange version bundles:
- Claims
- Scenarios
- Evidence metadata + hashes
- Optional verdicts
- Templates
- Embeddings (optional)
- AKEL distilled knowledge summaries (optional)
Sync methods:
- Push (webhook)
- Pull (cron)
- Subscription (WebSub-like)
Large assets may be transferred via:
- S3-compatible file transfer
- IPFS
- Peer-to-peer
Scaling to Thousands of Users
Nodes scale independently:
- horizontally scaled API servers
- background worker pools
- GPU queues for AKEL
- caching (Redis)
- sharded databases
The network scales horizontally by adding more nodes.
Communities can form:
- Domain-specific nodes
- Region/language nodes
- NGO/academic nodes
- Private organization nodes
Nodes cooperate through:
- Shared scenario libraries
- Overlapping claim clusters
- Expert delegation
- Distributed AKEL tasks