How I built Fluxer, a Discord-like chat app

I'm Hampus Kraft, a 22-year-old software developer from Sweden. I'm nearing completion of my BSc in Computer Engineering at KTH Royal Institute of Technology. You can find my LinkedIn page here.

In Sweden, our citizen and company registration databases are public records that you can check using a regular search engine. I'm an open book!

Ever since 2020, when the pandemic hit and I was still in senior high school, I've been fascinated by Discord, the instant messaging and VoIP chat platform with over 200 million MAU that took the world by storm.

What I'm about to introduce is a brand new OSS community chat app I've worked on solo, on and off, for the past 5 years. I believe it's one of the closest public attempts at feature parity with platforms like Discord or Slack to date.

And it's all free and open source software (AGPLv3).

Fluxer in 60 seconds

flux /flŭks/

A continuing movement, especially in large numbers of things.
Constant or frequent change; fluctuation.
"Flux capacitor ... fluxing!" (Back to the Future)

Why use Fluxer when Discord is free and works well? And, realistically, why trust a new product that could disappear next week?

If Discord does what you need, and you're fine relying on a proprietary, investor-driven platform and have no concerns about their upcoming IPO, then you probably don't need Fluxer. I'm not trying to compete with Discord's network effect by fearmongering.

Fluxer is for people who want different incentives: free, open source, self-hostable software, with an optional hosted version run by an independent, European-owned provider.

Fluxer is also among the closest, if not the closest, replications of the state-of-the-art feature set and UX that we've all grown accustomed to on centralised proprietary platforms such as Discord or Slack.

Fluxer's success isn't contingent on Discord getting worse. I'm building something I believe the tech community has been missing, where people are generally more willing to switch to a credible alternative if one shows up.

Discord's network effect is hard to beat head-on, so I'm focusing where switching is already plausible: technical users and communities that value control and transparency, and want software they can run on their own terms. Others may simply prefer a European-owned instance run without venture capital, with clearer incentives.

Fluxer is free and open source (AGPLv3), and the core principle is simple: it's always the same software. The business model is built around giving people multiple ways to support Fluxer, depending on how they want to use it:

First, we run an official hosted freemium instance. It's free to use and it has a Plutonium subscription for users who want higher limits. We also offer a limited-time lifetime Visionary plan for early supporters.
Second, we accept donations from individuals and organisations who self-host Fluxer and still want to contribute to its development. You can also support Fluxer regularly via GitHub Sponsors.
Third, for people who self-host and want help, we offer paid support through a one-time Operator Pass. That gives you direct contact with the team for help with deployment and day-to-day operations.
Finally, we can offer commercial licences to companies that want to run Fluxer internally without being bound by the AGPLv3 copyleft terms. This is enabled via a contributor-friendly CLA, but it doesn't create a separate "enterprise edition". It's still the same Fluxer software everyone else uses.
Fluxer doesn't currently offer managed hosting, but if there's interest, I'm happy to offer managed instances of the Fluxer Server and the LiveKit voice server, including managed backups. Just let me know!

If you don't like the free tier limits on the hosted instance and you don't want to pay for Plutonium, you can always run your own instance. Fluxer is committed to not paywalling parts of the software or requiring licence key checks. It also won't force upgrades to unlock quotas on software you run yourself. No SSO tax!

Now, my backstory

2017–2020

I first started using Discord in 2017, and my interest in the platform only grew over time. By January 2019, I had joined Discord Testers, their crowd-sourced bug reporting programme, and by April 2019 I'd earned enough XP to unlock the Bug Hunter badge. Around the same time, I was also accepted into Discord's HypeSquad Events programme, though I never got the chance to represent Discord at any events.

2020–2022

When the pandemic hit, I suddenly had a lot more time while studying from home to learn new things and improve my skills. Until then, programming wasn't something I took all that seriously, but the project I had in mind kept pulling me back.

During my senior high school years, I worked on early prototypes of what is now Fluxer. My final graduation project became that prototype, along with a technical report detailing what I'd learned from studying Discord's technical blog posts and architecture, and how I applied those ideas in practice.

When I graduated in summer 2022, I received a small $200 scholarship from the school, and the title "Web Guru of the Year."

2022–2023

I've been a student at KTH Royal Institute of Technology since autumn 2022. By summer 2023, I decided to focus more actively on Fluxer. However, my studies still took up much of my time, so progress was sporadic, with stretches of downtime.

