---
title: "Roadmap 2026"
description: "What we're building for Fluxer in 2026 and 2027, including end-to-end encryption for calls, DMs and group DMs, optional federation and public forums."
url: "https://canary.fluxer.com/blog/roadmap-2026"
language: "en"
last_updated: "2026-11-01"
author: "Hampus Kraft"
published: "2026-01-26"
category: "Announcements"
---

> Index of Fluxer's official pages for AI agents: https://canary.fluxer.com/llms.txt
> Links to Fluxer pages go to their Markdown versions when they have one. For other Fluxer help, policy or blog links, remove any #section part and add .md to the end.

# Roadmap 2026

What we're building for Fluxer in 2026 and 2027, including end-to-end encryption for calls, DMs and group DMs, optional federation and public forums.

This is our plan for the rest of 2026 and into 2027, with dates for every item in the table below. The biggest items are optional federation and end-to-end encryption for calls, personal notes, DMs and group DMs. All of it goes into the free and open source Fluxer software (AGPLv3), which anyone can run on their own server.

> [Self-hosting and the Operator Pass](https://canary.fluxer.com/blog/self-hosting-and-the-operator-pass.md)
>
> How to run Fluxer as a self-hosted Discord alternative, how the desktop and mobile apps connect to your instance, and what the Operator Pass is.
>
> Source: Fluxer blog / Hampus Kraft

| Item | When |
| --- | --- |
| #1: Mobile apps on the App Store and Google Play | We expect iOS on the App Store in early November 2026, Android in 2026 |
| #2: A new voice and video system with encrypted calls | 2026 |
| #3: Federation | Experimental draft in 2026, stable in 2027 |
| #4: End-to-end encryption for notes, DMs and group DMs | Experimental draft in 2026, stable in 2027 |
| #5: Threads, forums and publishing to the web | Threads and forums in early beta now, public forums as an experimental draft in 2026 |
| #6: Slash commands, components and interactions for bots | 2026 |
| #7: Equip emoji and stickers from communities | 2026 |
| #8: Creator payments | 2027 or later |

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

The mobile apps are in public beta, and they've been [open source](https://canary.fluxer.com/blog/fluxer-on-ios-and-android.md) on GitHub since June 15, 2026. On Android you can [download them](https://canary.fluxer.com/download) through the [Google Play beta](https://play.google.com/store/apps/details?id=com.fluxer).

The iOS beta on TestFlight [is on hold for now](https://canary.fluxer.com/help/ios-testflight.md) following a technical issue at Apple, and we expect the iOS app on the [App Store](https://canary.fluxer.com/help/fluxer-app-store.md) in early November 2026, without TestFlight invites or limited slots. We're making the Android app more stable for its full release on Google Play later in 2026, and we want it out as soon as possible.

## #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 on it 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](https://github.com/discord/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](https://github.com/trailofbits/publications/blob/master/reviews/2024-08-discord-dave-protocol-designreview.pdf) and [implementation](https://github.com/trailofbits/publications/blob/master/reviews/2024-09-discord-dave-protocol-codereview.pdf) in 2024, and both reports are public. Our own code has not been audited.
- Calls on it will no longer connect through WebRTC.
  - Audio and video are sent as RTP packets inside [QUIC](https://developer.mozilla.org/en-US/docs/Glossary/QUIC) datagrams, and QUIC encrypts the connection from the app to the voice server.
  - Discord's native apps have [used their own signaling and encryption over plain UDP](https://discord.com/blog/how-discord-handles-two-and-half-million-concurrent-voice-users-using-webrtc) for years, and only its browser app uses the browser's WebRTC.
  - Browsers can do without WebRTC too. The [WebTransport API](https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API) gives a web page QUIC streams and unreliable datagrams over HTTP/3, and the [WebCodecs API](https://developer.mozilla.org/en-US/docs/Web/API/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, and 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](https://polyproto.org/), 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](https://media.ccc.de/v/ds26-627-how-to-outlive-your-home-server-the-polyproto-federation-protocol), 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](https://polyproto.org/docs/protocols/core), 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](https://matrix.org/) 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, and 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.

The first reason is legal, because an instance admin 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](https://spec.matrix.org/v1.19/client-server-api/#redactions) 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](https://element-hq.github.io/synapse/latest/usage/configuration/config_documentation.html#redaction_retention_period) 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](https://canary.fluxer.com/privacy.md) 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](https://spec.matrix.org/v1.19/rooms/v2/#state-resolution), 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.

The second reason is accounts, because 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](https://github.com/matrix-org/matrix-spec-proposals/pull/2787), [MSC4014](https://github.com/matrix-org/matrix-spec-proposals/pull/4014), [MSC4243](https://github.com/matrix-org/matrix-spec-proposals/pull/4243) and [MSC4348](https://github.com/matrix-org/matrix-spec-proposals/pull/4348).

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. Because polyproto lets a project define its own features as a p2 extension, we can describe Fluxer's API as one and keep it working as it is. 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.

Instance admins should back up their instances regularly. If the hosting instance's admin shuts a community down, no other instance has a copy to keep it going. A Matrix room stays available as long as any one server in it is still 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, and the stable release will follow in 2027. Until then, we're discussing federation in [Fluxer Labs](https://fluxer.gg/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](https://en.wikipedia.org/wiki/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's servers can decrypt them once they arrive.

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.

![Diagram of public-key encryption: Alice encrypts the message Hello Bob! with Bob's public key, it travels as unreadable scrambled data, and Bob decrypts it with his private key.](https://canary.fluxer.com/static/img/blog-assets-e2ee-public-key-encryption.467fd48b1a3a89d3.webp)

Public-key encryption, the building block of end-to-end encryption. Alice encrypts with Bob's public key, and only Bob's private key can decrypt. Diagram by Winstonlee, based on one by David Göthberg, from [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Public_key_encryption_alice_to_bob.svg), [CC0](https://creativecommons.org/publicdomain/zero/1.0/deed.en).

Fluxer will add end-to-end encryption to personal notes, DMs and group DMs, 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](https://www.rfc-editor.org/rfc/rfc9420.html) in July 2023.

In MLS, which was designed for group conversations, the members' devices agree on shared keys that the server never has and encrypt messages with them. 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 will 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 to Fluxer's server software. Communities, which are the large public spaces with moderation and search, are not part of this plan.

Communities work differently in Fluxer's server software, and we haven't worked out how end-to-end encryption would fit them. For smaller groups, we plan to let you tie a group DM to a community, though we haven't set a date for it yet.

The app would show it with that community and leave it out of your DM list, and it would be an end-to-end encrypted group DM of up to 250 members.

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 get end-to-end encryption first. In 2026, every call on the new voice and video system from #2 will use DAVE, with no unencrypted fallback.

## #5: Threads, forums and publishing to the web

Threads and forums are in [early beta](https://canary.fluxer.com/blog/patch-notes-2026-10-16.md) for everyone on web, desktop, iOS and Android, and forum channels will get an optional [public web mode](https://canary.fluxer.com/blog/how-i-built-fluxer.md). You'll be able to try an experimental draft of public forums before the end of 2026. Anyone will be able to read the posts in a public forum without having an account, find them in search engines, save them in archives and follow them with RSS or Atom feeds.

A community will decide whether a forum channel is public when it creates the channel, and a private forum channel won't be able to become public later. Everyone who posts in a public forum will be able to see that it's public before they write anything.

Announcement channels will also be able to get a public page with RSS and Atom feeds, but only if the community turns that on for that specific channel. Messages in regular chat channels, DMs and group DMs will never be published on the web.

A public forum page will show only the posts people wrote themselves. Fluxer runs no generative AI or LLM over your messages, files or calls, whether they're on a public forum or anywhere else. [Section 5 of our privacy policy](https://canary.fluxer.com/privacy.md) lists the automated safety checks we do run, such as an image classifier for explicit content preferences.

## #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.

We'd also like to let people without Plutonium equip at least a few of their favorite emoji and stickers to use across communities. Plutonium helps fund the cost of running fluxer.com, and we're still working out how much of this we can offer for free.

## #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 fund hosting fluxer.com and developing both fluxer.com and the open source software behind it.

Like the rest of the roadmap, 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 what creators on them receive from fans.

## Get involved

You can have a say in the roadmap by joining [Fluxer Labs](https://fluxer.gg/fluxer-labs) or by reporting bugs and requesting features on [Fluxer Feedback](https://feedback.fluxer.com). When a change started as a post there, our [patch notes](https://canary.fluxer.com/blog/patch-notes-2026-10-24.md) credit whoever posted it. You can also support Fluxer directly.

- [Donate](https://canary.fluxer.com/donate) once, every month or every year, as an individual or a business.
- [Subscribe to Plutonium](https://canary.fluxer.com/plutonium) for higher limits on fluxer.com.
- Get an [Operator Pass](https://canary.fluxer.com/pass), an optional one-time purchase that supports Fluxer and isn't needed to self-host. You can buy one on [the Operator Pass page](https://canary.fluxer.com/pass).
- Tell your friends and followers about Fluxer.

## Closing thoughts

See you in the Fluxerverse!

[Video](https://canary.fluxer.com/static/img/blog-assets-tenor-delorean.da4d7758292a5583.mp4)

A DeLorean time machine lifts off, heading for new adventures.

---

Canonical page: https://canary.fluxer.com/blog/roadmap-2026

Last updated on November 1, 2026