Fluxer isn't federated yet. Each instance, including fluxer.com, is separate, and an account on one instance can't join communities on another. Federation is item 3 on our Roadmap 2026, with an experimental draft planned for 2026 and a stable release in the first half of 2027, and each instance will always be able to choose whether to turn it on.
What is federation?
Federation lets people on different instances talk to each other, the way email works between providers. It will always be optional, and every instance can run without it.
In Fluxer, federation will mainly be about identity. It will give you one identity for signing in to communities on other instances and let you move your account, and everything else stays Fluxer's own protocol between your app and the instance that hosts a community. We want to keep federation simple, and Fluxer won't become another Matrix.
Is Fluxer federated or decentralised?
Not today. Fluxer is open source, so anyone can run their own instance, but instances don't talk to each other, and no federation code has shipped yet. Once it arrives, each instance can choose whether to turn it on, and every instance will keep working without it.
Is Fluxer based on Matrix?
No. Fluxer has its own API and real-time gateway, and when federation comes, we'll build it on polyproto-core, the base specification of polyproto, with our own extensions.
What is polyproto?
polyproto is a family of federation protocols maintained by the Polyphony project, and polyproto-core is its base specification. For an introduction, watch How to outlive your home server, a 43-minute talk by Flori Ava Star at Datenspuren 2026.
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, and the official chat extension, polyproto-chat, is in early alpha. We'll write our own extensions for Fluxer's features, and if a change would help other polyproto implementations too, we'll suggest adding it to the specification itself.
Will one account work across instances?
Yes, that's the plan. polyproto-core defines an identity that works across instances. Your home server is the instance with your account, such as fluxer.com or your own, and it will give you an identity in the form name@domain that you'll use to sign in to communities on other instances. You won't have to make a separate account on each of them.
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 instance, your device signs a challenge from that instance, which then checks your certificate with your home server.
Can another instance pretend to be me?
No. Your device signs every message you send, and other instances and apps check the signature against your certificate and your home server's. An instance 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.
Why polyproto and not Matrix?
The main reason is where a community is stored. Matrix is the best-known federated chat protocol, and every Matrix server with a member in a room keeps its own copy of that room, while a Fluxer community will be stored only on the instance that hosts it.
That choice keeps an instance admin responsible only for content they chose to host, keeps self-hosting cheap and makes one copy of each community easier to get right. polyproto-core also lets you move your account to another instance and lets Fluxer keep its own API. The trade-off is that a community is unavailable while its instance is offline.
Where will a federated community be stored?
A federated Fluxer 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, and their app connects to it directly, or through their home server if they prefer. Either way, their home server doesn't store or cache a copy of the community, its messages or its files.
That's our own choice, since polyproto-core doesn't decide where a community's data is stored. We use it so people can sign in elsewhere with their home identity, and if a use case ever needs more than that, we'll set limits and keep one copy of each community.
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, meaning its name, settings, members and permissions, and every message sent since the server joined.
Older history comes from other servers in the room when users scroll back. No copy is official, and each server works out the state from the events it has.
What happens when I delete a message on another instance?
In Fluxer, only the instance that hosts a community stores its messages. When you delete a message, that instance removes it under its retention rules, and no other instance has a copy to clean up. For fluxer.com, section 7.3 of our privacy policy says how long deleted messages can stay in backups, and for other instances, their privacy policy tells you.
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 after a redaction. A redaction also doesn't remove the files attached to the message from the media caches of other servers in the room.
Keeping messages on one instance also means an instance admin is only responsible for content they chose to host. In Matrix, if someone posts illegal content in a room, every server with a member in that room stores a copy, and each of those servers also stores any older history its users scroll back to and caches the media their apps load.
Will a small instance have to store large communities?
No. A Fluxer instance stores data only for its own users and the communities it hosts. 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 still a heavy load for a small server at home.
How will permissions work across instances?
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.
With no server in charge, 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 version 12.
One case the algorithm handles is an admin removing a moderator's permissions while the moderator, on another server, bans another user. Servers can get the 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, because each event lists the earlier events it follows, and events sent at the same time on different servers have no set order.
Will I be able to move my account to another instance?
Yes, that's the plan. Moving your account to another instance is part of polyproto-core, the base specification that Fluxer's federation will be built on. As in Matrix, your address includes your home server's domain, and it will change to the new instance's domain when you move. polyproto-core also defines how your old identity hands over to the new one.
While your old instance is online, your old account will be able to redirect to the new one, and you can export your data there and import it on the new one. Messages you posted on other instances stay where they are, and you can re-sign them with your new identity.
Each instance keeps the original message 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 instance already knows your old certificate and it hasn't banned you.
In Matrix, a user ID like @name:example.org contains its home server's domain, and it's written into every event you send and into each room's membership and permission records. You can't move to another home server with your identity and message history. Proposals working toward that include 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.
Will Fluxer keep its own API with federation?
Yes. Fluxer has an API, a real-time gateway and a permission system, and because polyproto lets a project define its features as a p2 extension, we can describe Fluxer's API as one and keep it working. 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.
What happens to a community when its instance goes offline?
If the instance that hosts a community goes offline, the community is unavailable until it's back, and communities hosted on other instances keep working as normal. No other instance has a copy of the community. A Matrix room stays available as long as any one server in it is still online, and that's the trade-off of keeping one copy.
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.
Will Fluxer federate with Matrix?
No. Fluxer won't federate with Matrix directly, and a bridge can connect the two, as bridges already do for Matrix and many other chat platforms such as Discord and Slack. There's no official bridge from Fluxer to Matrix or to any other network.
When is federation coming?
The roadmap plans an experimental draft in 2026 and a stable release in the first half of 2027, and we don't have exact dates yet. The draft will be a pull request in the open source Fluxer software to try and give feedback on, and our patch notes will say when it's ready. We discuss federation in Fluxer Labs, our community, and anyone can join.
What can I do before federation is out?
You can run your own Fluxer instance today and invite people to make accounts on it, and you can export your data from your account at any time.
Can I already use accounts on several instances?
Yes, and it works without federation. The desktop app keeps your accounts on fluxer.com and on self-hosted instances connected at the same time, and switching between them usually doesn't need a reconnect. Each account still belongs to its own instance, and the next step is combining all your accounts from every instance into one view in the app.