Roadmap 2026

This is our plan for the rest of 2026 and into 2027.

Item	When
#1: Mobile apps on the App Store and Google Play	In public beta now, full release in 2026
#2: Self-hosting and the Operator Pass	Server install, docs and desktop app support available now. Operator Pass waitlist in early October 2026 and sales from early November 2026. A combined view across instances and moving communities to your own instance come later
#3: A new voice and video system with encrypted calls	2026
#4: Federation	Experimental draft in 2026, stable in 2027
#5: End-to-end encryption for notes, DMs and group DMs	Experimental draft in 2026, stable in 2027
#6: Threads, forums and publishing to the web	2026
#7: Slash commands, components and interactions for bots	2026
#8: Equip emoji and stickers from communities	2026
#9: Creator payments	2027 or later

#1: Mobile apps on the App Store and Google Play

The mobile apps are in public beta. You can use them today through TestFlight on iOS or the Google Play beta on Android, and both are linked from our download page. A mobile app developer has joined the team, and we're making the apps more stable for a full release on the App Store and Google Play in 2026.

#2: Self-hosting and the Operator Pass

Fluxer is free, open source software under the AGPLv3 license. Anyone can run, study, change and share its code. If you change it and offer it to others over a network, you share your source code under the same license. Running your own copy on your own server is called self-hosting. Each copy is called an instance. Fluxer.app is the instance we run, and it's free to use.

Self-hosting work happens in public on GitHub. You can install Fluxer on a server today with Docker images and an installer script, and the self-hosting documentation walks you through setting up your own instance.

As of 12 October 2026, the desktop app connects to self-hosted instances. When you first open the app, it asks which instance to use. You can sign in to accounts on as many instances as you like and switch between them instantly.

The Flathub version is waiting on an update and might not support self-hosting yet. If you don't want to wait, uninstall it and install our own Flatpak.

The desktop app keeps every account on every instance connected in the background at once. You can switch between accounts instantly and get push notifications from all of them. Accounts you aren't looking at keep their data in a small cache on disk and don't slow the app down. Press Ctrl+K, or Cmd+K on macOS, to open the Quick Switcher. It shows unread messages and mentions from all your accounts and takes you straight to that account's view.

What's left is combining your accounts from different instances into a single view, and that's next on the roadmap. It doesn't need federation. Real federation comes later, as described in #4. We spent months reworking how the desktop app works, and that work makes a single view possible.

Later, you'll also be able to export your communities from Fluxer.app and import them onto your own instance. We haven't decided exactly how that will work yet.

The Operator Pass is an optional one-time purchase for people who self-host Fluxer. It unlocks nothing in the software, and self-hosting stays free without it. Buying it directly funds work that makes self-hosting Fluxer better for everyone. The waitlist opens in early October 2026, and sales start in early November 2026. The price is $199 or €199, and it goes up on 1 January 2027. The Operator Pass page explains what you get.

#3: A new voice and video system with encrypted calls

We're replacing LiveKit, the voice and video software Fluxer uses today, with our own server and call client built around how Fluxer works. The work is almost finished, and it ships in 2026.

• In our benchmarks it's faster and uses less memory than our LiveKit setup. It can also share bandwidth and server capacity fairly between users, which keeps CPU usage predictable and makes voice servers easier to plan and scale.
• Every call will be end-to-end encrypted with DAVE, the protocol Discord built for encrypted calls.
  • There will be no setting to turn it off and no unencrypted fallback.
  • Our clients run libdave, the open source library Discord published for DAVE. It is built natively for the desktop app and compiled to WebAssembly for the browser.
  • In a call you'll be able to see a privacy code for the whole call and compare a verification code with any other participant. Once you mark someone as verified, the app warns you if their key changes.
  • Trail of Bits reviewed Discord's design in 2023 and Discord's implementation in 2024, and both reports are public. Our own code has not been audited.