In October 2022, I co-authored a medium-severity bug bounty report for a permission bypass vulnerability and submitted it to Discord's security team. The report earned my co-author and me a shared award of $1,500.

While I was studying, I ended up leading the web development for a popular Minecraft: Bedrock Edition server with nearly 6 million registered players. I built and ran the production systems for the web side, spending a lot of time on API design and security, plus billing and reliability.

It was a very valuable experience, and it was also nice to be paid while learning how to run things at that scale. I still help them out every now and then to maintain my codebases even though I don't actively work there anymore!

2023–2024

In July 2023, I released the first private alpha of Fluxer to a few dozen initial testers. Since then, I've iterated on the tech stack many times before settling on what I'm running today.

The current stack is heavily inspired by Discord and, to some extent, WhatsApp. It leans on battle-tested technologies like Cassandra (though self-hosters can use SQLite instead) and Erlang/OTP. I did try simpler alternatives to avoid unnecessary complexity, but I kept running into the same problem: I'd end up reinventing the wheel for problems that proven technologies already solve well.

Those iterations, along with continued research into Discord's architecture, have paid off. I dug through Reddit and Hacker News posts from Discord employees, public Discord conversations with their engineers, and a lot of blog posts and postmortems. I also implemented ideas in practice to understand the tradeoffs. In parallel, I deepened my understanding of distributed systems both independently and through coursework.

My studies at KTH cover computer science and network security, plus software testing and distributed systems. That has helped me build a strong technical foundation.

My degree programme also emphasises applying and demonstrating knowledge in practice through projects. In spring 2024, I joined a project course where we delivered an internal tool for Giesecke+Devrient, an international security technology company.

2025

In January 2025, I grew wary of how Discord handled my personal data and where the platform was headed. I built Discorch, a tool that guides you through Discord's undocumented privacy request process to bulk delete messages. It produces a CSV plus instructions for contacting Discord's privacy team to request deletion.

As more people used it, Discord kept changing the process and eventually imposed arbitrary limits, including blocking deletion of your own DM messages through this route because you can still delete them manually, limiting it to only left servers & groups.

In spring 2025, I reported a security vulnerability to Discord that could have enabled unauthorised destructive actions against critical user-owned data without proper authentication, and I was awarded $2,000. Later that summer, I registered Fluxer Platform AB, a Swedish limited liability company, which required a minimum deposit of $2,000.

Maeby from Arrested Development: "Well, that was a freebie."

After nearing completion of most of my university courses and spending the entire summer of 2025 partnering up with a fellow student to complete our bachelor thesis (on behalf of the supportive and welcoming Intelligent Heart Technology Lab at KTH), our thesis was finally published in September 2025.

Between September–December 2025, I worked diligently, day and night, to make a public release of Fluxer a reality. It wasn't easy. Making this project production-ready in terms of system architecture and feature parity, alongside a very complex web client, all by myself, is one of the most challenging things I've done to date.

On October 25, I launched the first public beta since I needed some revenue to keep going, and I gained a handful of Visionaries ($299 each) from early testers who'd been supportive of my work since 2023, when the first rudimentary alpha was made available. I kept working towards feature completion on this very complex platform.

2026

And this brings us to the present year of 2026. On January 2, 2026, I tried to do a Show HN, to no avail (a bit surprising, given that this is a topic that gets brought up on HN almost every other week, with users being quite frustrated with the existing OSS community chat options).

At the same time, I also launched on Product Hunt, which gained me some more traction. Since this soft launch, I've raised some extra funding through Visionary purchases, but it still isn't quite enough for me to get by yet. Paying myself a salary in Sweden involves a lot of government fees and taxes.

Fluxer prioritises a familiar UX you know from platforms you already use, and it strives to implement all the features you're accustomed to. The feature coverage is already quite high, higher than that of existing alternatives, and the usability is pretty much on par with the classic Discord experience. You'll feel right at home.

I'm looking for more funding to keep going from anyone who's interested in supporting an independent communication platform. I want it to stay fully bootstrapped without venture capital, and to answer to users rather than investors. It should remain fully free and open source software under the AGPLv3, without restrictions on self-hosting.

With your support, Fluxer can become the open and self-hostable communication platform you want. That might be financial through the Operator Pass, a custom donation, or issues and PRs in the GitHub repo.

Fluxer's backend (hello Mike!)

Discord's backend scaling work has been well documented over the years, and the engineering team have been unusually open about how they build and operate things. Their posts have been a big inspiration for me. A few of the ones I'd start with:

