Thanks! And you're right, the future federation work is what will make it possible to implement support for transferring communities across instances natively.
I'm the developer behind Fluxer – self-hosting is ready to use already [1][2][3], people are using it actively currently, and I'm currently working to make account switching across instances in the desktop app a reality. This, with a big voice update around the corner, will let us move much faster moving forward!
Funnily enough, I just happened to be looking through "new" on HN whilst some code was recompiling when I found this. So it was pure coincidence! I know most companies that expect to be discussed on HN have alerts set up for this kind of thing though, and I probably should too. It's made me realise I've likely missed plenty of other threads & comments about Fluxer just because I didn't happen to see them the moment they were posted :)
Fluxer's hosted service also needs to comply with laws around the world. However, we're clear that we'd rather exit a region than implement age verification. We don't have age verification. For example, to comply with the Online Safety Act, we block NSFW content for users on a UK IP address, rather than implementing invasive age verification. The same goes for Brazil. And we don't allow users in Mississippi to create an account at all. Those are the only limitations we currently have [1].
Discord, on the other hand, wants to implement global age verification, despite there being no legal requirement to do so in most jurisdictions. There's a difference between a social media app with ad revenue and a pure communications app. Because Discord focuses heavily on ad revenue, it might be treated as more of a social media app than a communications app under some legislation. Fluxer won't implement ads.
As another commenter has noted, I'm also doing the final push to release everything we've been working on privately, to make self-hosting officially supported and easy to do. Self-hosting is, and always will be, our focus. Our hosted service lets us act as an independent, European-owned alternative to mainstream services, handling the hard parts of platform moderation and operation that take time and money.
We strongly encourage self-hosting from 15 June, when that big update drops and all the code lands on GitHub. We had to keep those changes private while we improved our anti-abuse measures, as that was the only safe way to do it for now. That update also includes the first beta of the native Flutter-based mobile app for iOS and Android. On 8 June, we're landing many bug fixes, performance improvements, and voice and video changes (text-in-voice, end-to-end encryption in voice, screen sharing with audio, and much more) currently being tested on the Canary client [2] [3].
Zendesk conversations tend to follow a standard template that's easy to recognise. They also often mention Zendesk in the footer ("Delivered by Zendesk").
Either way, someone shared a much more minimal version [1] on my gist, which should be safe to use as long as you're not signing up for a Zendesk site. Most of the recent spam emails have been about Zendesk sign-ups specifically.
I just didn't want to keep maintaining this script if they find some other way to exploit Zendesk in the future, hence my nuclear approach.
If your email service supports Sieve scripts (for example, Fastmail or Proton Mail), you can use this filter [1] that I made. It's very aggressive and will block all emails that originate from Zendesk, so you'll need to disable it whenever you're actually expecting mail from Zendesk.
I suspect the recipient email address they're using (which I don't share widely) might have been exposed in one of Discord's recent support breaches, because I can't work out where else they could've got it from.
I'm using Proton Mail, so I set up a Sieve filter [1]. I'm doing this because this email address isn't used for anything even remotely related to Zendesk. I mostly use a separate custom domain address for everything.