Home / federation_comprehensive_report

Fluxer Federation: Comprehensive Technical Report

Generated via Incremental Map-Reduce

Technical Report: Federation Infrastructure for Fluxer

1. Federation Architecture and Design

1.1 Federation Model and Architecture

Problem/Concept:
Implement federated identity (not federated chat) for Fluxer, enabling users to use one account across multiple instances. The client connects to multiple instances simultaneously, with instances authenticating users via a federated identity protocol but not sharing data.

Deliberations & Considerations:
- Tradeoffs:
- Client-side aggregation vs. server-to-server (s2s) federation. The proposed model moves data aggregation to the client, simplifying the backend but requiring clients to handle multiple connections and state.
- Avoids s2s complexity (e.g., Matrix/XMPP), which can scale poorly due to data sharing.
- Similar to IRC clients handling multiple networks, but adapted for modern chat.
- Challenges:
- Cross-instance DMs require both users to connect to a common instance (or a dedicated DM protocol).
- If an instance goes down, users lose access to its communities until identity migration.
- CORS issues for web clients (solved by requiring instances to allow all origins or using proxies).

Final Conclusion:
- Federated identity (without federated chat) is the consensus approach.
- Client-side multi-instance connections and authentication are prioritized for efficiency and scalability.
- The model is deemed suitable for chat due to its lack of need for a global data view.

Citations:
- @dark (2026-02-19 20:47:29, 2026-02-20 00:00:01, 2026-02-21 00:09:49, 2026-02-21 01:02:32, 2026-02-21 11:17:39, 2026-02-21 20:51:20, 2026-02-21 22:17:38, 2026-02-21 14:34:40, 2026-02-21 15:07:55, 2026-02-21 18:24:59)

1.2 Federation Architecture: Communities vs. DMs

Problem/Concept:
Designing federation for communities (guilds) and direct messages (DMs) with decentralized storage and identity.

Deliberations & Considerations:
- Communities:
- Messages stored locally on the instance hosting the community.
- No content federation (avoids complexity and scaling issues).
- Tradeoff: Centralized storage per community vs. cross-instance access.
- DMs:
- Approaches:
- Inbox Model: DMs stored on recipient’s server, encrypted end-to-end (e.g., Signal protocol).
- Duplication: Messages stored on both sender and recipient servers for resilience.
- Tradeoffs:
- Inbox model requires E2EE to prevent server access; duplication increases storage.
- Trust concerns: Users must trust remote servers with unencrypted DMs.

Final Conclusion:
- Communities: Decentralized storage per instance; no content federation.
- DMs: E2EE via Signal protocol preferred; duplication for resilience.

Citations:
- @dark (2026-02-21 20:51:20, 2026-02-21 22:17:38)
- @praytowin (2026-02-21 21:07:26)
- @ima (2026-02-21 22:36:38)

1.3 Federation Design: Identity vs. Content Federation

Problem/Concept:
Debate over whether Fluxer's federation should prioritize identity federation (single account across instances via OAuth) or content federation (message/data sharing between instances like Matrix). The roadmap distinguishes "federated identity" (v1) from "true federation" (v2), causing confusion about v2's scope.

