How I built Fluxer, a Discord-like chat app

This article is currently under revision since a lot happened on 9 February. Fluxer now has a substantial amount of funding and traction to become a truly viable commercial alternative to Discord. Thanks to all the Visionaries and other supporters who helped make this happen!

We now also have a new hire beyond myself :D

After Discord's age-verification announcement, Visionary sold out quickly: we sold around 1,000 copies at $299 each before pausing sales. Visionaries are recognised in-app with a numbered badge that shows how early they supported Fluxer.

I'm Hampus Kraft, a 23-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 resident 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 exploiting its users, 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 offered a limited-time lifetime Visionary plan for early supporters. It sold out at 1,000-ish copies before we stopped it!
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 will offer paid support through a one-time Operator Pass (coming soon!). That gives you direct contact with the team for help with deployment and day-to-day operations.
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 Postgres 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.

Lots of things have changed since! After Discord's age-verification announcement, Visionary sold out quickly: we sold around 1,000 copies at $299 each before pausing sales. Visionaries are recognised in-app with a numbered badge that shows how early they supported Fluxer.

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 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 Plutonium, 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. In Fluxer.app's production environment, these are deployed separately: HTTP API, Worker, Media Proxy, App, Queue, and Admin. Valkey is used for caching & rate limiting.

Fluxer.app's production instance uses Cassandra for persistence, while self-hosted instances use Postgres by default. Fluxer uses Meilisearch for full-text search, 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.
- More on this below!

If you're self-hosting Fluxer, there's a relatively lightweight Docker Compose file to get you started with everything you need.

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 Postgres 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 Postgres for self-hosted instances?

Yes. Since I already had an abstraction layer in place for Cassandra, adding centralised Postgres 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 Postgres support was simple: I could use a single key-value table and avoid relying on Postgres' relational features. In practice, I treat Postgres 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've gotten a lot of traction since Discord's age verification announcement on 9 February, and it's put me in touch with some experienced Flutter developers who'd like to help build Fluxer's mobile app as quickly as possible. I'll do what I can to support the work, but I'm not a mobile app developer by trade, so I'm really glad to have help from people who know this better than I do :)

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.

Edit: Huzzah! Thanks to your financial support, I was able to upgrade my workstation.

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 mostly built before LLMs became a normal part of development. I do use them now, in a limited way, and I want to be clear about what that looks like.

About 90% of my LLM usage is rubber-ducking. I'll feed a crash log or test failure into a conversation and talk through where to look next. The other 10% is mechanical implementation: I write a detailed spec covering the design, the edge cases, and how it fits into what already exists, and then use an LLM to produce a starting point that reuses the patterns and primitives already in the codebase. I review that output the same way I'd review an external contribution.

No LLM designed the system, wrote the specs, or made architectural decisions. I only use them on work I already understand well enough to catch mistakes in.

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.

If it were this easy to slop-code a Discord alternative this polished, we'd already be swimming in alternatives. AI isn't capable of producing anything near this yet. Some overestimate where the tech is actually at. Fluxer belongs to the category of software where you can't just conjure it with an LLM.

The CONTRIBUTING.md reflects how LLMs should be used in the Fluxer project:

You should understand every change in your PR well enough to explain and defend it during review. You don’t need to write an essay, but you should be able to give a brief summary of what the patch does and why it’s correct. You may not use AI to generate a bug report, pull request description, or GitHub comment in any form, except for a 1:1 translation if English isn't your native language.

The maintainer uses LLMs in a limited capacity. That’s how he was able to build the final version of Fluxer largely on his own over five years, with help from a supportive group of early testers. Without limited, controlled LLM use, he likely would have needed more starting capital to achieve the same result and hire a team of engineers.

If you use LLMs, use them responsibly. They can be helpful for rubber-ducking and for scaffolding boilerplate from thorough specifications, detailed guidance, and test coverage that verifies behaviour rather than implementation. This kind of platform cannot be built via autonomous code generation. Please disclose any LLM usage in your contribution.

We also ask contributors to treat each other with respect on this topic. People hold a wide range of views on LLMs, often rooted in ethical conviction. A contribution that is reviewable, understandable, and properly tested should be evaluated on its merits.

I also want to address the commit history, since it comes up. The OSS release started from a clean slate because the early work happened in private over 3+ years. I squashed the history rather than publishing 3,000+ messy commits. That's standard practice for a closed-to-open transition. It doesn't say anything about how the code was written, which is a common misconception.

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.

If you'd like to support this, contributors are very welcome. Once more than one person is working on it, there's less need for LLMs to be involved anyway, and up to now they've only been a way for me to extend my own abilities, nothing more.

That's one of the best parts of this being a FOSS project. If donations make it possible, I'd also consider offering bounties for specific work. My goal is to make Fluxer sustainable and largely 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 Plutonium 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 arrives, OAuth2 will be used to authenticate via your home instance when interacting with other instances, and no instance will store data from outside its own.

Even before true federation is available, you can combine all your accounts across multiple instances into a single view using an upcoming "relay" system. Relays multiplex your client connections over HTTP and WebSockets to Fluxer instance backends, with all traffic end-to-end encrypted. Fluxer Platform AB will provide official relays, but anyone can host their own. This system is entirely separate from federation, so if you want to use the hosted Fluxer.app instance alongside a couple of self-hosted ones, the relay system has your back without complicating the backend infrastructure or user experience.

Once federation does arrive, you'll no longer need to manage multiple identities at all, making things even simpler. But it's also fully optional. Instance operators will be able to choose whether to route traffic through their own servers to other instances, meaning you won't need to worry as much about scaling your instance or the implications of serving other instances' traffic. A network of decentralised, community-hosted relays can relieve the load and reduce central points of failure for staying connected to remote instances.

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 uses Shield by Project Arachnid to proactively detect known CSAM and other harmful or abusive imagery involving children in an even better way. 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.

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 instead of Cloudflare.

Cloudflare is used for one other thing: 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. 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, and if there's popular demand, Fluxer will offer the least bad options on the market for verifying your age very soon, fully opt-in.

To protect against spam, Cloudflare's Turnstile is offered as the default CAPTCHA provider since this provides the least amount of friction for most users, but you can switch to hCaptcha if Turnstile doesn't work for you.

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 (Visionary helped immensely!), 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.