I've got a lot of respect for their engineers, but I'm less enthusiastic about some of Discord's product management and business decisions. At the same time, a usable self-hosted alternative still doesn't really exist.

Realistically, no sane person would pour this much time and energy into building something truly viable. Mainly because it's demotivating work, since people usually won't pay until the platform is already on par with what they expect.

What kept me going was a slightly obsessive desire to understand Discord's architecture in depth. That meant reading loads of HN and Reddit threads, digging through postmortems and blog posts, taking relevant courses at KTH as part of my degree programme, and building up professional experience along the way.

On top of that, I've been active in Discord's meta communities for years, regularly engaging with fellow Discord enthusiasts, security researchers, and bug hunters. I've spoken with Discord engineers directly on several occasions.

With that level of insight into Discord's development and the pain points people have with Discord, I'm not just some random person trying to build a Discord clone. I'm in an unusual position to use my know-how to build a truly viable alternative to proprietary community chat apps, and that's what I want to do with Fluxer.

It's pretty much just TypeScript with a pinch of Erlang

Fluxer's backend is split across a handful of projects, but for a typical self-hosted deployment you only need to run:

Fluxer Server (TypeScript)
- An umbrella project that wraps several modules with zero external deps. In Fluxer.app's production environment, these are deployed separately: HTTP API, Worker, Media Proxy, App, S3, Queue, KV, and Admin.

Fluxer.app's production instance uses Cassandra for persistence, while self-hosted instances use SQLite by default. Fluxer uses Orama as an embedded full-text search engine, with the database remaining the source of truth.
LiveKit is an optional dependency that enables voice and video. You can deploy it separately. LiveKit SFUs can run wherever you like and don't need to be co-located with your Fluxer server.

In fact, you will probably want to deploy it separately, since it typically requires opening multiple firewall ports for WebRTC (primarily UDP) to ensure client connectivity.
Cloudflare Tunnels (or similar) are an easy way to run the Fluxer server at home on a NAS, old PC, or Raspberry Pi without opening inbound ports. However, tunnels only proxy HTTP and WebSockets, so they won't work for LiveKit's media ports. If you run LiveKit at home, you'll need port forwarding, or deploy LiveKit on a host with a public IP.

Fluxer Gateway (Erlang)
- Written in Erlang to take advantage of its strengths for soft real-time systems and hot code swapping, so you can replace code while the application is running without losing live state or connections.
- For self-hosting, the Gateway is bundled into the same Docker image as the Fluxer Server, so you still just run a single Fluxer Server container.

If you're self-hosting Fluxer, you typically pull the Fluxer Server image, which includes the Server plus the Gateway. The Fluxer Server proxies requests to the Gateway internally, so you only need to expose the Fluxer Server port behind an HTTPS reverse proxy such as Caddy, or directly via something like Cloudflare Tunnels. After that, you're good to go.

Why choose Erlang/OTP?

The Erlang runtime system is designed for distributed, fault-tolerant, soft real-time, highly available, non-stop applications, with the ability to use hot swapping to change code without stopping the system.

Hello Mike. Hello Joe. Hello Mike. Hello Robert. Hello Joe. Hello Mike. Hello Robert. Hello Mike. Hello. Looks like we fixed the bug!

It was originally developed as proprietary software at Ericsson, a Swedish telecom company, by Joe Armstrong (who wrote his PhD thesis at my university, KTH Royal Institute of Technology, in the year I was born), Robert Virding, and Mike Williams in 1986. It was released as FOSS in 1998, and is maintained by the OTP unit at Ericsson.

Notable uses of Erlang/OTP at a very large scale include WhatsApp, plus Discord via Elixir (which compiles to Erlang). WhatsApp surpasses the scale of Discord by several magnitudes. With more than 3 billion MAU globally, it's largely built on top of Erlang, and they got there with a minimal headcount.

I've tried out a lot of iterations of the real-time system to finally learn the truth:

"Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang."

– Robert Virding, co-creator of Erlang

Fluxer's real-time system is built like so, heavily inspired by how Discord works, and is, to a large extent, wire-compatible with Discord's protocol to make it easier to port existing Discord gateway bots to Fluxer:

When you connect to the WebSocket Gateway, you're asked to identify yourself with your authentication token.
The "session manager" handles the payload and sends an HTTP request over the internal network to an authenticated API monolith RPC endpoint.
If correctly authenticated, all data needed to build your "ready" payload, and the initial client state, is constructed, along with an array of all guild IDs you're a member of. This operation will read from the database in parallel, and hit caches when possible.
You're internally synchronised to presence updates and guild events through a dual-monitoring system, where your Session GenServers connect to your Presence GenServer, acting as the point of ingress for direct user dispatches to fan out to all your connected sessions only. Your Session also connects to all Guild GenServers you're a member of. With monitoring on each side, side effects can be performed when processes exit for any reason.
The Guild GenServer holds an up-to-date cache, kept in sync from API event dispatches to the Guild, of guild properties and members, plus channels and roles. This lets it determine which sessions are eligible to receive an event scoped to a specific channel.
Each Session maintains an in-memory buffer of received events to allow replaying missed events without reconstructing your entire "ready" state from scratch if you briefly lose your network connection. WebSocket connections linked to a Session will periodically acknowledge received sequence numbers to truncate its in-memory buffer.
Messages mentioning you are queued for mobile push notifications, and that queue is truncated as you read them. If you're away from your desktop and not currently active on mobile, you may be eligible to receive any pending push notifications for messages you haven't yet read.
A lot of work has gone into not loading every single guild member or presence update into your client in real time. Things work lazily, on par with the optimisations Discord has made.

I can't reasonably describe how this system works in full in one sitting. Once I've tested this architecture in practice with a larger number of real users, I'll write a series of blog posts explaining how it works and the challenges I ran into. But kudos to the engineering team at Discord for the inspiration!

Why choose Cassandra?

Cassandra is what the Fluxer.app instance uses in production. I added SQLite support and it's the default storage method for self-hosted instances!

For a long time, ScyllaDB was my database of choice. Discord also migrated to it after running Cassandra. As of December 2024, though, ScyllaDB is no longer open source software, which is a deal-breaker for me.

I completely understand @scylladb.com's challenge with maintaining an OSS/open core business model. On the other hand, I'm not sure I would have chosen ScyllaDB for Bluesky PBC's infra if there wasn't an OSS version. So this is unfortunate but I can't blame them for doing what they need to do.
— Jake Gold (@jacob.gold) 2024-12-19T03:29:31.546Z

All databases suck. I like Cassandra and I despise it at the same time. I still use it because it lets me not have to think about a bunch of things, and because it matches Fluxer's write-heavy, event-driven design.

First, Cassandra makes it hard to be accidentally inefficient. You have to think upfront about how your data is modelled and queried, because inefficient queries are either impossible or very explicitly opt-in (hello, ALLOW FILTERING).

Second, Cassandra prioritises high write throughput, and Fluxer is built to avoid reads as much as possible. Its eventual consistency is an acceptable tradeoff to get that write path. When you send a message on Fluxer, you generally only hit the database with a single foreground read to validate your auth session. Permissions are handled via RPCs to the Erlang Gateway service, which keeps an in-memory cache of everything needed to compute permissions in a community (called a guild internally). Clients mostly read from the database when starting a new session to populate initial state. After that, everything stays in sync via the event dispatching system.

Third, operationally, Cassandra removes an entire class of problems I've struggled with in traditional RDBMS setups. Postgres can absolutely be made fast, but it also gives you more ways to shoot yourself in the foot: JOINs, tuning indexes, locking behaviour, and sometimes needing downtime for certain migrations. With Cassandra, schema changes are always zero-downtime and there are no locks. I like that!

Finally, Cassandra is a great fit for how Fluxer represents message rows. Things like unfurled link content and file attachments, plus similar metadata, are best stored as embedded documents. Cassandra gives you rich types like sets and maps, along with user-defined types that can be nested, typed, and stored efficiently. That avoids querying extra tables to assemble a single document, or using untyped JSON blobs.

Building Fluxer's data model using an RDBMS generally felt more "icky" than using a NoSQL database, so it's not about premature optimisation, but rather personal preference after evaluating a variety of options for this specific use case.

You mentioned SQLite for self-hosted instances?

Yes. Since I already had an abstraction layer in place for Cassandra, adding centralised SQLite support was fairly straightforward.

Because Cassandra behaves like a key-key-value (KKV) store (partition key + clustering key, where the clustering key identifies a specific row within a partition), I already had to design my tables and queries so that every lookup requires knowing the full key, or at least a sufficiently specific leading part of it for SELECT queries.