Deliberations & Considerations:
- Identity Federation (v1): Uses OAuth2 for authentication, allowing seamless access to communities on other instances without multiple accounts. Avoids data replication and legal liability (e.g., storing illegal content). Tradeoff: Limited to authentication; no cross-instance message sharing.
- Content Federation (v2): Would enable message/data sharing between instances. Raises challenges like data storage, moderation (e.g., CSAM propagation), legal liability, and scalability. Tradeoff: Richer communication but increased complexity and moderation burden.
- Moderation Concerns: Content federation risks replicating illegal content across instances, exposing hosts to legal issues (e.g., Matrix's model). Identity federation mitigates this by isolating data.
- User Experience: Identity federation reduces friction; content federation risks fragmenting networks if instances defederate.

Final Conclusion:
- Partial: Team leans toward identity federation (v1) as a pragmatic first step. "True federation" (v2) remains undefined but is expected to build on v1. Full content federation is seen as risky and potentially unscalable.
- Final: No decision on v2, but identity federation is prioritized for its simplicity and safety.

Citations:
- @sharon (2026-03-17 15:58:39)
- @Atakku (2026-03-17 15:19:11)
- @Lilith (2026-03-17 22:17:29)
- @jce (2026-03-19 21:17:29)

1.4 Separation of Identity and Community Services

Problem/Concept:
Decoupling identity management (accounts) from community/content hosting into independent services.

Deliberations & Considerations:
- Modularity Benefits:
- Operators can run identity-only, community-only, or combined instances.
- Simplifies scaling (e.g., identity services handle lightweight auth; community services manage heavy content).
- Moderation Challenges:
- Blocking an identity service could affect all its users (collateral damage).
- Reports go to content servers, not identity servers, complicating abuse response.
- DM Hosting:
- Identity servers host DMs (lightweight load) vs. community servers (fragmented data).
- Tradeoffs:
- Pros: Resilience, easier infrastructure management.
- Cons: Moderation complexity, potential for abuse (e.g., identity-only services with no incentive to moderate).
- Comparison to Matrix/Bluesky:
- Matrix’s monolith model ties identity to homeservers (risk of data loss). Bluesky separates identity (PDS) and content (better portability).

Final Conclusion:
- Strong support for separation (modular design).
- Identity services set default DM hosts; users can override.
- Moderation remains a key concern (no final solution).

Citations:
- @astromahdi (2026-03-20 18:40:24, 2026-03-20 18:40:43, 2026-03-20 19:52:44)
- @Rain (2026-03-20 18:44:52, 2026-03-20 18:51:33)
- @patataofcourse (2026-03-20 19:47:39, 2026-03-20 19:49:35)
- @skyibis (2026-03-20 19:54:21, 2026-03-20 19:55:24)

1.5 Relay System as a Federation Precursor

Problem/Concept:
A "relay" system to unify multi-instance access before full federation is implemented.

Deliberations & Considerations:
- @jce shared the 2026 roadmap: Relays multiplex client connections over HTTP/WebSockets with E2EE, hosted by Fluxer Platform AB or self-hosted.
- @gustave clarified relays would allow combining accounts (e.g., fluxer.app + self-hosted) into one view without backend federation.
- Tradeoffs: Relays reduce federation complexity but introduce a central dependency; E2EE mitigates privacy risks.

Final Conclusion:
- @jce finalized that relays are "entirely separate from federation" and will launch first to enable multi-instance access.
- @SlimTanButterfly called it a "neat temporary solution."

Citations:
- @jce (2026-02-26 09:09:54)
- @gustave (2026-02-26 09:09:55)
- @SlimTanButterfly (2026-02-26 08:53:21, 2026-02-26 10:05:31)

1.6 Deployment Architecture for Self-Hosted Federation

Problem/Concept:
Scalability and deployment methods for self-hosted federation instances, particularly the need for Kubernetes-based solutions over Docker.

Deliberations & Considerations:
- Tradeoff: Docker vs. Kubernetes for scalability.
- @tsubasa argued Docker alone is insufficient for scalable federation due to limitations in orchestration and resource management.
- Kubernetes was proposed as superior for auto-scaling, load balancing, and service mesh capabilities, critical for federated systems handling cross-instance traffic.
- Tradeoff: Helm charts vs. manual deployment.
- @tsubasa emphasized the need for Helm charts to simplify Kubernetes deployment, reducing operational overhead for administrators. Manual setups risk configuration drift and inconsistent deployments.

Final Conclusion:
- Kubernetes is the preferred foundation for scalable federation.
- Helm charts are essential for user-friendly deployment, though no final decision was made on implementation.

Citations:
- @tsubasa (2026-03-01 08:58:04, 2026-03-01 08:59:07, 2026-03-01 09:00:25)
- @jameskitt616 (2026-03-01 09:03:02)

2. Identity and Authentication

2.1 Adversarial Migrations and Identity Reassociation

Problem/Concept:
Challenges in migrating user identities between servers while preserving permissions (e.g., guild roles) and preventing malicious migrations.

Deliberations & Considerations:
- Problem: If a user migrates from Server A to Server B, how do remote servers (e.g., Server C) update permissions without resigning all messages?
- Solutions Discussed:
- Migration Signatures: Users sign a migration notice with a one-time secret to notify remote servers.
- Stable Internal IDs: Use immutable UIDs instead of mutable FIDs (Federated IDs) to avoid resigning data.
- Trust Models: Debate over whether to trust client-side secrets or server-side keys for migration.
- Tradeoffs:
- Client-side secrets risk compromise; server-side keys risk malicious server actions.
- Resigning messages is impractical for large-scale data.

Final Conclusion:
- Remote servers should update references to the new FID upon receiving a signed migration notice.
- Stable internal IDs (UIDs) are preferred over resigning messages.

Citations:
- @dark (2026-02-21 00:09:49, 2026-02-21 01:02:32, 2026-02-21 11:17:39)
- @alexia (2026-02-21 01:09:23, 2026-02-21 01:12:34)
- @ava (2026-02-21 11:55:22, 2026-02-21 12:01:48)

2.2 Username Resolution Across Federated Instances

Problem/Concept:
Mechanism for globally unique usernames in a federated system, avoiding centralization while enabling cross-instance addressing.

Deliberations & Considerations:
- Tradeoff: Centralized directory vs. decentralized addressing.
- @maelstrom questioned whether a central directory (e.g., mapping usernames to instances/IDs) would be needed, risking centralization.
- @gustave proposed a decentralized approach: username@instance (e.g., [email protected]), inspired by Mastodon’s @server system. This avoids single points of failure but requires robust DNS-like resolution.
- Tradeoff: Resolution protocol complexity.
- Decentralized systems need efficient discovery protocols (e.g., SRV records or federated APIs) to resolve @instance addresses without latency.

Final Conclusion:
- Adopt a decentralized username@instance format for federation.
- Resolution mechanisms are still under design (referenced in pinned resources).

Citations:
- @maelstrom (2026-03-01 10:14:41, 2026-03-01 10:20:54, 2026-03-01 10:29:55)
- @gustave (2026-03-01 10:27:21, 2026-03-01 10:27:37, 2026-03-01 10:31:22, 2026-03-01 10:31:28)
- @jameskitt616 (2026-03-01 10:21:17)

2.3 User ID Uniqueness Across Instances

Problem/Concept:
How user identifiers (IDs) are handled to ensure uniqueness and consistency across instances, especially for bot data storage.

Deliberations & Considerations:
- ID Structure:
- @Atakku questioned if IDs are unique per instance or globally.
- @Vero proposed compound IDs: [userID]:[currentServerId]:[homeServerId].
- @myachan argued global uniqueness (e.g., high-entropy IDs) could eliminate the need for compound IDs.
- Data Storage Impact:
- @Atakku warned that instance-specific IDs would break bot data storage (e.g., if a user’s ID changes when interacting from another instance).
- @crittero suggested instances maintain separate local/federated IDs.

Final Conclusion:
- Compound IDs ([userID]:[currentServerId]:[homeServerId]) are favored for uniqueness (@Vero).
- Global uniqueness is ideal but may not be feasible (@myachan).

Citations:
- @Atakku (2026-03-04 16:01:57–17:11:18)
- @Vero (2026-03-04 16:22:21, 2026-03-04 16:23:14, 2026-03-04 21:50:12)
- @crittero (2026-03-04 17:45:57)
- @myachan (2026-03-04 22:08:04)

2.4 OAuth and Data Privacy in Federation

Problem/Concept:
How OAuth enables federation while ensuring user data isn’t stored on other instances.

Deliberations & Considerations:
- @Didi referenced the roadmap stating federation uses OAuth and other servers won’t store user info.
- No deep technical discussion; OAuth implies trust-based authentication where the home server handles data.

Final Conclusion:
- OAuth is the confirmed mechanism for federation, with data privacy enforced (@Didi).

Citations:
- @Didi (2026-03-02 10:54:12)

2.5 Protocol Selection (OAuth2/OIDC/IndieAuth)

Problem/Concept:
Choosing a federated identity protocol for Fluxer, balancing flexibility, adoption, and chat-specific needs.

Deliberations & Considerations:

Final Conclusion:
- @jce (2026-03-19 22:20:12): "OIDC is battle-tested and flexible."
- @jce (2026-03-19 22:24:26): "ATproto could work for identity, but OIDC is design-agnostic."
- @oak (2026-03-19 22:23:09): Advocates for separating identity/community servers via OIDC.

Citations:
- @jce (2026-03-19 22:20:12, 2026-03-19 22:24:26)
- @oak (2026-03-19 22:23:09)

3. Protocol Selection and Standards

3.1 Performance of MLS for Federation

Problem/Concept:
Whether MLS can handle federation at scale (millions of users) given its design goals and asymmetric message signatures.

Deliberations & Considerations:
- MLS was designed with millions-scale performance in mind.
- Asymmetric signatures per encrypted message establish sender identity but may impact performance.
- Tradeoff between security (sender authentication) and scalability.

Final Conclusion:
MLS performance is deemed sufficient for federation due to its scale-oriented design.

Citations:
- @ava (2026-02-21 00:07:54, 2026-02-21 00:08:51, 2026-02-21 00:09:17)

3.2 Leveraging IETF Standards (MIMI/MLS) for Federation

Problem/Concept:
Integrating IETF standards (MIMI/MLS) to enhance federation security, interoperability, and reduce development overhead.

Deliberations & Considerations:
- Tradeoff: Custom protocol vs. standardized implementation.
- @Noel advocated for MIMI/MLS to avoid reinventing security protocols, citing IETF’s rigorous vetting.
- Custom protocols risk vulnerabilities and fragmentation, while standards ensure maturity and cross-platform compatibility.
- Tradeoff: Interoperability vs. control.
- Adopting MIMI/MLS would enable federation with non-Fluxer systems (e.g., XMPP), attracting administrators but limiting protocol customization.

Final Conclusion:
- MIMI/MLS integration is proposed as a strategic priority for security and interoperability.
- No final decision; requires further evaluation of IETF standardization timelines.

Citations:
- @Noel (2026-03-01 13:09:57, 2026-03-01 13:11:42)

3.3 Polyproto Adoption vs. Custom Protocol

Problem/Concept:
Whether Fluxer should adopt the Polyproto protocol (modular, Discord API-like) or build a custom federation solution.

Deliberations & Considerations:
- Polyproto Pros:
- Modular design (p2-core for auth, p2-chat for Discord-like API).
- Existing reference implementations (e.g., Sonata chat server).
- Interoperability with Fluxer, Stoat, and Spacebar.
- Polyproto Cons:
- Early-stage; lacks full-stack proof-of-concept.
- Risk of slow development due to standardization efforts.
- Custom Solution Pros:
- Faster iteration without committee overhead.
- Custom Solution Cons:
- May lead to ecosystem fragmentation.

Final Conclusion:
- Polyproto is viable due to architectural alignment with Fluxer’s goals.
- Custom solution preferred for MVP to avoid delays; standardization deferred.

Citations:
- @alexia (2026-02-21 01:43:02, 2026-02-21 06:02:55)
- @jce (2026-02-21 01:30:39, 2026-02-21 12:20:43)
- @fizz (2026-02-21 06:03:40)

3.4 Protocol Selection for Federation

Problem/Concept:
Choosing an existing federation protocol (e.g., XMPP, ActivityPub, Matrix) versus alternatives like atproto.

Deliberations & Considerations:
- XMPP: Criticized as outdated and lacking modern features (e.g., scalability, security).
- ActivityPub/Matrix: Explicitly rejected due to perceived inefficiencies or design flaws.
- atproto:
- Pros: Decentralized, identity-focused, and non-public data support is still in progress (contrary to misconceptions).
- Cons: No native private chat support; implementations like roomy.space are "barebone."
- Tradeoff: atproto offers strong identity federation but requires complementary protocols for messaging.

Final Conclusion:
- atproto is favored for identity management but needs augmentation for full functionality.
- Existing protocols (XMPP, ActivityPub, Matrix) are deemed unsuitable.

Citations:
- @Kinu (2026-03-05 14:33:43)
- @astromahdi (2026-03-05 14:34:39)
- @dubliv (2026-03-06 06:28:54, 2026-03-06 06:29:34)
- @ember (2026-03-06 00:17:58, 2026-03-06 03:23:41)
- @tulilirockz (2026-03-06 00:59:44)
- @dubliv (2026-03-06 06:32:16)
- @ember (2026-03-06 06:40:30, 2026-03-06 07:52:28)

3.5 Fluxer’s Relay Architecture vs. Polyproto-Core

Problem/Concept:
Fluxer’s use of relays for IP obfuscation versus implementing Polyproto-core as an alternative.

Deliberations & Considerations:
- Relays obscure user IPs between servers but are a "permanent plan" for Fluxer.
- Polyproto-core could have been implemented with minimal effort since relays only handle IP masking.
- Tradeoff: Relays add latency and complexity; Polyproto-core might offer simpler federation.

Final Conclusion:
Fluxer’s relay design is prioritized for IP privacy, but Polyproto-core is a viable, simpler alternative that was overlooked.

Citations:
- @alexia (2026-03-06 10:10:02)

4. Data Storage and Sovereignty

4.1 Data Storage and Sovereignty

Problem/Concept:
Ensuring user data sovereignty in federation, particularly whether instances should store external data and how to decentralize control.

Deliberations & Considerations:
- Proposal: Store messages/media on user-controlled servers (e.g., via links), not instances. Instances only store metadata.
- Pros: Users control data deletion/expiration; reduces instance storage burden.
- Cons: Client-side complexity; moderation challenges (e.g., self-destructing messages).
- Alternative: Instances only host their own communities, avoiding replication but limiting functionality.
- E2EE Integration: End-to-end encryption is seen as complementary to data sovereignty.

Final Conclusion:
- Partial: Team favors instances not storing external data (per roadmap). User-controlled storage via links is discussed but not prioritized.
- Final: Data sovereignty is secondary to federation simplicity; E2EE is a separate priority.

Citations:
- @Rain (2026-03-17 08:31:07)
- @damiuwu (2026-03-17 08:35:56)
- @Rain (2026-03-17 16:41:31)
- @Lilith (2026-03-19 21:49:48)

4.2 Global Emoji/Reaction Cross-Instance Handling

Problem/Concept:
How emojis/reactions from one instance are rendered in messages on another instance, including caching, storage, and abuse prevention.

Deliberations & Considerations:
- Storage Model: @Speykious argued reactions are message properties stored on the target instance (not the source), referencing Matrix as a precedent.
- Caching Strategy:
- @bricklou suggested caching emoji images to balance load.
- @Speykious proposed indefinite caching (no expiration) to avoid broken links if the source instance is down.
- Tradeoff: Caching complexity vs. reliability (e.g., expired emojis could break messages).
- Abuse Mitigation:
- @myachan warned of DDoS risks via mass reactions from bot accounts across instances.
- @Speykious downplayed this, noting emoji size (5–20KB) makes it inefficient for attacks.
- Permissions: @myachan suggested restricting cross-instance reactions behind Plutonium, but @gustave opposed this, arguing it should be instance-specific.

Final Conclusion:
- Reactions will be stored on the target instance, with emojis referenced via URLs.
- Indefinite caching of emojis is preferred to prevent broken links.
- No Plutonium restrictions for cross-instance emojis (@gustave, @myachan).

Citations:
- @maelstrom (2026-03-02 09:14:52)
- @myachan (2026-03-03 20:32:39, 2026-03-03 20:35:07, 2026-03-03 20:57:50)
- @Speykious (2026-03-03 20:33:36–20:47:26)
- @bricklou (2026-03-03 20:40:37)
- @gustave (2026-03-03 20:59:55)

5. Moderation and Compliance

5.1 Moderation in Federated Environments

Problem/Concept:
Handling moderation (e.g., illegal content, spam) across decentralized instances without central control.

Deliberations & Considerations:
- Instance-Level Moderation: Each instance moderates its own communities.
- Cross-Instance Coordination:
- Blocklists/Warnlists: Instances share moderation lists (e.g., via .well-known endpoints).
- Trust Systems: Verified instances get "checkmarks" for safety.
- Tradeoffs:
- Blocklists risk fragmentation (e.g., political defederation).
- Central moderation lists contradict decentralization.

Final Conclusion:
- Instance-level moderation is primary; cross-instance lists are optional.
- No central moderation body; legal compliance is the instance owner’s responsibility.

Citations:
- @florian (2026-02-21 23:43:05, 2026-02-22 02:06:58)
- @fizz (2026-02-22 02:31:39)
- @kate (2026-02-22 03:11:57)

5.2 Instance Blocking and Moderation

Problem/Concept:
Mechanism to block untrusted homeservers (instances) from others, focusing on safety and moderation.

Deliberations & Considerations:
- Per-Instance Defederation:
- Requires synchronized allow/block lists visible only to instance operators to avoid Fediverse-like drama.
- Distributed Trusted Server List:
- Proposed: Servers share trust status; untrusted servers get isolated.
- Blocklist Models:
- Centralized: Operator-controlled lists (reduces abuse but limits community input).
- Open lists (e.g., DNSBL): Community-driven but prone to misuse.
- Tradeoffs: Centralized control reduces drama but may slow response to threats; open lists increase transparency but risk false positives.

Final Conclusion:
- Instance blocking is planned for Federation v2.
- Synchronized operator-visible lists preferred; distributed lists remain theoretical.

Citations:
- @meowergirl (2026-03-20 12:48:04, 2026-03-20 12:48:24)
- @jce (2026-03-20 12:49:33, 2026-03-20 13:33:17)
- @astromahdi (2026-03-20 13:46:00, 2026-03-20 13:50:05)
- @parkervcp (2026-03-20 13:51:05)

5.3 Operator Pass as a Compliance Mechanism

Problem/Concept:
Using an "Operator Pass" to vet self-hosted instances for inclusion in official apps.

Deliberations & Considerations:
- @spff proposed that operators could "register" instances for app inclusion, enabling moderation.
- @jce questioned if this would create a two-tier system (official vs. self-hosted).
- NOTE: @jce: The really big issue is actually requiring a payment to Fluxer Platform AB in order for other instances to be vetted in official clients. - Either there's no vetting and end-users will just log into any instance without guidance or official clients will additionally provide a list of vetted instances that adhere to an agreement, similar to what Mastodon does with their Mastodon Server Covenant: https://joinmastodon.org/covenant - Tradeoffs: Centralized vetting improves compliance but contradicts decentralization; manual registration adds friction.

Final Conclusion:
- @spff framed it as a pragmatic compromise, but no consensus was reached.

Citations:
- @spff (2026-02-24 00:27:17)
- @jce (2026-02-24 00:49:05)

6. Self-Hosting and Deployment

6.1 Self-Hosting and Docker Images

Problem/Concept:
Challenges in self-hosting Fluxer instances due to incomplete Docker images and dependencies.

Deliberations & Considerations:
- Docker Image Issues:
- Official images (e.g., ghcr.io/fluxerapp/fluxer-server:stable) are missing.
- Third-party scripts (e.g., shadowflee3/fluxer-selfhost) use AI-generated configs, raising security concerns.
- Workarounds:
- Build images from source using turbo run build and docker build.
- Manual configuration of dependencies (Cassandra, Caddy, etc.).

Final Conclusion:
- Self-hosting is possible but requires manual builds and configurations.
- Official Docker images are pending federation stabilization.

Citations:
- @achie (2026-02-22 03:27:47)
- @myachan (2026-02-22 20:04:37)
- @nin0 (2026-02-23 11:12:00)

6.2 Self-Hosted Instance Support in Mobile Apps

Problem/Concept:
Concerns about whether self-hosted Fluxer instances will be accessible in official mobile apps without requiring users to fork/publish custom apps.

Deliberations & Considerations:
- @spff argued that excluding self-hosted instances would fragment the ecosystem and violate decentralization principles.
- @jce countered that multi-instance login already exists in the desktop client, implying mobile support is inevitable.
- @hypno referenced Mastodon’s mobile apps (e.g., Tusky) as proof that custom instance support is technically feasible.
- Tradeoffs: Allowing custom instances risks app store rejections (Apple/Google) due to "harmful content" policies.

Final Conclusion:
- No final decision, but @jce expressed optimism that mobile support would align with desktop capabilities.
- @spff proposed the Operator Pass as a potential solution (see Topic 5.3).

Citations:
- @spff (2026-02-24 00:25:37, 2026-02-24 00:26:02)
- @jce (2026-02-24 00:48:25, 2026-02-24 00:49:05)
- @hypno (2026-02-24 00:56:44)

6.3 Self-Hosting and Instance Scalability

Problem/Concept:
Enabling self-hosting for data sovereignty while ensuring federation scales from small (10 users) to large (10M users) instances.

Deliberations & Considerations:
- Challenges:
- Instance discovery and management.
- Moderation tooling for different scales (e.g., anti-spam for large instances).
- Avoiding over-engineering for small hosts.
- Solutions:
- Tiered Moderation: Two tiers of moderation services (basic/advanced) for instance owners.
- Protocol Simplicity: Prioritize identity federation to reduce infra burden.
- Tradeoffs: Overbuilding moderation tools may bloat small instances; underbuilding risks safety.

Final Conclusion:
- Partial: Tiered moderation and protocol simplicity are prioritized. Scalability is addressed via design flexibility.
- Final: Self-hosting is core to federation, but scaling is managed through moderation tiers.

Citations:
- @Lilith (2026-03-19 21:44:06)
- @jce (2026-03-19 21:33:17)
- @Shadow_Mare (2026-03-17 21:53:12)

7. User Experience and Features

7.1 Plutonium Features in Federated Contexts

Problem/Concept:
How premium "Plutonium" features (e.g., enhanced analytics, advanced moderation) function in federated communities hosted on other instances.

Deliberations & Considerations:
- Tradeoff: Feature availability vs. instance autonomy.
- @Didi questioned whether Plutonium features would extend to communities on external instances.
- @gustave clarified Plutonium is instance-specific: Self-hosted instances enable Plutonium locally, but federated communities inherit features only if their host instance supports Plutonium. This preserves instance autonomy but creates feature fragmentation.
- Tradeoff: Cost vs. value.
- Plutonium offsets hosting costs for self-hosters but may deter adoption if unavailable in federated communities.

Final Conclusion:
- Plutonium features are per-instance, not globally federated.
- Users gain Plutonium benefits only in communities hosted on Plutonium-enabled instances.

Citations:
- @Didi (2026-03-01 22:59:48)
- @gustave (2026-03-01 23:02:12)

7.2 Plutonium Features Cross-Instance Availability

Problem/Concept:
Whether Plutonium (premium) features (e.g., external stickers, high-quality streaming) function when users interact with servers on other instances.

Deliberations & Considerations:
- Per-Instance Subscription Model: Requiring users to purchase Plutonium on every instance they use (e.g., @glyph argued this diminishes value proposition, as users would need "dozens of subscriptions").
- Resource vs. Non-Resource Features: @gustave proposed resource-heavy features (e.g., large file uploads, high-bitrate streaming) should be behind Plutonium to offset costs, while non-resource features (e.g., global emojis) could remain free.
- Fairness Concerns: @jce noted that if one instance offers generous Plutonium tiers, users from other instances could exploit benefits without contributing to that instance’s costs.
- User Experience: @maelstrom suggested a "main instance" model where Plutonium is only required for the primary instance (e.g., web.fluxer.app), but acknowledged this may not align with developer plans.

Final Conclusion:
- No final decision; consensus that per-instance subscriptions are impractical (@glyph, @maelstrom).
- Likely outcome: Plutonium features will be instance-specific, not cross-instance (@maelstrom, @gustave).

Citations:
- @Didi (2026-03-02 00:06:23)
- @jakubiszon26 (2026-03-02 02:11:31)
- @jce (2026-03-02 02:16:22)
- @maelstrom (2026-03-02 09:13:50, 2026-03-02 09:42:21, 2026-03-02 09:42:47)
- @glyph (2026-03-02 09:36:21)
- @gustave (2026-03-02 09:54:51, 2026-03-02 10:02:39)
- @jce (2026-03-03 16:45:38)

7.3 Push Notification Constraints for Federated Instances

Problem/Concept:
Ensuring reliable, low-battery push notifications for third-party instances without compromising privacy or violating app store rules.

Deliberations & Considerations:
- @proteusnexus explained that iOS/Android require a single push service with baked-in keys, making decentralized notifications challenging.
- @rupx noted that Zulip’s relay service (used for push notifications) introduces privacy risks by acting as a middleman.
- @proteusnexus highlighted that Signal forks failed due to battery drain from polling-based push alternatives.
- Tradeoffs: Centralized relays (e.g., Zulip) simplify implementation but sacrifice privacy; E2EE encryption adds complexity.

Final Conclusion:
- @proteusnexus concluded E2EE for notifications is "solvable but requires careful implementation."
- @rupx warned that battery drain remains a critical risk for polling-based solutions.

Citations:
- @proteusnexus (2026-02-24 03:49:14, 2026-02-24 03:51:01, 2026-02-24 03:51:18, 2026-02-24 03:53:30)
- @rupx (2026-02-24 03:50:58)

7.4 Notification Handling in Federation

Problem/Concept:
How notifications (e.g., @ mentions) are delivered across instances without constant connections.

Deliberations & Considerations:
- @Vero proposed periodic pings from instances to followed instances to check for notifications.

Final Conclusion:
- Periodic pings are a viable solution for notification delivery (@Vero).

Citations:
- @Vero (2026-03-04 09:40:42)

8. Technical Implementation and Tools

8.1 Snowflake Entropy and Abuse Mitigation

Problem/Concept:
Using snowflake identifiers to prevent instance ID clashes, but addressing intentional abuse.

Deliberations & Considerations:
- Snowflakes provide high entropy to avoid accidental collisions.
- However, they cannot deter malicious actors who deliberately generate conflicting IDs.
- PKI or other authority mechanisms were implied as necessary for abuse prevention.

Final Conclusion:
- Snowflakes are sufficient for non-malicious scenarios but inadequate for abuse-resistant systems.

Citations:
- @Atakku (2026-03-05 01:57:25)

8.2 Chat Summarization for Technical Discussions

Problem/Concept:
Automating distillation of chat logs into actionable federation topics using AI.

Deliberations & Considerations:
- AI Approach:
- Locally hosted LLM (e.g., Olmo) parses logs every 6 hours, generating Markdown summaries.
- System prompt excludes off-topic discussions (e.g., E2EE) to focus on federation.
- Tradeoffs:
- AI handles volume but risks missing nuances; human review is essential.
- Output includes timestamps/usernames for traceability.
- Output Format:
- Summaries feed into GitHub discussions or RFC-style documents.

Final Conclusion:
- AI summarization is being implemented (Olmo) to distill discussions.
- Human refinement will ensure accuracy before formal proposals.

Citations:
- @astromahdi (2026-03-20 20:31:38, 2026-03-21 02:01:18, 2026-03-21 15:09:17)
- @skyibis (2026-03-20 20:53:57, 2026-03-20 21:57:26)

8.3 Scalability in Federation v1

Problem/Concept:
Addressing performance limits (e.g., 200-instance cap per client) in v1.

Deliberations & Considerations:
- Instance Limit:
- 200 instances/client is sufficient for most users but may bottleneck power users.
- WebSocket Overhead:
- Multiple connections strain client resources.
- Proposed Solution:
- A dedicated intermediary program connects to all backend servers and aggregates messages into one WebSocket.
- Tradeoffs: Adds complexity but mitigates client-side load; v2 federation will resolve this.

Final Conclusion:
- 200-instance limit is acceptable for v1.
- Intermediary program is a viable workaround for edge cases.

Citations:
- @Lilith (2026-03-21 16:33:07)
- @pilkey (2026-03-21 16:38:08)
- @bricklou (2026-03-21 17:00:02, 2026-03-21 17:01:17)

Summary of Key Decisions

Unresolved Topics:
- Full federation (v2) scope and implementation
- ATproto integration for content federation
- Instance blocking mechanisms
- Operator Pass compliance framework
- Cross-instance Plutonium feature sharing