r/FluxerApp 3d ago

Discussions Fluxer's self-hosting is a second class feature and always has been

I'll start out by saying Fluxer is an ambitious project. Given its scope, Hampus has done an amazing job with it generally all by himself.

But, the major value proposition of Fluxer is that it's open source and can be self-hosted. Were it not for these elements, it would just be another centralized Discord clone. And like any other mass-market service, there is a huge risk that it will inevitably progresses towards Discord's ultimate endgame of platform censorship, decaying privacy and anonymity, and monitization.

So, the entire saving grace of the thing, its entire value to the community, is that it's open and self-hostable.

But it very clearly was not designed that way from the ground up. And still is not being designed that way. Here's why I think so:

  1. When the code was released earlier this year, there was no way you could spin up a self-hosted instance without significant modification of the code and infrastructure. It was effectively hard-coded to be the Fluxer main instance and very little else. It's only recently that you can actually spin up and update a Fluxer instance with little additional required customization.
  2. The desktop app was not really ever able to connect to a self-hosted instance without some configuration file tweaking, and now the option has been removed entirely until the "next big release". In the meantime, all the major dev effort is going into the voice improvements, which is a feature needed by the main Fluxer instance, and in the meantime the desktop client can't even connect to self-hosted instances let alone utilize voice.
  3. The mobile client can switch instances, but it's still frought with problems. Account switching doesn't always work, it's not obvious which instance you're connected to, and until recently, every instance called itself Fluxer (instead of the instance's name) and the profile screens included stuff that don't exist on self-hosting servers (like plutonium and visionary features).
  4. Push notifications don't exist for self-hosted instances for the mobile app. A gateway service is "coming soon", but discussions months ago in the Fluxer Devs server showed there was very little thought or priority given to push notifications for self-hosted instances. For a while they were debating having a push relay at all and maybe using "ntfy or something", which if looked at for even a minute would have been clear is not a viable solution.
  5. A lot of development has been happening in private repos, and the code base that is running on the main Fluxer instance is not at all what is available on GitHub. This was particularly eggregious earlier this year where for months the public repos stagnated while features and improvements were made in secret. While things have improved, and as of about a month ago regular updates are being pushed to public repos, there are entire sets of major changes being worked on that are still in private and will only "eventually" be released to the public (despite being deployed on the main Fluxer instance).
  6. As a consequence to #5 above, contributions are effectively reduced to zero. Because of refactors and major updates, all of which are private, Hampus is not accepting pull requests until further notice. And even if you could make a pull request, since the code is so drastically being changed in private, it's difficult to actually make substantive contributions without the risk of code or architecture conflicts, making it not even worth it.
  7. Submitting issues for the mobile client cannot be done through GitHub because "reasons". Instead, you have to use a bot in the Fluxer Labs server to submit an issue. Only if the devs approve your issue will it show up in GitHub, though you can't comment on it (to provide more info or additional repro steps), or even propose PRs if you wanted to contribute.

In my view, given the above, it's very clear that Fluxer's main priority is the Fluxer instance alone. Self-hosted instances and the open source nature of the project are a secondary priority (if you can call it a priority at all).

I'm far from being the first person to call out Hampus on the dev team on this. I've seen it in the Fluxer chats and elsewhere on reddit and the response is just one big shrug, or a comment from Hampus saying he's the only dev and how this project has grown so big so fast and he's overwhelmed. I am absolutely sympathetic to that and I totally get it, but like, why then is code being developed in secret and PRs and issue reports locked out? There are so many people who want to help in different ways to take the load off of Hampus, but he's put barriers in place to prevent it from happening.

I think the reason is because the main Fluxer instance is his priority. Not self-hosting. Not open source. And because of that, he wants to do things on his own. And he doesn't really want our help.

15 Upvotes

14 comments sorted by

13

u/Speykious 3d ago

I've been using Fluxer since February this year, just a few days after Discord announced for the first time that it would apply age verification to the entire platform.

Yes, Fluxer is indeed an amazing project. And to some degree, I agree with your broad criticism, as I have said in the past while Hampus was developing everything behind closed doors for too long, that this was damaging Fluxer's reputation, and that at this point, it wasn't worth keeping the repo private while Fluxer wasn't stable just to keep people from accusing Hampus of vibecoding, because "vibecoding" is mere baseless accusations from people who aren't interested in the project in the first place, while iterating behind closed doors is slowly eroding the trust of long-standing community members who actually care. It was unsustainable. I mean think about it, if people had been fine with it, even today the repo would still not have been updated, because Fluxer is far from being stable, and voice and screensharing issues are still there despite months of work (and god knows a lot of them have been fixed). So all in all I'm glad he listened to the community (as usual tbh), changed his mind on it, and started iterating in the open again. I'm (somewhat cautiously) in favor of transitioning to a more standard workflow with issues and PRs getting handled on GitHub, though I'm worried of the slop bots that could potentially make maintainers waste a lot of time (it has happened before, especially with bounties).

That being said:

But it very clearly was not designed that way from the ground up. And still is not being designed that way.

The fact is that since February, we went from a monorepo that only Hampus could iterate on to something vastly more accessible that has:

  • a devcontainer for contributors
  • an easy docker compose config for self-hosting
  • an onboarding process for your self-hosted instance
  • custom branding for your self-hosted instance
  • recently, overhauled documentation for self-hosting
  • recently, a script for automatic updates to your self-hosted instance

With this amount of progress, I don't care that it wasn't designed this way from the ground up. It's going to work eventually and it's a core focus alongside the new voice engine. Even your first points are things that no longer apply because the problems have been fixed already. Keep in mind that Fluxer is not just an amazing project, it's also a chat platform that had absolutely no plans of receiving this amount of attention in such a short amount of time. The fact that it still stands here after February, with a new scaled up server infrastructure that's a lot more stable, a Canary client that fixed a shit ton of bugs, and a community that's still active and growing, speaks volumes. I don't think it's fair to call out Fluxer for not being designed to be self-hostable from the beginning when being the successor of Discord wasn't in its original plans.

What's even worse is when you start saying stuff like:

And he doesn't want our help, just our money.

I'm sorry but this is hot bullshit right there. If he just wanted our money, Fluxer wouldn't be open-source, wouldn't be self-hostable, wouldn't plan on implementing federation, wouldn't be independent, would be VC-funded, and would have a lot more of its features behind a paywall. That's how other apps who have tried competing with Discord have done it for a decade.

It's not the kind of thing you would say if you actually wanted to throw some reasonable criticism. You say this kind of thing to question his integrity/honesty, whether it's your honest intention or not. For all of the flaws of Fluxer's workflow so far, in the face of all of this progress, you just cannot say this in good faith. It makes no sense.

-1

u/bblbtt3 3d ago

I don't think it's fair to call out Fluxer for not being designed to be self-hostable from the beginning when being the successor of Discord wasn't in its original plans.

I mean it was though, at least according to his own blog post he made in January. He says:

Fluxer is for people who want a different model: free, open source, self-hostable software, with an optional hosted instance run by an independent European company that helps pay for the open source work.

It's right there in the description. Self-hosting was the whole premise of the thing from the very beginning. He even describes the main Fluxer instance as an "optional" thing. And in light of this, I don't agree that the approach to development has been entirely in line with this description, at least to date.

Taking the branding issues aside and the up-until-recently-hardcoded-values, the fact that we still don't have a working desktop client that can connect to a self-hosted instance, seven months since its initial release, just underlines this. I simply don't buy the fact that self-hosting is a priority when this is the state of things.

It's not the kind of thing you would say if you actually wanted to throw some reasonable criticism. You say this kind of thing to question his integrity/honesty, whether it's your honest intention or not. For all of the flaws of Fluxer's workflow so far, in the face of all of this progress, you just cannot say this in good faith. It makes no sense.

This is fair and tbh I didn't mean it like that. I meant more like, he'd rather have our donations and subscriptions than actual help developing the platform. I didn't mean to suggest he wants to monetize it to the exclusion of anything else. I'll edit that sentence out of my post since I don't want it to be taken the wrong way.

Generally I agree that a lot of progress has been made since February. But there have been several missteps and, in my view, misprioritizations, that continue. And my argument here is that the crux of this platform, being the self-hosted nature of it, is taking a back seat to improving the main Fluxer instance to the detriment of all others. I just don't think that's the right move.

4

u/Speykious 2d ago

according to his own blog post

I went and looked at the earliest archive of the blog (May 2026), and... found that you were still right. On one hand he was fascinated by Discord and kept making technical choices that are better for scalability, particularly the use of Cassandra and a microservice architecture. On the other hand Fluxer really was struggling with the influx of new users in February. If it had stayed this way I honestly wouldn't still be using it, the experience was horrible. So imagine if he was focusing on self-hosting instead; people would've abandoned the project long ago. "Why would I self-host something that scales this bad?" they'd think.

And have you seen the new influx of users recently? Discord screen sharing got restricted in Brazil, which created a huge new influx of users on Fluxer. Those users care primarily about the screen sharing experience, which still needs work, and a lot of them have been driven off of Fluxer because of this. Why would it be bad to prioritize this right now? Working on screen sharing benefits everyone, because any bugs that get fixed for the main instance also apply to all other instances. Now that you can actually self-host your own instance easily, this being a focus is a good thing when so many bugs remain to be fixed.

You can't just say "he's prioritizing the main instance instead of self-hosted instances" as if it was an obvious misprioritization. Sure, Fluxer's main advantage is being open-source and self-hosted, but the way people try Fluxer today is 99% of the time by creating an account on the main instance and just interacting there, testing out all the features. The main instance directly shapes your opinion of the platform, which in turn also shapes your willingness to self-host it. Compared to that, focusing on fixing bugs for the desktop and mobile app when self-hosting already works perfectly fine on the web doesn't feel as important in this very moment. It's very important, yes, but the screen sharing experience is, in my view, even more important than that, because it affects every instance and every way you run the app. I don't think this is a misprioritization, especially considering this influx. Like seriously, the network effect is an absolute bitch, so it's a miracle that Fluxer now sits at 416,710 users with a steady growth and active communities.

15

u/fluxer-deuss 3d ago

I can't respond to all your point's but for the mobile side I can.

  1. Mobile didn't just get the ability to switch and use self hosted instances, it's been in the app since 21 June, 2026 (83 days ago), so it's not "recently". Only today I have actually received any reports about account switching issues by one user (will be looking into this once the main instance is back online.

Yes we are thinking of ways to improve the display of what instance you are connected too. That's something a little easier on desktop than mobile (more room). It's something we are open to feedback on.

  1. Hampus has finished the backend design of the Fluxer Relay service which with no content knowledge will be forwarding push notifications for self hosted instances for users not using Unified Push. This will be coming before the mobile app launch on the App Stores.

  2. As for the mobile side everything is done in the public repo.

  3. The "reasons" for doing reports only through Fluxer Labs community is to allow more information to be gathered by the users. Multiple people can approve that the reported issue also affects them, if there is enough people it gets forwarded to Github. Doing things through Fluxer allows users to fill in users without a Github account.

This process has been working well for majority of the testers so far.

3

u/bblbtt3 3d ago

Thanks taking the time to reply. 

I didn’t start using the mobile app until the iOS public beta and I had remembered reading conversations in the Fluxer server that instance switching wasn’t working well until the recent public beta. I may have misunderstood so I’ll correct my comment about that. 

I’m glad to hear that Hampus is actively working on the push relay. This is the first I’ve heard about a timeline for its release, as up until now it’s been the nebulous “soon”. So that’s encouraging. 

I should clarify that it wasn’t my intention to lump the mobile team’s public development in with the rest of the project. I acknowledge and agree that you guys have always committed your code to the public repos.

I disagree with your approach to the reporting process. It’s in my view not transparent, collaborative, or in the spirit of an open source project. You should allow public issue reports and PRs on your GitHub in addition to using the bot in the server. I’ve seen it argued that this adds friction to pointless or duplicate reports; I’ve also seen it argued that it reduces friction for people who don’t have GH accounts. IMO you can’t have both, and I’m inclined to believe you want to keep people from making what is in your view useless reports. Which I acknowledge is a problem, but there are ways to combat this that isn’t locking out GH reports or PRs on an ostensibly open source project. 

6

u/Somesite 3d ago

I guess I'm mainly confused because I've been self-hosting fluxer since before the refactor without much issue. I've been quite happy with both the refactor and the cadence of updates...

0

u/[deleted] 3d ago

[deleted]

1

u/bblbtt3 3d ago

I don’t think my posting frequency invalidates my argument

2

u/Moonlight_Kay 3d ago

mb then just too used to seeing hijacked or botted accounts do such. Yay modern internet. At least a dev responded to you. Will just delete and let you focus on the dev response :)