• Calls will no longer connect through WebRTC.
  • Audio and video travel as RTP packets inside QUIC datagrams, and QUIC handles the encrypted connection to the voice server.
  • Discord's desktop and mobile apps have skipped WebRTC's usual connection setup and encryption for years. Discord has written that it uses its own signaling and encryption over plain UDP, on a media engine built on the WebRTC native library, and that only its browser app uses the browser's full WebRTC stack.
  • Browsers can now do without it too. The WebTransport API gives a web page QUIC streams and unreliable datagrams over HTTP/3, and the WebCodecs API gives it direct access to audio and video encoders and decoders.
  • We depend less on how each browser and platform supports WebRTC and on its quirks, and the stack is simpler to maintain.
  • Joining a call is faster, and we can see what's happening at every step.
  • The browser version needs a recent browser that supports both APIs. The desktop app still uses the WebRTC project's audio processing module, and nothing else from WebRTC.
• Streams are separate from calls. Each stream gets its own connection and its own process on the server. A problem with a stream is less likely to affect the call, and a stream can handle far more viewers without slowing the call down.
• The browser and the desktop app share Rust code for packetizing video, checking codecs and driving DAVE. It runs through WebAssembly in the browser and natively in the desktop app. The mobile apps will move to the new system as well.
• The gateway, the part of Fluxer that keeps clients up to date in real time, tells the voice servers who is in which call directly. This prevents the mismatches that came from keeping that information in sync with LiveKit.

Adding a voice server to a self-hosted instance also gets much simpler. You set a registration token when you set up the machine, and your instance picks up the server automatically. The admin panel shows each server's health and load, and calls are never sent to a server that's unhealthy.

#4: Federation

Federation lets people on different instances talk to each other. Email works the same way between providers. We'll build Fluxer's federation on polyproto-core and add our own extensions. polyproto-core is the base specification of polyproto, a family of federation protocols maintained by the Polyphony project. polyproto is still young. We hope our implementation, and what we learn from writing it, helps the specification mature. For an introduction to polyproto, watch How to outlive your home server, a 43-minute talk by Flori Ava Star at Datenspuren 2026.

polyproto-core defines an identity that works across servers. Your home server is the instance that has your account. It issues your identity, in the form name@domain. Each time you sign in, your device creates a key pair for that session and keeps the private key. Your home server issues a certificate for the public key, called an ID-Cert. To prove who you are to another server, your device signs a challenge from that server, and that server checks your certificate with your home server. You don't need a separate account on each server.

Your device also signs every message you send. Other servers and clients check the signature against your certificate and your home server's. A server you visit never has your private key, and it can't forge a message from you. This assumes your device hasn't been compromised and your home server is run honestly.

As of October 2026 polyproto-core is at v1.0-beta.14, and the specification calls itself an early beta. It leaves message formats and chat features to extensions, which it calls p2 extensions. The official chat extension, polyproto-chat, is in early alpha. We'll write extensions for Fluxer's features. Where a change would help other implementations too, we'll propose it to the specification.

Signing in to several instances from one app is separate from federation. You sign in to each instance with its own account and switch between them in the app. The desktop and mobile apps both support this.

Why polyproto and not Matrix

Matrix is the best-known federated chat protocol, and we're often asked why we don't use it. The main reason is where a community's messages are stored.

In Matrix, each channel is its own room, and rooms can be grouped into a space. A room doesn't belong to one server. Every server with a joined member keeps its own copy of the room. Over time that copy holds the room's full current state and every message sent since the server joined. The state is the room's name, settings, member list and who has which permissions. Older history is fetched from other servers when users scroll back. No copy is authoritative. Each server works out the room's state from the events it holds.

In Fluxer, a community will be stored only on the instance that hosts it. People from other instances sign in to that instance with the identity from their home server. Their app connects to that instance directly, or through their home server if they prefer. Either way, their home server doesn't store a copy of the community. polyproto-core doesn't decide where a community's data is stored, and this design is our own choice. We use polyproto-core so people can sign in to another server with their home identity.