In Cassandra, secondary indexes are typically implemented at the application level using additional tables optimised for alternative access patterns. These are maintained on writes (via logged batches), with optional denormalisation depending on how important it is to avoid an extra read to fetch the full primary row. Materialised views and native secondary indexes exist, but they come with caveats that can make them risky in production.

Given those constraints, adding SQLite support was simple: I could use a single key-value table and avoid relying on SQLite's relational features. In practice, I treat SQLite as a blob store keyed by the same enforced keys as Cassandra, with efficient prefix range queries for listing and scans, reusing my custom Cassandra query builder.

I'm open to adding support for other databases too. Realistically, with this abstraction in place, I could support just about any database, as long as you're OK with it falling back to a single table of serialised blobs when it's not Cassandra.

Fluxer's frontend (have mercy!)

Fluxer's web app codebase is quite complex, and it also supports a mobile web-based experience through a PWA that can be installed on your home screen, with push notification support when the app is closed and you're not active on desktop. This is by no means perfect, or the desired endgame for mobile, since a lot of things simply can't be achieved on mobile web, and the UX doesn't feel native.

I'm looking into using Skip to develop the native mobile app for Fluxer. It was recently made FOSS, and it seems like the most promising option besides Kotlin Multiplatform. Skip also provides a rationale for why they believe Skip is better than KMP.

A lot of work has gone into this web app to make it on par with Discord. The amount of complexity involved is insane, especially with regard to the message scroller (a surprisingly difficult thing to make work correctly with infinite scrolling, maintaining scroll position, bounded caches, jumping in time, state reconciliation, unread handling, etc.) and my entirely custom-built Discord Markdown-compatible parser and renderer (with some custom extensions like GFM-like alerts and more), with an extensive test suite.

I'd very much like to develop a fully native app, but as a soon-to-be graduate who's trying to start a fully bootstrapped business with no external investment, all I've got is my MacBook Air M1 (2020, 8GB RAM) and remote SSH development to a Hetzner VPS with more RAM to be able to work on Fluxer. Developing a native app sets entirely different hardware requirements that would, in practice, have prevented me from shipping this already quite usable experience if I'd made that a blocking requirement.

With your donations and other financial support, I'll hopefully be able to make enough revenue to pay myself a modest salary to keep going, which includes hardware upgrades for me to get started on a native app (I'm also very open to anyone who wants to develop third-party clients too, or help make official native clients a reality, no matter which platform!). You can send me an email at hampus@fluxer.app.

Unlike Discord, Fluxer welcomes all kinds of client modifications – custom themes, non-malicious account automation, third-party clients, and anything else that tickles your fancy. Oh, and it’s all FOSS anyway so you’re most welcome to upstream things if it aligns with the goals of the project! Just be sure to open an issue first to discuss it :)

Electron? Right to jail, right away

Fluxer currently uses Electron. I know, I know. I'm not too happy about it either. Tauri isn't as mature yet, and I ran into hurdles there that I simply didn't have to deal with in Electron. In the spirit of choosing boring technology, Electron unfortunately wins. A lot of apps give Electron a bad name, but it doesn't have to be that way.

The biggest selling point of Tauri is also its biggest drawback: it uses the system webview. That sounds great on paper, but it means the desktop app is ultimately at the mercy of whatever runtime the OS happens to provide, with whatever bugs and quirks come with it. And when those bugs happen, you can't just ship a fix by updating your runtime, because the runtime is tied to OS updates.

I will reevaluate Tauri when there's a mature, supported option for shipping a consistent runtime with it, like CEF (cef-rs).

For most people, Electron is an acceptable choice. The ideal is a fully native app, and I'm very open to contributions that move us in that direction. But I'm one person, and native development isn't part of my skill set. Even with LLMs, I can't make native development productive or reliable enough to maintain.

I use LLMs to extend what I already know, double-check my work, and speed up repetitive tasks. That only works when I've got enough prior knowledge to evaluate the output. If I don't understand a platform well enough to verify what I'm shipping, then I can't ship it. It's as simple as that. I'm trying to use LLMs responsibly.

The web platform is ultimately my area of expertise. It's what lets me, and apps like Discord, Slack, and Microsoft Teams, build cross-platform experiences while also supporting web users from the same codebase.

That's the priority for me (and for many others): something that just works. I'd rather ship a consistent, reliable experience than chase technical purity and end up with behaviour that varies by platform, more bugs, and worse accessibility. And if you prefer it that way, you can also install the web app as a PWA on desktop, just like on mobile.

