Fluxer
Open-source Discord-like instant messaging & VoIP platform
153 followers
Open-source Discord-like instant messaging & VoIP platform
153 followers
An open-source, independent instant messaging and VoIP platform. Built for friends, groups, and communities.
Fluxer
Raycast
@hampuskraft wow, AGPLv3 is a choice! What's your thinking/strategy behind that?
Fluxer
Hey @chrismessina, thanks for your comment! Indeed, I'm going for a strong copyleft license, following the lead of projects like Mastodon, Signal, Forgejo, Nextcloud, Grafana, and Element. This is to prevent proprietary forks that reduce the freedoms I believe users of the software should have (no matter who is hosting it) including access to the source code, and to reduce the risk of vendor lock-in.
Fluxer's monetisation strategy is partly a hosted freemium instance, which I'd like to protect from better-funded competitors who might copy the product and run a larger hosted version, keeping their changes closed instead of contributing them back. You're allowed to make money from running a Fluxer instance, but your modifications would need to be disclosed under the AGPLv3.
However, I'm open to doing what many AGPL-licensed projects end up doing: dual-licensing the codebase, allowing companies to pay for an enterprise license so they're no longer bound by the AGPLv3 if they want to make private modifications instead of upstreaming them. This protects Fluxer's hosted freemium instance and means large companies that want to privately modify the product for internal use over a network can still do so, if they pay for that privilege.
My stance is that Fluxer stays fully open, and anyone running a modified Fluxer instance over a network should provide the corresponding source, preferably by upstreaming changes where it makes sense, except for companies that pay for a separate license. But the base software is always the same. I won't add arbitrary self-hosting restrictions that require paying or patching out to remove (like limiting the number of messages) and I also won't have an SSO tax.
So, in summary, it's a philosophical choice: I want to respect user freedoms and ensure that no other commercial entity can violate those freedoms using Fluxer's software, protecting the hard work that I and other contributors have put into the project, as well as protecting my hosted instance where paid users help fund continued development.
Raycast
@hampuskraft that's awesome, and I appreciate your approach. It's relatively rare these days.
What's your take on 37Signals's O'Saasy License?
Fluxer
@chrismessina First time I'm hearing about O'Saasy! My take is that O'Saasy is a compelling source-available option if your main goal is to have auditable production code while remaining the sole SaaS vendor. It reminds me of the Functional Source License (FSL), except that FSL has delayed open-sourcing, whereas O'Saasy is effectively MIT once the original licensor is no longer in business.
If Fluxer were purely a SaaS business, I'd very much consider O'Saasy (or something similar). But I don't actually want to prohibit commercialisation of Fluxer; I want to protect user freedoms first, and I also want to be able to truthfully call Fluxer "open source" under the OSI definition. Once you restrict commercial use or a field of endeavor, you're source-available instead, and that's a meaningful trust and marketing difference for the audience I'm trying to reach.
That's why I prefer AGPLv3. It preserves the freedom to run Fluxer as a service while requiring that network-deployed modifications remain available, which reduces the incentive for proprietary forks that do not contribute back. The brand I want is "fully FOSS, no self-hosting gotchas" so that technical users are more likely to contribute both code and funding (donations and support plans), while I still retain the option to offer custom commercial licenses to companies that are willing to pay to avoid AGPL obligations, without ever compromising the base software.
More broadly, I'm targeting the user segment that is actually willing to switch when a credible alternative appears. A big part of the gap in this space is usability and feature parity with state-of-the-art platforms like Discord, and that's what I'm trying to deliver while focusing on self-hosting and decentralisation to cater to a technical audience (linked a HN thread to show the sentiment of that group of users) who values this and are frustrated with the existing options.
My thinking is that the best way for me to find a foothold is to prioritise the things that my competition does not prioritise, in order to win over all the frustrated users I know exist out there, and with a focus on gaining the trust of technical folks initially, the product might be able to flourish with an active contributor base, to help the project to reach its fullest potential without needing a lot of capital to do so. It's quite rare to take this approach indeed!
NativeBridge
@hampuskraft Explored this briefly and it’s refreshing to see such a focused approach. Congrats to the team!
Congratulations on the launch! How about security? Encryption?
Fluxer
@mykyta_semenov_ Thanks!
Fluxer is not end-to-end encrypted today. Some existing options, like Matrix, are both end-to-end encrypted and federated, but still fail to deliver the UX that people expect coming from platforms like Discord. Instead of starting out with complex features such as E2EE and federation, I decided to focus on what other OSS or OSS-adjacent options are criticised for lacking in terms of usability today, offering what I believe to be one of the closest public attempts at feature parity with modern chat apps such as Discord.
There's also a lot more coming, including features that make Fluxer unique. One example is publishing forum channels to the web to solve the content discoverability problem Discord/Slack has, where tech communities, for example, often use these platforms as replacements for an open web forum, making it more difficult to find content, which also could disappear anytime. I think there's room for innovation here: the familiar, easy-to-use UX of Discord (that no OSS alternative has really nailed) combined with ways to publish content to the open web, with Atom/RSS feeds, indexable pages, archives, and access without requiring a login.
So while I do care about E2EE, my priority right now is delivering the UX people expect, and hopefully an endeavor people are willing to pay to support financially, since not many are taking on this challenge. Getting Discord-level UX with E2EE everywhere adds a lot of complexity to an already very complex piece of software: I'd have to solve scalability for large groups, message history, lack of server-side search, account recovery, and deal with a generally slower UX. Some features may not even be feasible in a community chat app if everything is end-to-end encrypted. When Fluxer adds E2EE, it'll likely start with ephemeral private DMs with friends.
Designing the entire app around E2EE (or building in decentralisation via federation from day one) introduces whole categories of issues in terms of scalability, moderation, and UX, that I'd otherwise avoid. These problems would distract me from implementing features people want and it's part of why platforms like Matrix have ended up with a lot of frustrated users. That said, the fact that you can already self-host a Fluxer instance and control your data is an important first step toward private communications. The next step would be federation, its own massive technical challenge, so you can use one set of credentials across trusted instances and avoid having to context-switch via the in-app account switcher.
So yes: I definitely care about end-to-end encryption! But given the technical challenges for this type of product, and how much it can distract from the core mission, it has not been the priority so far. Being a one-person team has forced some tradeoffs, and I've had to draw the line in a few places just to keep the scope manageable. Still, I'm not opposed to implementing E2EE if there's enough demand, and especially if users want it enough to help finance its development :)
Oasi
Cool up, what makes it different from Discord except that is Open source?
Fluxer
@mrrabbar The main thing open source community chat platforms lack today is basic feature parity with products like Discord. Until that baseline exists, people who care about privacy, data ownership, and free and open source software still end up on Discord or Slack. That is where everyone already is, and it has the features you expect from a community chat app, working reliably. Most alternatives suffer from poor usability, questionable licensing, missing features people assume will be there, or a self-hosting story that is too resource-heavy and complex.
There is already clear interest from this crowd. Early supporters have paid $299 each through the Visionary offering because Fluxer already feels polished and complete, and they want to back my mission to get it over the line: a fully decentralised, feature-complete alternative to the soon-to-be-IPO'd Discord. A place where you can host your own data and move between instances. That is the niche I'm targeting first, because these users are more willing to switch when a credible option appears. There's also constant noise on Hacker News about the lack of one.
My next move is a major refactor focused on self-hostability, alongside proper documentation. After that, I'll post to r/selfhosted and publish the full story and technical details as a blog post and on Hacker News.
That said, Fluxer already differentiates itself from Discord in a few ways:
You can join voice from multiple devices at the same time, instead of having to disconnect one to use another.
You can fully customise client-side CSS.
You can save media so you can quickly find and resend any GIF, image, video, or audio clip you've enjoyed before, across all your devices (not just GIFs).
You get personal notes for when you just want somewhere to jot down thoughts.
Still, feature parity comes first. Nobody will pay unless there's a believable path to the baseline set of features they expect, and no other alternative really delivers that today. That's exactly why I'm already getting compliments and payments from new users who don't know me. They can see the promise in Fluxer precisely because the baseline is already strong. In that sense, adding too many differentiators too early wouldn't necessarily be a good thing. The baseline itself is what is likely to drive me the most adoption from a technical audience, which is my initial focus.