My vengeance for these transgressions will be enacted patiently, and I assure you will be fully encompassing. A frog never forge- is that a hamster wheel? Aw fuck yeah dude… Holy shit this slaps

I loved it! 😄

Scraping the moss with the hori-hori knives is lowkey relaxing though, ngl.

We’ve also built up a bit of a rapport with Gary the Satyr (we’re on a first name basis now), and the little dude will jam out some Checkfield on his flute upon request (the forest weed he offered us really enhanced the experience, too).

First time was a little awkward, but by the third time, it’s honestly a chill time, and a good excuse to get some nighttime hiking in. We don’t even notice Gary’s fully erect schlong anymore :)

Bummed that you can’t seem to catch a break with the server suffering from separation anxiety and throwing a fit every time you leave for work.

Artist’s rendering. (had to use catbox since lemmy.cafe doesn’t seem to allow image uploads?)

Base image courtesy of @undthr@horp.sciops.net

Unfortunately that is the case. The creator mentioned during the release they had used AI sparingly, but it’s clear from their commit history that it is pure slop at this point.

Like Lemmy a few years ago, there is not yet a large community on Movim. I’m hoping that an exodus of Discord users who give Movim a try will bring with it more activity, just as the reddit API exodus did with Lemmy a couple years back. The first adopters may need to rely on just using it to communicate with friends for a bit as they either wait for others to build communities, or build some themselves, which is what made Lemmy as healthy and vibrant as it is today :)

Matrix because it seems like the most logical choice - largest platform that’s federated/decentralised and has end-to-end encryption.

Personally I’ve had consistent problems with messages not un-encrypting in Matrix, requiring frequent re-sending of messages. I’m also not a fan of how much Metadata is shared across the Matrix network even with encryption, nor am I fan of the history of the group (Amdocs) who developed and funded it, or the willingness of the Matrix/Element team to sell their services to law enforcement (They had purchased a booth at a police convention).

Movim has all of the same features as Matrix without those downsides, if you’d like to give that a try instead.

It’s a promising project for sure, though it will have to prove that it can scale up without bogging down.

As an alternative, there’s also Movim, which uses a more mature back-end. If you’d like, you could try that out with a friend to see if it can handle your needs. It offers both group video calls and screen-sharing (must use a chromium based browser to screen-share with audio for now), and it’s already federated and offers optional encryption based on Signal’s style of encryption.

The second link in the body of OP is the dev explaining that he’d been working on it in his spare time for 5 years before releasing it as a public beta on Github.

He does mention using AI in a limited capacity.

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.

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.

**EDIT: **Just a heads up to anyone interested in Fluxer: I was just informed today of a huge red flag for Fluxer; it has a contributor CLA that could allow it to change to a non-FLOSS license in the future. I was hopeful for it previously, but that kills it for me.

Of all the discord clones, this one does look promising I must admit, especially since the dev has mentioned they’d be open to incorporating federation and some encryption abilities down the road. The GPL license is a good mark, and the dev seems pretty chill. Downside is that’s it’s still very rough and in more of a polished alpha state. The dev mentioned they’re about to release a major refactor of the codebase, which they hope will fix the sluggishness the server is experiencing after an influx of new users from the Discord dumpster fire.

Personally, I’d still suggest Movim over Fluxer at the moment.

Movim already has a proven, scalable back-end (XMPP), it’s already federated, already provides good encryption, has 90% feature parity with Discord such as Chats, group video calls, screen-sharing with audio (requires chromium browser to share audio for now), its made in the EU, and it’s ready right now, not some time in the future (if Discord users fleeing discord try Fluxer, they’d be likely to bail on it due to the current bugs and just go back to discord). The Movim developer is also currently working on adding in discord-like channels and rooms.

But that’s just my 2 cents. Fluxer is one to keep an eye on for the future, though.