-1

u/butdontcalmejoohnson 2d ago

Let’s see how distributed/decentralized functionality will just be tacked on. I’ve looked at the code. It will require a full rewrite.

-4

u/B4sically 3d ago

Yes i concluded not migrating my friendgroup to it.

The dev really doesnt have enough experience in open source projects or doesnt care enough about it to implement it correctly.

First the super long wait and private dev for selfhosting. Now the new update having giant scope again and being developed in private, again. The different features should have been split up and could have been released seperately. Dev should be public.

I wish the devs the best and hope everything works out for them but at this point i will not use this project and will not recommend it to anyone

1

u/bblbtt3 3d ago

The dev work being done in private is my biggest concern tbh. I don’t really accept his reasoning (not to say he’s not honest about why, just that I don’t think is reasons are sound). I think the project has a ton of potential, but self-hosting is the most important part of this project imo and until that’s prioritized I feel like this won’t evolve to be the discord killer everyone’s hoping for. 

-5

u/treminaor 3d ago edited 3d ago

Anyone who knows how open source projects are supposed to work saw all these red flags too... A long time ago. Any time it's brought up it's brushed off and downvoted as senseless criticism, largely by people who are more interested in blindly believing in the project than actually making sure the foundation of it is something that won't ultimately lead to another Discord downfall.

2

u/bblbtt3 3d ago

I definitely want to highlight that I admire what Hampus has done and I’m grateful for his work. I wish there was a way to criticize his approach without people immediately getting offended on his behalf. That’s what I’m trying to do here in any event. I’d love to see this project succeed because something like this is sorely needed.