Fluxer Federation: Comprehensive Technical Report

Generated via Incremental Map-Reduce

Fluxer Federation Infrastructure Technical Report

Executive Summary

This report synthesizes deliberations on Fluxer's federation architecture, protocol selection, and operational requirements. Key decisions include prioritizing identity federation over content sharing, adopting Polyproto for v2, implementing instance-specific premium features, and using home-instance models for data management. E2EE is explicitly out of scope for federation. Federation v1 focuses on interoperability, while v2 emphasizes decentralization with built-in privacy.

---

1. Federation Architecture and Scope

Problem/Concept

Defining whether Fluxer should implement identity federation (decentralized logins) or content federation (shared messages across instances), and clarifying the scope of Federation v1 vs. v2.

Deliberations & Considerations

• Identity Federation (Favored)
  
  • Users maintain one account across instances; instances only verify authentication, not share data.
    
  • Pros: Simplified scaling, avoids global data replication, reduces legal liability (e.g., CSAM propagation).
    
  • Cons: Cross-instance DMs require a common instance; cross-instance features (e.g., emojis) are limited.
    
• Content Federation (Rejected)
  
  • Instances synchronize data (like Matrix/XMPP).
    
  • Pros: Seamless cross-instance DMs/communities.
    
  • Cons: Complex scaling, high bandwidth, moderation challenges, and legal risks.
    
• Federation v1 vs. v2
  
  • v1: Client-to-instance model (peer-to-instance), focusing on UI quirks and basic interoperability.
    
  • v2: Home-instance model for connections, prioritizing decentralization and built-in privacy (not content sharing).
    

Final Conclusion

• Federated identity is the consensus for both v1 and v2. Clients handle multi-instance connections; instances remain isolated.
  
• Federation v1: Expected in 3–5 months (client not ready yet).
  
• Federation v2: Targeted for ~1 year; uses Rust for critical services.
  
• E2EE is explicitly out of scope for federation solutions.
  

Citations

• @dark: [2026-02-19 20:53:06] – Proposed federated identity architecture.
  
• @Lilith: [2026-03-17 22:17:31] – Clarified v2 scope: "federation + decentralization with built-in privacy."
  
• @meowergirl: [2026-03-26 07:53:21] – "v1 federation will come soon... v2 is not ready."
  
• @jce: [2026-03-29 12:32:40] – Confirmed v1 as "interoperability-focused federation."

---

2. Protocol Selection and Design

Problem/Concept

Choosing a federation protocol (e.g., Polyproto, ATproto, custom) and evaluating interoperability with existing standards.

Deliberations & Considerations

• Polyproto (Favored for v2)
  
  • Pros: Discord-like API, existing implementations, adversarial migration support, message signing.
    
  • Cons: Unfinished specs, no full app implementation, client efficiency concerns in high-load scenarios.
    
  • Fluxer may adopt p2-core and co-develop p2-chat.
    
• ATproto (Rejected for Core Federation)
  
  • Pros: Account portability, federated identity design.
    
  • Cons: Asynchronous architecture (unsuitable for real-time chat), cryptographic overhead for small instances, lacks semi-private content support.
    
• Custom Protocol (Favored)
  
  • Pros: Tailored to Fluxer’s real-time needs, avoids ATproto’s scalability issues.
    
  • Cons: Duplication of effort; slower development.
    
• Existing Protocols (Matrix/XMPP/ActivityPub)
  
  • Matrix: Critiqued for full-room synchronization (resource-heavy).
    
  • XMPP: Deemed outdated and complex.
    
  • ActivityPub: Ruled out due to centralization risks.
    

Final Conclusion

• Polyproto is a strong candidate for v2. Fluxer will drive p2-chat development via real-world implementation.
  
• Custom protocol preferred for core federation due to real-time requirements.
  
• ATproto only considered for federated identity, not full federation.
  

Citations

• @alexia: [2026-02-19 23:57:21] – Pitched Polyproto as a fit for Fluxer.
  
• @jce: [2026-03-19 05:59:21] – "The ATproto architecture isn't really meant for something as intensive as real-time chat."
  
• @Lilith: [2026-03-23 15:56:25] – Evaluating Polyproto for client efficiency.
  
• @dubliv: [2026-03-06 06:29:34] – Ruled out Matrix and ActivityPub.

---

3. User Identity and Account Management

Problem/Concept

Mapping Fluxer user IDs to federated identities, handling account migration, and managing bot identities.

Deliberations & Considerations

• Identity Mapping
  
  • Proposed: [email protected] (e.g., [email protected]).
    
  • Challenges: Case insensitivity vs. p2-core’s lowercase requirement; global uniqueness.
    