We want this for legal reasons. An operator should be responsible only for content it chose to host. If someone posts illegal content in a Matrix room, every server with a member in that room stores a copy. Each of those servers also stores any older history its users scroll back to and caches the media their apps load. Deleting a message in Matrix sends a redaction to every server in the room. The specification requires each server to strip the content from its own copy. No other server can check that it did. Synapse, the most widely used Matrix server, keeps the original for seven days by default. A redaction also doesn't remove files attached to the message from other servers' media caches. In a Fluxer community, the hosting instance holds the only server copy of a message. Deleting the message removes it.

Storing each community in one place also keeps self-hosting cheap. A server that joins a large Matrix room ends up downloading and storing the room's full state. That state includes a membership event for every user who has ever been invited, joined, left or been banned. Faster joins let a server start using the room before all of it arrives, and the rest downloads in the background. That is a heavy load for a small server on a spare computer at home. A Fluxer instance stores data only for its own users and the communities it hosts.

One copy of each community is also simpler to implement correctly. With no server in charge of room state, every Matrix server has to compute the same state from the same events, even when some servers send conflicting or malicious ones. Matrix does this with a state resolution algorithm. One case it handles is an admin removing a moderator's permissions while the moderator, on another server, bans someone. Servers can receive those two events in different orders, and all of them still have to agree on whether the ban counts. The algorithm was redesigned in room version 2 and revised again in room version 12. Matrix orders events only partly. Each event lists the earlier events it follows, and events sent at the same time on different servers have no set order. In Fluxer, the instance that hosts a community gives each message an ID that sorts by creation time, and it checks permissions itself. That's how Fluxer works today, and we can keep the permission system you already use.

Accounts are the second reason. A Matrix user ID like @name:example.org contains its home server's domain. It is written into every event you send and into each room's membership and permission records. You can't move to another home server and take your identity and message history with you. Several proposals work toward that, including MSC2787, MSC4014, MSC4243 and MSC4348. As of October 2026 all of them are still open. Each changes how events or room permissions work, and Matrix can only make changes like that in a new room version.

Migration is part of polyproto-core itself. As in Matrix, your address includes your home server's domain, and it changes when you move. polyproto-core also defines how your old identity hands over to the new one. Your old account can redirect to your new one while your old home server is still online. Messages you posted on other servers, for example in communities, stay where they are, and you can re-sign them with your new identity. Each server keeps the original and adds a version with the new signature. That works even if your old home server is gone, as long as you still have your old keys, the server already knows your old certificate and it hasn't banned you. While your old home server is online, you can also export the data stored there and import it on the new one.

The third reason is how much of Fluxer we can keep. Fluxer already has an API, a real-time gateway and a permission system. polyproto lets a project define its own features as a p2 extension. We can describe Fluxer's existing API as one and keep it working as it does today. As shared extensions such as polyproto-chat mature, we can move parts of it to them. On Matrix, we would have to rebuild Fluxer's features on top of Matrix rooms.

Each community depends on one instance. If that instance goes offline, the community is unavailable until it's back. Communities hosted on other instances keep working in the meantime. No other instance has a copy. Operators should back up their own instances. The operator of the hosting instance can also shut a community down on their own. A Matrix room stays available as long as any server in it is online.

Fluxer won't federate with Matrix directly. A bridge can connect the two, as bridges already connect Matrix to many other chat platforms.

We'll publish an experimental draft pull request in 2026 that you can try and give feedback on. The stable release follows in 2027. Until then, we're discussing federation in Fluxer Labs, and you're welcome to join.

#5: End-to-end encryption for notes, DMs and group DMs

End-to-end encryption (E2EE) means that only the sender and the people a message is meant for can read it. As Wikipedia's article on end-to-end encryption describes it, messages are encrypted on the sender's device so that no third party, including the service provider, has the means to decrypt them, and the recipients decrypt them on their own devices. That is different from encryption in transit, where the service can still read your messages once they reach its servers.

The usual building block is a pair of keys for each person. The public key is safe to share and is used to encrypt, and the private key stays on that person's device and is the only thing that can decrypt.