The LLMephant in the room

Fluxer was largely built before LLMs became a normal part of day-to-day development. I do use them now, but in a limited way: as a rubber duck and for mechanical implementation work when I already have a detailed spec. I treat the code it outputs like I would any external contribution.

No LLM designed the system, wrote the specs, or made architectural decisions. That was all me. I only use LLMs when I already know the platform well enough to review the result properly.

Ultimately, you'll have to take my word for it that I'm trying to handle this responsibly. Fluxer is a large, complicated codebase because the project itself is large and complicated. LLMs still aren't capable of autonomously producing anything like what Fluxer is today.

If it were that easy to create something this polished on a whim using only LLMs, we'd already be swimming in credible Discord alternatives.

In short, for Fluxer: PRs should be reviewable, understandable, and test-backed. Submitting generated code you cannot explain, or using an LLM to bypass review standards, isn't acceptable. At the same time, responsible use of LLMs as a tool is fine, and contributors should not be harassed for using them.

From our CONTRIBUTING.md:

You must have sufficient understanding of every change in your PR to explain it and defend it during review. You don't need to write an essay, but you should be able to give a short summary of what the patch does and why it's correct.

LLM-assisted contributions. You're welcome to use LLMs as a tool for automating mechanical work. We don't ask you to disclose this, since we assume you're acting in good faith: you're the one who signs off on the patch you submit in your own name, and you have the technical understanding to verify that it's accurate.

That said, don't use LLMs on areas of the codebase you don't understand well enough to verify the output. If part of your change touches code you aren't confident reviewing yourself, say so in the issue you opened beforehand and defer that work to someone else. The maintainers will be happy to help.

Moreover, the OSS release began from a clean slate, so the public commit count doesn't reflect the full private iteration timeline, how long it has been deployed in production, or how extensively it has been tested. Going forward, what matters is that contributions will be reviewed, and tests will be required where appropriate. I also don't condone low-effort, unreviewed AI slop.

I published the project with a squashed history because the early work happened privately, and I didn't want to make 3,000+ messy commits part of the public record. I'm proud of where things are now, and the codebase has improved a lot over the 3+ years it was developed in private.

Squashing commits during a closed source to open source transition is common practice, and it doesn't imply the project was vibe-coded.

This is my work, and it's hard-earned. If something seems too good to be true, it's because I've put real effort into making it good.

I get that in the age of LLMs, people are more suspicious and may assume bad intent behind every project. But some projects come from true passion and domain understanding. That's the case for Fluxer.

I could've built and maintained this platform without using LLMs for the mechanical parts of the work. It just would've taken about three times as long. At that pace, I'd need a full-time job to make a living, and then I wouldn't have time for Fluxer anyway. This is the world we live in, and sometimes compromises are unavoidable.

Starting with no money, the realistic options were to raise VC funding (since most people won't back a project like this until it's already close to what they expect), or to use LLMs in a limited, controlled way to speed up the mechanical tasks. I chose the latter so the project could stay independent.

If you feel conflicted about this, know that I do too. I'm happier writing code by hand. Going forward, LLMs don't need to be quite as involved. Now that I've released publicly, I don't necessarily need to work on this alone, and I've prepared the codebase to make it attractive to people who want to self-host the software.

I hope to find a small group of like-minded individuals, or even occasional one-off contributors, who want to help build Fluxer. From here on, Fluxer is maintained by the community as free and open source software. I also hope to use donations and other funding to support community maintainers, including bounties for specific work.

I don't think a single VC-backed platform, pending an IPO, should be the only realistic option in this space. Like Mastodon, I want Fluxer to be a credible independent alternative: transparent and community-developed, and built around different values.

If that's something you want to support, contributors are welcome. If donations make it possible, I'd also consider bounties for specific work. My goal is to make Fluxer sustainable and community-developed.

Frequently asked questions

What about the open web?

This is something I'd like Fluxer to do something about. Fluxer will eventually have a discovery system of public forum channels, Atom/RSS feeds, and server-side rendered, public, unauthenticated views of forum channels that can be found on search engines and archived, as an entirely opt-in thing to get the best of both worlds.

Discord seeks to solve a problem that it created | TechCrunch

Conversations on Discord can be hard to follow. Discord SVP Peter Sellis proposes making forum-like features, or using AI summaries.

TechCrunchAmanda Silberling