• Account Migration
  
  • Reference Updates (Preferred): Remote servers update actor references (FID/ID-Cert) upon receiving signed migration notices.
    
  • Resigning Messages (Rejected): Impractical for large-scale data.
    
  • Permissions: Guild ownership transfer requires further spec work.
    
• Bot Federation
  
  • Bots will have a home instance (where created) for consistent identity.
    
  • Tradeoffs: Identity consistency vs. per-instance simplicity.
    

Final Conclusion

• 1:1 mapping is feasible: [email protected].
  
• Migration uses reference updates (not resigning).
  
• Bots require a home instance for identity consistency.
  

Citations

• @dark: [2026-02-19 21:24:31] – Explained regex compatibility and case handling.
  
• @alexia: [2026-02-21 01:12:34] – Proposed reference updates for migration.
  
• @Lilith: [2026-03-26 21:28:00] – Clarified bot identity model.

---

4. Data Storage and Flow

Problem/Concept

Designing data storage for communities, DMs, and media in a federated environment.

Deliberations & Considerations

• Communities
  
  • Reside on their home server. External users access via identity verification.
    
• Direct Messages (DMs)
  
  • Current Design: DMs stored on sender’s home instance; recipient fetches them.
    
  • E2EE: Optional for sensitive contexts; Signal protocol proposed but deferred.
    
  • Tradeoffs: Decentralized storage vs. complexity.
    
• Media Hosting
  
  • Rejected: Link-based messages for text (performance issues).
    
  • Possible for Attachments: External hosting adds complexity without clear benefits.
    
• Data Sovereignty
  
  • Rejected: Separate media hosting for users (latency, moderation challenges).
    

Final Conclusion

• Communities/DMs follow a home-server model.
  
• Media stored on instances; external hosting deprioritized.
  
• E2EE optional for DMs; not default for public communities.
  

Citations

• @damiuwu: [2026-03-12 21:35:45] – "Communities live on home servers; DMs use inbox/outbox."
  
• @bricklou: [2026-03-23 08:07:03] – Raised privacy concerns for DM storage.
  
• @Lilith: [2026-03-27 00:40:25] – "Sovereignty is good, but this model hinders small hosts."

---

5. Premium Features (Plutonium) in Federation

Problem/Concept

Handling instance-specific premium features (e.g., custom emojis, 4K streaming) across federated instances.

Deliberations & Considerations

• Cross-Instance Sharing (Rejected)
  
  • Allowing perks from one instance to work on others.
    
  • Pros: User convenience.
    
  • Cons: Devalues premium on host instances; abuse risk (e.g., self-hosted free premium).
    
• Instance Isolation (Favored)
  
  • Premium tied to the instance hosting the community.
    
  • Pros: Incentivizes instance revenue; simpler.
    
  • Cons: UX fragmentation.
    
• v2 Considerations
  
  • Account migration will retain perks (e.g., Visionary) when moving instances.
    

Final Conclusion

• Premium features are instance-specific in v1. Users must hold premium on the instance hosting the community.
  
• v2 will address monetization equity during migration.
  

Citations

• @gustave: [2026-02-19 21:34:40] – Raised cross-instance perk confusion.
  
• @alexia: [2026-03-01 23:02:12] – Confirmed Plutonium as per-instance.
  
• @Lilith: [2026-03-26 22:04:28] – "v1: per-instance perks; v2 will address equity."

---

6. Security and Integrity

Problem/Concept

Ensuring message integrity, handling key rotation, and preventing misuse in federation.

Deliberations & Considerations

• Message Signing
  
  • Polyproto’s approach: Messages signed with user’s private key. Servers can’t forge messages.
    
  • Benefits: Trustless moderation; prevents server-side tampering.
    
  • Overhead: Ed25519 signing is efficient (browser support exists).
    
• Key Rotation
  
  • Private keys rarely rotate unless compromised. ID-Certs (TTL: 1–12 hours) are renewable.
    
  • Re-signing mechanism (Polyproto Section 7.2) accepted.
    
• Misuse Scenarios
  
  • Malicious servers faking messages via forged identity keys.
    
  • Mitigation: Key-change alerts and protocol design.
    

Final Conclusion

• Message signing is critical for integrity.
  
• Key rotation uses Polyproto’s re-signing mechanism.
  
• Misuse mitigated by protocol design and key-change alerts.
  

Citations

• @ava: [2026-02-20 21:39:49] – Explained signing’s role in trust.
  
• @Kaevel: [2026-03-24 18:52:52] – Clarified key rotation via re-signing.
  
• @alexia: [2026-03-24 16:25:27] – Addressed misuse scenarios.

---

7. Moderation and Trust & Safety

Problem/Concept

Handling illegal content (e.g., CSAM) and instance-level blocking without disrupting user access.

Deliberations & Considerations

• Content Sharing Risks
  
  • Full replication (like Matrix) could make all instances legally liable for illegal content.
    