End-to-end encryption does not protect a device that has itself been broken into, and it depends on knowing that a key really belongs to the person you think it does.

Fluxer will add end-to-end encryption to personal notes, DMs and group DMs. It will be required, with no setting to turn it off. We're building it on MLS (Messaging Layer Security), an IETF Standards Track protocol published as RFC 9420 in July 2023.

MLS was designed for group conversations. The members' devices agree on shared keys that the server never has, and messages are encrypted with those keys. Each device is normally its own member of the group, and the group's keys change whenever its membership changes. It is designed so that the server delivering the messages cannot read them, as long as members' keys are verified independently of that server.

Some things stay visible to the server, for example who is in a conversation and when messages are sent. MLS itself also doesn't give a new device the messages that were sent before it joined. We haven't written this encryption yet. How your history reaches a new device, and how you check that a key really belongs to the person you're talking to, are things the experimental draft has to answer. For calls, that check already exists as the verification codes described in #3.

Group DMs also grow from 50 to 250 members as part of this work, on the same timeline as the encryption. That needs backend changes so our real-time infrastructure scales to groups that size. Communities, the large public spaces with moderation and search, are not part of this plan.

polyproto, the family of specifications behind our federation plans in #4, includes polyproto-mls. It is a separate extension from polyproto-core, based on the same MLS standard, and as of October 2026 it is at an alpha version. We will most likely build our encryption in line with it and help finish it.

An experimental draft that you can try arrives in 2026, and the stable release follows in 2027.

Voice and video calls come first. They get required end-to-end encryption in 2026, using DAVE on the new voice system described in #3.

#6: Threads, forums and publishing to the web

Fluxer will get threads and forums in 2026, and forum channels will have an optional public web mode in the same year. If a community turns it on, anyone can read those posts without an account, find them through search engines, archive them, and follow them with RSS or Atom feeds. Communities choose what to publish, and private chats stay private.

#7: Slash commands, components and interactions for bots

Bots and integrations on Fluxer will get slash commands, modals, buttons and other components, and interactions in 2026. Commands that bots register themselves are already in active development.

#8: Equip emoji and stickers from communities

On many chat platforms, you have to stay in a community to keep using its emoji and stickers elsewhere. In 2026, Fluxer will let you equip emoji and stickers from a community you're in, and keep them on your account after you leave.

On Fluxer.app, equipping will be part of Plutonium, the same as using custom emoji and stickers across communities is today. Inside a community, everyone can use its emoji and stickers for free, animated ones included. Each community can already have up to 500 emoji and 500 stickers. On self-hosted instances, equipping follows the limits the operator sets.

#9: Creator payments

Creator payments are planned for 2027 or later. Fluxer could let fans pay to unlock roles and exclusive content in a creator's community. That access could be permanent or time-limited, as a one-time purchase or a recurring subscription. Creators could also sell tickets for events, where a ticket or temporary role opens specific text and voice channels for the length of the event.

Creators on Fluxer.app could then run their community and take payments from supporters in one place. Fluxer.app would handle the payments and take a small fee, likely between 5 and 10%. That fee would pay for hosting and for the people who work on both Fluxer.app and the open source software.

Patreon and Discord have each tried to combine community chat with paid memberships, with mixed results. If Fluxer gets it right, the fee helps keep Fluxer.app generous for free users, pays for improvements that also reach self-hosted instances, and gives Fluxer more financial freedom to keep working on open source software.

Patreon is adding a Discord-like chat feature for creators and fans

The Discord integration will still be available.

The VergeMia Sato

Get involved

You can help shape the roadmap by joining Fluxer Labs or by reporting bugs and requesting features on Fluxer Feedback. You can also support Fluxer directly.

• Donate any amount, as an individual or a business.
• Subscribe to Plutonium, the optional paid subscription on Fluxer.app with higher limits.
• Get the Operator Pass if you self-host, once sales start in early November 2026.
• Tell your friends and followers about Fluxer.

Closing thoughts

See you in the Fluxerverse!