Roadmap 2026

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

Self-hosting and the Operator Pass have their own post, which explains how to set up your own instance and how to connect the desktop and mobile apps to it.

Self-hosting and the Operator Pass

How to run your own Fluxer instance, how the desktop and mobile apps connect to it, and what the Operator Pass is.

Fluxer blogHampus Kraft

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

The mobile apps are in public beta. You can use them through TestFlight on iOS or the Google Play beta on Android, and both are on our download page. We're making them more stable for the full release on the App Store and Google Play later in 2026.

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

We're replacing LiveKit, the voice and video software Fluxer uses today, with our own voice server and our own call code in the apps, built around how Fluxer works. It's almost finished, and we plan to ship it in 2026 with end-to-end encrypted calls.

• 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 Discord's DAVE protocol.
  • There will be no setting to turn it off and no unencrypted fallback.
  • Our apps use libdave, Discord's open source DAVE library. 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 your verification code with anyone else who is in it. Once you mark someone as verified, the app will warn you if their key changes after that.
  • Trail of Bits reviewed Discord's design and 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 are sent as RTP packets inside QUIC datagrams, and QUIC handles the encrypted connection from the app 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 WebRTC.
  • 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 rely less on how each browser and platform handles WebRTC, with all its quirks, and the code for calls is simpler for us 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 uses only WebRTC's audio processing module.
• 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 running 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 is the part of Fluxer that keeps your apps up to date in real time, and it tells the voice servers directly who is in which call. That stops the mismatches we had when we kept that information in sync with LiveKit.

#3: Federation

Federation lets people on different instances talk to each other, the same way email works between providers. Federation will always be optional, and every instance can keep running without it. 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, and we hope our work on it and what we learn along the way help the specification mature. If you want an introduction, watch How to outlive your home server, a 43-minute talk that Flori Ava Star gave at Datenspuren 2026.

polyproto-core defines an identity that works across servers. Your home server is the instance with your account, and it gives you an identity like name@domain.

Each time you sign in, your device creates a key pair for that session and keeps the private key. Your home server then gives your device a certificate for that public key, called an ID-Cert. To prove who you are to another server, your device signs a challenge from that server, which then checks your certificate with your home server. You don't need to make a separate account on every server you use.

Your device also signs every message you send. Other servers and apps 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. That's true as long as nobody has broken into your device and your home server is being run honestly.

In October 2026, polyproto-core was at v1.0-beta.14, and the specification called 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 our own extensions for Fluxer's features. If a change would help other polyproto implementations too, we'll suggest adding it to the specification itself.

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 member in the room keeps its own copy. Over time that copy ends up with the room's full current state and every message sent since the server joined. The state is the room's name, settings, members and permissions. Older history comes from other servers when users scroll back.

No copy is official, and each server works out the state from the events it has.

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 it directly, or through their home server if they prefer.

Either way, their home server doesn't store a copy of the community. That's our own choice, since polyproto-core doesn't decide where a community's data is stored. 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 only be responsible for content they 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, but 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 the files attached to the message from the media caches of other servers in the room.

In a Fluxer community, the instance that hosts the community is the only server that stores its messages. When you delete a message, that instance removes it under its own retention rules, and no other server has a copy to clean up. On fluxer.com, section 7.3 of our privacy policy says how long a deleted message can stay in backups.

Storing each community in one place also keeps self-hosting cheap. A server that joins a large Matrix room downloads and stores its full state, including a membership event for everyone who has ever been invited, joined, left or been banned.

Matrix's faster joins feature lets a server start using the room before all of it arrives, and the rest downloads in the background. That's a heavy load for a small server at home. A Fluxer instance stores data only for its own users and the communities it hosts.

One copy of each community is also easier to get right. With no server in charge of room state, every Matrix server has to work out the same state from the same events, even when some send conflicting or malicious ones. Matrix does this with a state resolution algorithm, redesigned in room version 2 and revised in room version 12.

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.

Matrix doesn't put all events in one order. 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 it lets us keep the permission system that you already use in your communities.

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. There are several proposals working toward that, including MSC2787, MSC4014, MSC4243 and MSC4348.