With LLMs, Sellis said, Discord could take a long, meandering conversation and turn it into “something that could be more sharable and syndicated across the web.” However, he said that he and his team hadn’t “seen a solution that we feel great about yet.”

On Fluxer, LLMs shouldn't be involved in this at all. I want to embrace the open web by supporting RSS and Atom feeds, and without altering anyone's content. After all, this feature would apply only to forum threads, not to the unstructured firehose of conversation in regular text channels.

This is not available yet during the public beta, but I feel strongly about it. If you do too, feel free to send a donation or support Fluxer's continued development in any of the other ways available, and drop a note in the Fluxer HQ community!

This looks a lot like Discord!

The UX is intentionally close to the classic Discord experience (and Discord itself borrows heavily from Slack and similar products). If you want a Discord-like product, familiarity is a pretty important aspect.

Changing things just to be different, sacrificing usability and inventing new unproven patterns for the thrill of it, only adds friction and makes adoption harder. I've aimed for differentiation where it clearly improves the product, but a lot of these patterns are common across chat apps for a reason.

I've tried a bunch of different takes on the UX, and they always end up messy. Just look at contemporary attempts to recreate the Discord experience while prioritising novelty over usability, like Root. I've tried those alternatives, and so have many others I've spoken to, and we keep reaching the same conclusion: the UX is awful.

Is Discord's UX perfect? Of course not! But it's simple and familiar. Most OSS community chat options fall down because they won't lean into a UX users already know, and they still don't match the feature set people expect. The result is that, to most users, they look and feel bad.

Having an experience similar to classic Discord is also nostalgic for many of us longtime Discord users, from before they began redesigning the UI.

That said, Fluxer lets you fully customise your client's look with custom CSS, and it'll continue to. More UI takes are always appreciated!

I've built a Discord bot. Will it work on Fluxer?

Yesn't! Fluxer's HTTP API and WebSocket Gateway API are heavily inspired by Discord's and, in many cases, are directly wire compatible with it. That means you can reuse existing Discord libraries and abstractions in many languages.

For example, you can use the core libraries from discord.js directly. It's a bit more low level, but it will take you very far. The Fluxer API docs guide you through a quick start using this approach. Forking existing Discord libraries and modifying them slightly will also get you far. Or you could create your own community-maintained Fluxer SDK, and email me (hampus@fluxer.app) to get it featured in the docs (or submit a pull request in the GitHub repository).

Slash commands and similar features aren't implemented yet, though. If you want this added, you can support Fluxer through Visionary or donations.

End-to-end encryption? Federation?

I currently don't have a focus on E2EE because of how complex it is, and how it compromises every single core app feature that people expect to work like on Discord (syncing history across devices, message search, key management).

If I went full-on E2EE initially, I'd likely end up in the same situation as Matrix, with users criticising it for broken UX and missing features that Discord can deliver easily because of its centralised and unencrypted architecture. Self-hosting would also end up more complicated and clients would be more resource-intensive.

Why We Abandoned Matrix (2024) | Hacker News

Hacker News

What many actually want is not privacy maximalism but a reliable, feature-complete, non-E2EE Discord alternative: fast clients, good search, profiles/statuses/custom emoji, straightforward roles and permissions, solid voice/video, and practical moderation tools that work.

I could see myself adding support for ephemeral private chats with friends in DMs that would disappear when both users close their clients, though.

Federation is in development! When it's available, it will use distributed, horizontally scalable, end-to-end encrypted federation relays that anyone can host. These relays route HTTP and WebSocket traffic to the correct target instance, and Fluxer will provide official relays.

OAuth2 is used to authenticate via your home instance when interacting with other instances. Other instances do not store data from outside their own instance.

How does moderation work?

Each Fluxer instance is responsible for its own moderation. Fluxer Platform AB operates the Fluxer.app instance, and the Fluxer Community Team (currently volunteer-based) handles in-app reports on Fluxer.app. Fluxer also includes a comprehensive admin panel for professionally run instances, with moderation tooling comparable to other large platforms.

Fluxer.app uses Shield by Project Arachnid to proactively detect known CSAM and other harmful or abusive imagery involving children. Shield is a free tool for eligible electronic service providers (ESPs). It compares media against a database of known digital fingerprints to help identify and remove matching content.

In our current integration, we submit the full file (image or video) to Project Arachnid's content-scanning API for analysis. Project Arachnid does not retain uploaded files. Over time, we plan to apply for access to Project Arachnid's hash lists so we can scan locally and reduce reliance on third-party APIs.