• Identity Federation Solution
  
  • Data stays on the origin instance, reducing liability.
    
  • Requires robust instance-level moderation tools.
    
• Defederation Mechanics
  
  • When instances block each other, user data from the defederated instance must be deleted.
    
  • Risk of admin conflicts fragmenting user networks.
    
• Two-Tier Moderation
  
  • Basic for small instances, advanced for large ones.
    

Final Conclusion

• Synchronized instance blocklists (similar to Fediverse MRF) for coordinated moderation.
  
• Tiered moderation services for different instance scales.
  

Citations

• @jce: [2026-03-19 21:51:06] – "When defederating from an instance, any data originating from there should be deleted."
  
• @Lilith: [2026-03-19 21:44:06] – "We are currently designing two tiers of moderation services..."

---

8. Deployment and Self-Hosting

Problem/Concept

Supporting self-hosted instances, mobile apps, and push notifications in a federated environment.

Deliberations & Considerations

• Self-Hosting
  
  • Kubernetes: Optional (not mandatory) for scalability.
    
  • Docker: Sufficient for simple deployments; complex for scaling.
    
  • Operator Pass: Proposed for mobile app support (compliance/reliability).
    
• Push Notifications
  
  • Relays + E2EE: Preferred solution for battery efficiency and privacy.
    
  • Tradeoffs: Relays reduce battery drain but introduce trust dependencies.
    
• Mobile Apps
  
  • Platform restrictions (Apple/Google) may block third-party servers.
    
  • Operator Pass could enable self-hosted instances in official apps.
    

Final Conclusion

• Kubernetes is optional; Docker prioritized for simplicity.
  
• Push relays with E2EE are viable.
  
• Operator Pass proposed for mobile app support.
  

Citations

• @tsubasa: [2026-03-01 08:58:04] – Requested Kubernetes/Helm charts.
  
• @proteusnexus: [2026-02-24 03:49:14] – Explained push relay architecture.
  
• @spff: [2026-02-24 00:25:37] – Proposed Operator Pass for mobile apps.

---

9. Collaboration and Communication

Problem/Concept

Formalizing Fluxer-Polyproto collaboration and documenting federation decisions.

Deliberations & Considerations

• Collaboration with Polyproto
  
  • Joint working group proposed to align specs. Fluxer’s API will inform p2-chat.
    
  • Challenges: Spec-implementation sync; Fluxer’s rapid development vs. Polyproto’s pace.
    
• Documentation
  
  • Chat summaries deployed (fluxerparse.fluxer.host).
    
  • GitHub discussions requested for structured organization.
    

Final Conclusion

• Collaboration is desirable. Fluxer will drive p2-chat via real-world implementation.
  
• Summaries deployed; GitHub discussions pending.
  

Citations

• @alexia: [2026-02-20 13:30:27] – Proposed WG and joint development.
  
• @astromahdi: [2026-03-26 03:05:08] – Generated comprehensive summaries.

---

10. Performance and Efficiency

Problem/Concept

Optimizing cryptographic operations and client efficiency in high-load scenarios.

Deliberations & Considerations

• Ed25519 Performance
  
  • Native browser support; sub-second signing for typical message histories.
    
  • Comparison: TLS already handles encryption; signing adds marginal overhead.
    
• Client Efficiency
  
  • Concerns about verifying hundreds of certificates in high-load scenarios (e.g., live streams).
    
  • Mitigation: Background verification with visual indicators (e.g., unverified badges).
    
• High-Load Scenarios
  
  • Polyproto’s design parallels WhatsApp/Signal, which handle similar loads.
    

Final Conclusion

• Performance is acceptable. Ed25519 is efficient for real-time use.
  
• Background verification adopted for public channels.
  

Citations

• @proteusnexus: [2026-02-20 23:52:02] – Noted Ed25519 browser support.
  
• @Lilith: [2026-03-23 22:35:36] – Raised client efficiency concerns.
  
• @Kaevel: [2026-03-24 01:43:59] – Proposed background verification.

---

Key Outstanding Issues

1. Cross-Instance DMs: MVP requires a common instance; long-term E2EE/P2P deferred.
   
2. Protocol Finalization: Polyproto adoption pending deeper evaluation.
   
3. Account Migration: Opt-in process and data continuity require further design.
   
4. Vetted Instances: Covenant-based vetting (non-payment) proposed as alternative to payment-based model.
   

---

Conclusion

Fluxer’s federation strategy prioritizes federated identity for scalability and simplicity, with Polyproto as the leading protocol for v2. Key technical decisions include instance-specific premium features, cryptographic message signing, and home-instance data models. Collaboration with Polyproto is likely to accelerate p2-chat development, though adversarial migration and cross-instance DMs require further work.