In October 2026, all of them were still open. Each changes how events or room permissions work, and every room would have to move to a new room version.

Moving to another home server 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 online. Messages you posted on other servers stay put, 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 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'd have to rebuild Fluxer's features on top of rooms.

Each community depends on the one instance that hosts it, and no other instance has a copy. If that instance goes offline, the community is unavailable until it's back, and communities hosted on other instances keep working. Operators should back up their own instances. The hosting instance's operator 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 do for Matrix and many other chat platforms such as Discord and Slack.

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, our community on Fluxer, and you're welcome to join.

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

End-to-end encryption (E2EE) means only the sender and the people a message is meant for can read it. As Wikipedia's article on end-to-end encryption puts it, messages are encrypted on the sender's device so that no third party, including the service provider, can decrypt them, and the recipients decrypt them on their devices.

That is different from encryption in transit, which only protects messages on their way to the service, and the service can still read them once they get to 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 the messages encrypted with the public key.

End-to-end encryption can't protect you if someone has broken into your device, 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 standard that was 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 members change. It's designed so the server can't read the messages it delivers, as long as members check each other's keys without relying on that server.

Some things stay visible to the server, such as who is in a conversation and when messages are sent. MLS also doesn't give a new device messages sent before it joined. We haven't written this encryption yet. In the experimental draft, we'll work out how your history gets to a new device and how you check that a key belongs to the person you're talking to. For calls, the verification codes in #2 already let you do that.

As part of this work, group DMs will grow from 50 to 250 members, on the same timeline as the end-to-end encryption. For real-time updates to keep working in groups of that size, we'll need to make changes on our servers. Communities, which are the large public spaces with moderation and search, are not part of this plan.

The polyproto family behind our federation plans in #3 also includes polyproto-mls. It's separate from polyproto-core and uses the same MLS standard, and in October 2026 it was in alpha. We'll probably build our encryption to match it and help finish it.

An experimental draft will be out in 2026 and the stable release in 2027.

Voice and video calls come first. In 2026, every call on the new voice system from #2 will be end-to-end encrypted with DAVE, Discord's protocol for encrypted calls.

#5: Threads, forums and publishing to the web

Threads and forums are in early beta on web, desktop, iOS and Android, as our October patch notes say. In 2026, forum channels will also get an optional public web mode. If a community turns it on, anyone can read those posts without an account, find them in search engines, archive them and follow them with RSS or Atom feeds. Only the forum channels a community picks are published, and never DMs.

#6: Slash commands, components and interactions for bots

In 2026, bots and integrations will get slash commands, interactions and components like modals and buttons. We're working on custom bot commands.

#7: 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.com, equipping will be part of Plutonium, like 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 have up to 500 emoji and 500 stickers. On self-hosted instances, the instance sets the limits.

#8: 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, and fans could pay for it with a one-time purchase or a recurring subscription. Creators could also sell tickets for events, where a ticket or a temporary role opens specific text and voice channels for the length of the event.

Creators on fluxer.com could then run their community and take payments from supporters in one place. fluxer.com would handle the payments and take a fee, most likely between 5 and 10%. That fee would help pay for hosting fluxer.com and for developing both fluxer.com and the open source software behind it.

As with everything we build, self-hosted instances would get creator payments too, and because those instances are run by separate people and organizations, Fluxer wouldn't take a cut of the payments that creators on them receive from fans.

Patreon and Discord have each tried to combine community chat with paid memberships in their own way. If Fluxer gets it right, the fee helps keep fluxer.com generous for free users, pays for improvements that also come to self-hosted instances, and gives Fluxer more money 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 have a say in the roadmap by joining Fluxer Labs or by reporting bugs and requesting features on Fluxer Feedback. You can also support Fluxer directly.

• Donate once, every month or every year, as an individual or a business.
• Subscribe to Plutonium for higher limits on fluxer.com.
• Join the waitlist for the Operator Pass, an optional one-time purchase that supports Fluxer and isn't needed to self-host. Sales open on November 1, 2026.
• Tell your friends and followers about Fluxer.

Closing thoughts

See you in the Fluxerverse!