We are also a registered ESP with access to the CyberTipline Reporting API from the National Center for Missing & Exploited Children (NCMEC). This allows us to file reports when we detect matches that require reporting.

Once federation is available, each instance will still be responsible for its own moderation. Any enforcement action taken against your account on one instance will apply only to that instance. That means it would affect your access only to communities or users whose home server is hosted there.

Do you rely on American technology?

2026 isn't off to a great start. The American people put Donald Trump in charge of the nukes once again, and the rest of the world has to deal with it. The Onion might soon be out of business, because reality has become a parody of itself.

Relying on American technology is mostly unavoidable, but I've tried to avoid the most egregious offenders for the hosted Fluxer.app instance.

Fluxer uses the European CDN provider Bunny.net (not Cloudflare) to distribute static assets and user-generated content worldwide with low latency. None of the core application traffic is routed through Cloudflare.

Deutsche Telekom is throttling the internet | Hacker News

Hacker News

A major German ISP also has consistent issues accessing sites behind Cloudflare, particularly those on Cloudflare's free plan. One Deutsche Telekom user reports that, in the evenings, sites behind Cloudflare can take up to a minute to load or may not load at all. "I don't understand why anyone that serves the German market would use Cloudflare. Regardless of who is at fault, you are losing a lot of customers that way."

At the moment, Cloudflare is used for one thing only: client-side geolocation. It's the simplest way to comply with MaxMind's licence, and it's also the approach Bluesky uses, via a Cloudflare Worker that echoes back the user's country and region. Cloudflare already has a MaxMind Enterprise licence that permits this for user-facing functionality.

We use that region signal solely for legal compliance with age verification laws. Fluxer's response is to disable NSFW functionality entirely, regardless of a user's self-declared age, in the United Kingdom, South Dakota, Wyoming, Ohio, and Arizona. The entire state of Mississippi is additionally blocked from accessing the app entirely. These geographical restrictions apply only to the hosted Fluxer.app instance.

Bluesky initially made the same call as Fluxer, blocking Mississippi outright instead of implementing invasive, costly age verification. They later reversed course and introduced age verification anyway, but I don't see Fluxer doing the same.

This dependency is replaceable. However, Cloudflare Workers Paid is currently the cheapest straightforward legal option at $5 per month. I'm happy to swap it out for an alternative, but that likely requires sponsorship from a GeoIP database vendor. Wink wink, nudge nudge.

To protect against spam, Cloudflare's Turnstile is offered as the default CAPTCHA provider, but you can switch to hCaptcha if Turnstile doesn't work for you. If a privacy-first CAPTCHA provider would be willing to sponsor Fluxer, I'd be happy to make that the default on Fluxer.app!

For hosting, we use OVH, which is European-owned. The server is currently located in Virginia, USA, via OVH's American subsidiary, to provide acceptable latency for both Europe and the US West Coast.

In the future, federation could make it practical to offer hosted deployments in the EU or APAC for stronger data residency and lower regional latency. It's a direction worth pursuing if there's interest, but I'd need more funding to buy more servers.

Where's the roadmap?

Closing thoughts

Phew – if it isn't obvious, I care about this a lot. If you do too, I'd really appreciate your support: code contributions, one-off or recurring donations, or even a quick word of encouragement to @fluxer.app on Bluesky. With your help, Fluxer can grow into a chat platform that puts your interests first.

I want Fluxer to stay fully independent and bootstrapped. That means relying heavily on donations, whether one-off or recurring. It also means leaning on revenue from early supporters who pick up the Visionary or Operator Pass, as well as any revenue Plutonium generates on the hosted instance.

Got questions or concerns, or interested in partnering with Fluxer? Whether you're a content creator, run an open source project, manage a community of any size, or work at a CDN or trust and safety vendor, you can reach me directly at hampus@fluxer.app. If you're a fellow independent, bootstrapped, privacy-first alternative to the mainstream, or you're in the press, I'd love to talk too.

We've already come a long way, and I hope you've liked what you've seen so far. With your help, Fluxer can become a serious FOSS alternative to Discord.

See you in the Fluxerverse!

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

Become a Plutonium Visionary for a one-time fee of $299 or €299. You'll get lifetime Plutonium perks on the hosted instance, direct access to the team, and an included Operator Pass for prioritised support with self-hosting.

Learn more