Fluxer Federation: Comprehensive Technical Report
Technical Infrastructure Report: Federation Architecture & Roadmap
1. Federation Roadmap and Versioning
The Problem/Concept
Defining a phased rollout for federation to ensure stability and avoid protocol ossification. The core challenge is distinguishing between simple interoperability and true decentralization.
Deliberations & Considerations
- Federation v1 (Interoperability): Initially discussed as a pragmatic first step. It is defined as a "seamless client-side integration" where a single client can connect to multiple instances using separate accounts. It acts as a wrapper to eliminate frequent re-logging.
- Federation v2 (Decentralization & Privacy): Defined as "true federation." This involves cross-instance interaction where a user maintains one account on a home instance but communicates with users on other instances. Key requirements include the ability to migrate instances while maintaining content and enhanced built-in privacy.
- Tradeoffs: Prioritizing v1 defers the immense complexity of content federation and decentralization in favor of a stable identity layer.
Final Conclusion
Federation v1 is the immediate priority (multi-account client support). Federation v2 is the intended end-state but is deferred for at least 6 months. Release is contingent upon Canary stabilization, Fluxer v2, and the mobile app launch.
Citations:
-
@Lilith[2026-03-29 15:06:08, 2026-05-13 21:05, 2026-05-14 21:17] -
@jce[2026-03-29 12:32:40] -
@astromahdi[2026-03-29 14:39:48] -
@shardion[2026-05-14 21:04, 2026-05-16 22:11:06] -
@Speykious[2026-05-18 08:25:08]
2. Federated Identity and Addressing
The Problem/Concept
Establishing a globally unique identifier (handle) for users that is readable, scalable, and compatible with a decentralized network.
Deliberations & Considerations
- Handle Syntax: Various formats were debated, including dot-separation (
user.domain) and prefixing. The group compared these against email standards. - The Discriminator Problem: Discussion on whether to keep local numeric discriminators (e.g.,
#1234).- Tradeoff: Local discriminators prevent usernames from becoming "status symbols" but add visual clutter.
- The Domain as Global Discriminator: The domain (e.g.,
@fluxer.app) serves as the primary unique identifier across the federation.
- Separator Choice: A dot (
.) was preferred over a hash (#) for local discriminators to avoid visual clutter when combined with the@symbol. - Special Tiers: High-tier users (Visionaries) should be allowed to omit the local discriminator for a cleaner handle.
Final Conclusion
The standardized format is <user>@<instance> (Email-style).
- The domain acts as the global discriminator.
- Local discriminators will use a dot separator (e.g.,
username.1234@domain). -
#0000is designated as the canonical identifier for users on instances where discriminators are disabled. - Instance owners have autonomy over whether to enable local discriminators.
Citations:
-
@crittero[2026-05-01 16:24:34] -
@SteveLinkNoah[2026-05-01 16:28:59, 2026-05-18 06:23:39] -
@shardion[2026-05-10 22:55:37, 2026-05-15 21:25] -
@astromahdi[2026-05-14 06:37] -
@SylvaraTheDev[2026-05-13 00:43]
3. Protocol Evaluation and Selection
The Problem/Concept
Selecting the underlying protocol for identity and real-time communication.
Deliberations & Considerations
- OIDC (OpenID Connect): Viewed as highly appropriate for federated identity and authentication due to its chat-agnostic nature.
- ATproto: Useful for "permissioned data" and community identity (PDS), but currently insufficient for real-time chat and private data handling.
- Matrix: Heavily critiqued. Technical analysis showed it to be resource-heavy ("slow as fuck"), overly complex, and fundamentally flawed in its core architectural design.
- XMPP: Recognized for strong backend routing, but dismissed as a primary foundation due to extreme fragmentation and "compliance level" issues across providers.
Final Conclusion
Fluxer will not adopt Matrix or XMPP as a core foundation. The path forward is a custom protocol design for real-time communication, utilizing OIDC for identity/auth and potentially leveraging ATproto's permissioned data scheme for community identity in v2.
Citations:
-
@jce[2026-03-29 12:05:04, 2026-04-01 07:34:34] -
@astromahdi[2026-03-29 14:36:25] -
@ChrisGPT[2026-04-22 07:40:44] -
@sirobsidian[2026-04-22 08:15:14] -
@Pan[2026-04-06 08:04:04]
4. Premium Feature Management (Plutonium)
The Problem/Concept
Managing premium subscriptions across a network where the home instance and the remote instance may have different resource capabilities and monetization goals.
Deliberations & Considerations
- Cross-Instance Recognition: There was a conflict between providing a seamless UX (one subscription for all) and the reality that remote instance operators will not pay for the resources (bandwidth/storage) of a remote user's premium perks.
- Fraud Risks: Allowing remote instances to signal "Premium" status opens the door to "pirated" instances falsely claiming status to bypass limits.
- Resource Allocation: High-impact benefits (e.g., 4K streaming, large file uploads) impose costs on the receiving server.
Final Conclusion
Plutonium will be restructured to focus on Home-Instance Managed features.
- Compatible Features: Custom tags, message scheduling, animated avatars, and saved media (all handled by the home instance).
- Removed/Modified Features: Features requiring remote instance resources (e.g., increased message character limits) will be moved out of the premium tier to ensure a uniform experience.
- Protocol Level: No strict enforcement of cross-instance premium recognition; it remains at the discretion of the instance operator.
Citations:
-
@Lilith[2026-05-08 22:08:42, 2026-05-15 21:31] -
@vky[2026-05-08 18:34:23] -
@SteveLinkNoah[2026-04-20 22:34:41, 2026-05-08 21:58:30] -
@shardion[2026-05-08 18:28:43]
5. Content Storage and Replication
The Problem/Concept
Determining where media and messages are stored to balance data longevity against server costs.
Deliberations & Considerations
- The "Vanishing Instance" Problem: If content is only stored on the community instance, the data is lost if that instance goes offline.
- Replication Models: The "Mastodon Model" (full replication) was rejected as it is too costly for small self-hosted instances.
- Home-Instance Storage: A proposal was made to store attachments on the uploading user's home instance. Other instances only store a "pointer" (CDN-style link).
- Tradeoff: This ensures data persists as long as the user's identity server exists, regardless of the community's status.
Final Conclusion
Fluxer will avoid full content replication. The architecture will move toward Home-Instance Hosting for attachments. This supports small-scale hosting and ensures data longevity tied to the user's identity server.
Citations:
-
@SteveLinkNoah[2026-04-07 22:36:57] -
@crittero[2026-04-15 10:29:47] -
@Lilith[2026-05-08 21:17:13] -
@JoJoJux[2026-05-08 21:06:33]
6. Account and Content Portability (Migration)
The Problem/Concept
Preventing vendor lock-in by allowing users and communities to move their data between instances.
Deliberations & Considerations
- Implementation: While moving data is technically simple, defining what is federated is complex.
- Migration Mechanism: Discussion on whether to use integrated tools or standalone utilities. Given that instances are independent, an integrated "Export/Import" button may be impractical.
- Community Migration: For v2, the proposed flow involves updating a community record on a PDS (Personal Data Store). A new host can then re-index messages from the members' home instances.
Final Conclusion
Migration is a confirmed architectural goal for Federation v2. It will likely be handled via a separate standalone tool rather than integrated software to maintain instance independence.
Citations:
-
@Konnan[2026-05-03 18:16:17] -
@Lilith[2026-04-13 20:17:13, 2026-05-03 19:24:25] -
@astromahdi[2026-05-27 22:27:32] -
@oak[2026-04-12 16:36:54]
7. Security, Privacy, and Governance
The Problem/Concept
Managing trust, verification, and legal compliance in a decentralized environment.
Deliberations & Considerations
- IP Privacy: IP addresses are classified as PII under GDPR/CCPA. The primary driver for avoiding IP leaks is legal compliance.
- Verification (Phone/Email): Phone verification is deemed "broken" in federation. Trusting a home instance's verification is risky, but forcing re-verification is a poor UX.
- Moderation: To handle cross-instance abuse, a "double report" system (reporting to both the current and home instance) is preferred.
- Instance Vetting: A "Server Covenant" model (based on guidelines and uptime) is preferred over a payment-based vetting system to avoid creating a two-tier ecosystem.
Final Conclusion
- Privacy: The system must prioritize the masking of IP addresses to comply with GDPR/CCPA.
- Verification: Manual trust networks between instance operators are a viable tool but cannot be the sole infrastructure reliance.
- Governance: A covenant-based vetting system is the proposed path for "official" instance status.
Citations:
-
@Lilith[2026-04-12 04:28:35, 2026-04-13 21:47:16] -
@astromahdi[2026-04-12 02:56:55] -
@jce[2026-03-29 12:23:28] -
@crittero[2026-04-15 09:58:00]
8. Community and Room Architecture
The Problem/Concept
Defining the organizational hierarchy and visibility logic for federated communities.
Deliberations & Considerations
- Entity Priority: The group debated whether "rooms" or "communities" should be first-class citizens. A community-centric model (Server $\rightarrow$ Category $\rightarrow$ Channel) was chosen to simplify role and permission management.
- Visibility Logic:
- Opt-in: Hidden by default (leads to "Unknown Channel" errors).
- Opt-out: Visible by default (more natural UX).
Final Conclusion
The infrastructure will follow a Community-Centric model. Channel visibility will utilize an Opt-out approach (visible by default) to prevent UX failures.
Citations:
-
@meowergirl[2026-04-01 15:55:40, 2026-04-01 21:10:09] -
@Speykious[2026-04-01 13:52:07] -
@Masquerade[2026-04-01 21:08:57]
9. Infrastructure and Deployment
The Problem/Concept
Reducing barriers to entry for self-hosters while ensuring client consistency.
Deliberations & Considerations
- Kubernetes (k8s): Initially suggested as a requirement, but later decided that k8s should be optional to avoid barring small self-hosters.
- Client Fragmentation: To avoid the "mess" seen in XMPP/Matrix, the group discussed creating a core official library (similar to Telegram's TDLib).
Final Conclusion
Kubernetes is not a hard requirement for self-hosting. The project will adopt a centralized client library strategy to ensure all frontends share the same underlying protocol logic.
Citations:
-
@jce[2026-03-29 12:32:40, 2026-04-06 08:11:01] -
@Pan[2026-04-06 08:11:34]
10. Real-Time Communication (Voice & Chat)
The Problem/Concept
Solving latency and identity issues in cross-instance voice and text calls.
Deliberations & Considerations
- Voice Routing:
- Double-Hop: (Client $\rightarrow$ Home $\rightarrow$ Community $\rightarrow$ Voice Server) protects IP but increases latency (e.g., 40ms $\rightarrow$ 80ms).
- Single-Hop: Direct connection reduces latency but leaks IP.
- Voice Server Selection: To avoid "fights" over which instance hosts a call (and to preserve premium perks), a "multi-connection" approach was proposed.
Final Conclusion
- Voice Quality: The team acknowledges a direct tradeoff between IP safety and voice quality.
- Call Logic: The multi-connection approach (sending data through respective servers and syncing via timestamps) is the viable solution for preserving individual user perks.
Citations:
-
@Lilith[2026-04-13 20:49:07, 2026-04-20 21:50:44] -
@SteveLinkNoah[2026-04-13 20:45:48, 2026-04-20 15:30:25]