Fluxer Federation: Comprehensive Technical Report
Generated via Incremental Map-Reduce
Technical Infrastructure Report: Fluxer Federation Architecture
Status: Final Synthesis of Technical Deliberations
Date: 2026-06-20 (Consolidated)
Executive Summary
This document serves as the authoritative technical reference for the Fluxer Federation project. It synthesizes several months of deliberations regarding the transition from a centralized architecture to a federated ecosystem.
The overarching strategy is divided into two distinct phases: Federation v1, focusing on interoperability and multi-instance client support, and Federation v2, focusing on true decentralization, privacy, and adversarial portability. A core architectural pillar of this project is the "Anti-Matrix" approach—avoiding full content replication to ensure scalability and reduce legal liability for instance operators.
1. Overall Federation Architecture & Roadmap
The Problem/Concept
Defining a phased rollout that allows Fluxer to introduce federation without compromising platform stability or creating permanent architectural debt ("ossification").
Deliberations & Considerations
- C2S vs. S2S: Early debates centered on whether the client should aggregate multiple connections (Client-to-Server, like IRC) or if servers should communicate directly (Server-to-Server, like Matrix). The C2S model was favored for its horizontal scalability and ease of adaptation to the existing backend.
- The Relay System: To bridge the gap between a multi-account client and true federation, a "Relay" system was proposed to multiplex connections over HTTP/WebSockets, providing a single view of multiple accounts while the backend is still being developed.
- Decoupling Identity from Content: A significant architectural shift was proposed to separate the Identity Provider (IdP) from the Content Service. This prevents a "single point of failure" where a home instance outage blocks a user from accessing other federated communities.
Final Conclusion
The project will follow a strict versioned roadmap as defined by official Fluxer representation:
- Federation v1 (Interoperability): Focuses on the "truest sense" of federation—interoperability. This is primarily a client-side integration allowing users to maintain simultaneous connections to multiple instances via separate accounts.
- Federation v2 (Decentralization & Privacy): Introduces true decentralization. This enables a single global identity, enhanced privacy, and the ability for users to migrate their entire account/content between instances.
Citations: @Lilith [2026-03-29, 2026-05-14, 2026-06-16], @jce [2026-02-20, 2026-04-18], @dark [2026-02-20]
2. Federated Identity and Addressing
The Problem/Concept
Reconciling Fluxer's legacy user#1234 format with a globally unique, federated identifier that avoids collisions across thousands of independent instances.
Deliberations & Considerations
- Handle Formatting: Extensive debate occurred over the use of symbols. Options included
@username@domain,username#0000@domain, andusername.discrim@domain. The group sought to avoid "visual clutter" (e.g., using both#and@). - The Role of Discriminators: It was noted that in a federated system, the domain itself acts as a global discriminator. However, for legacy support and "Visionary" perks (
#0000), discriminators must be integrated into the handle prefix. - Custom Domains & Split-DNS: To prevent long handles and increase user sovereignty, the proposal of "Split Domains" (similar to ATProto) was introduced. This allows a user on
server-a.comto use a handle like@[email protected].
Final Conclusion
The standardized format for federated identity is an email-style address: [email protected].
- Discriminators: Instances may choose to enforce or remove them. Users with the
#0000perk can omit the discriminator entirely (@username@domain). - Verification: Custom domains will be authorized via DNS-based validation (CNAME or TXT records) to ensure legitimate authority over the domain.
Citations: @gustave [2026-03-01], @crittero [2026-05-01], @SteveLinkNoah [2026-05-01, 2026-06-01], @Hampus [2026-05-01], @jb [2026-06-21]
3. Protocol Selection & Implementation
The Problem/Concept
Selecting a communication protocol that supports real-time chat, cryptographic identity, and high performance without the baggage of existing failed implementations.
Deliberations & Considerations
- Rejected Protocols: Matrix was explicitly rejected due to scaling issues ("aggressive replication"), poor moderation tools, and high resource overhead. ActivityPub/JSON-LD were dismissed as too "hodgepodge" and CPU-intensive for real-time chat. XMPP was viewed as outdated but potentially useful as a bridge.
- Polyproto (
p2-core/p2-chat): This emerged as the primary candidate.p2-corehandles identity/auth via x.509 certificates, whilep2-chatdefines the API routes. Its design aligns with Fluxer's gateway architecture. - ATproto: Considered viable for the Identity Layer (due to its PDS model and portability) but rejected for the messaging layer due to its asynchronous nature and high cost of per-message signatures.
Final Conclusion
Fluxer will lean toward a Polyproto-based implementation.
-
p2-corewill be utilized for authentication and identity management. - The system will maintain a Fluxer-specific API for messaging to ensure performance, with the long-term goal of
p2-chatcompatibility for wider interop. - External protocols (like XMPP) will be handled via a Plugin/Bridge API, allowing instance admins to opt-in to external federation without bloating the core protocol.
Citations: @alexia [2026-02-19, 2026-03-23], @jce [2026-04-01, 2026-06-18], @Lilith [2026-06-18], @astromahdi [2026-04-22]
4. Data Residency & Storage Strategy
The Problem/Concept
Determining where messages and media are stored to balance user experience (speed) with instance sustainability (cost).
Deliberations & Considerations
- The "Anti-Matrix" Model: To avoid the legal and technical risks of full replication, the group decided that community content must remain on the host server. Foreign users connect directly to that host rather than syncing a copy of the room to their home server.
- Direct Message (DM) Storage: DMs present a unique challenge. A "Replication Model" was proposed where messages are stored on both the sender's and receiver's home instances to prevent data loss if one server goes offline.
- Media & Attachments: Storing large files on community servers creates a financial burden for admins. The alternative is a Pointer System, where media is hosted by the uploader's home instance, and other servers only store the URL.
Final Conclusion
- Text Messages: Reside exclusively on the instance where they are posted (Community Model).
- Direct Messages: Replicated across both participating instances for availability.
- Media/Attachments: Hosted by the Home Instance of the uploader. This ensures that the server providing the "premium" upload limit is also the one paying for the storage.
Citations: @Speykious [2026-03-03, 2026-04-06], @myachan [2026-03-13], @Lilith [2026-05-08], @JoJoJux [2026-05-08]
5. Account & Community Portability (Migration)
The Problem/Concept
Ensuring users and community owners are not locked into a single provider, allowing them to move their data if an instance becomes malicious or fails.
Deliberations & Considerations
- Adversarial Migration: Discussion focused on how to migrate when the source server is uncooperative. The solution involves using private identity keys (via Polyproto) to prove ownership at a new destination.
- The "Resigning" Problem: Moving historical data requires resigning messages with new keys, which is computationally expensive and potentially destroys audit trails.
- Interim Tooling: Building an integrated migration suite is high-complexity. It was suggested that third-party bots could act as a temporary bridge to export/import data via API before official tools are released.
Final Conclusion
Migration is a Federation v2 priority.
- Short-term: Bot-based "gap fillers" will be permitted for technical users to move data.
- Long-term: An integrated, first-party migration tool will be developed, allowing owners to map accounts and transfer history securely via the official UI.
Citations: @dark [2026-02-21], @alexia [2026-02-21], @Lilith [2026-05-29], @Rain [2026-05-29]
6. Premium Features (Plutonium) in Federation
The Problem/Concept
Managing "Plutonium" subscriptions across a trustless network where some instances may attempt to "spoof" premium status.
Deliberations & Considerations
- Resource vs. Cosmetic Perks: A distinction was made between perks that cost the host money (e.g., 4K streaming, large uploads) and those that are purely cosmetic (e.g., animated banners).
- The "Cheap Instance" Risk: Concerns were raised that users would subscribe to a low-cost instance to gain premium perks on expensive official servers.
Final Conclusion
Plutonium benefits will be split by resource impact:
- Resource-Heavy Perks: Tied strictly to the Instance providing the service. If you want 4K streaming on
fluxer.app, you must have a subscription there, regardless of your home instance status. - Identity/Cosmetic Perks: Managed by the Home Instance. Features like custom tags or animated avatars follow the user across the federation.
Citations: @gustave [2026-03-02], @jce [2026-03-02], @Lilith [2026-05-08, 2026-05-15]
7. Governance, Moderation & Trust
The Problem/Concept
Preventing the propagation of illegal content and managing "bad actor" instances without a central censorship authority.
Deliberations & Considerations
- Local vs. Global Blocking: Global blocklists were deemed ineffective ("drama hell"). Instead, the focus shifted to local enforcement where admins choose which trust-lists to import.
- Cross-Instance Reporting: To handle abuse, a "Double Report" system was proposed: reports are sent simultaneously to the hosting instance and the user's home instance.
- CSAM Prevention: Because federation is decentralized, a public, obfuscated list of media hashes will be provided for all instances to use for auto-blocking illegal content.
Final Conclusion
Moderation remains primarily local.
- Instance admins have full autonomy over their allow/block lists.
- Double-reporting is the standard for cross-instance abuse.
- A shared, obfuscated hash list will be implemented for critical safety (CSAM) compliance.
Citations: @fizz [2026-02-22], @jce [2026-03-16, 2026-04-15], @Lilith [2026-04-15]
8. Networking & Infrastructure
The Problem/Concept
Ensuring user privacy (IP obscuration) and mobile reliability in a decentralized environment.
Deliberations & Considerations
- IP Privacy: Direct connections to multiple servers expose the user's IP. Relays were proposed as a permanent architectural layer to obscure IPs during inter-server communication.
- Push Notifications: Mobile push is difficult for self-hosted instances due to Apple/Google requirements. UnifiedPush was identified as the viable standard for decentralized notification delivery.
- Voice Latency: A "Double Hop" (Client $\rightarrow$ Home Server $\rightarrow$ Target Server) protects IPs but increases latency (~40ms $\rightarrow$ ~80ms).
Final Conclusion
- Privacy: Relays are a permanent part of the infrastructure to ensure IP obscuration.
- Notifications: The Flutter-based mobile client will utilize UnifiedPush.
- Voice: A hybrid approach is preferred; while latency increases with privacy, it is an acceptable tradeoff for GDPR/CCPA compliance.
Citations: @alexia [2026-03-06], @proteusnexus [2026-02-24], @Spax [2026-05-15], @Lilith [2026-04-13]