hampus

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!

[1]: https://fluxer.app/blog/mobile-clients-and-fluxer-v2

[2]: https://docs.fluxer.app/operator/get-started/

[3]: https://github.com/fluxerapp/fluxer

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].

[1]: https://fluxer.app/help/regional-restrictions

[2]: https://canary.fluxer.app/download

[3]: https://web.canary.fluxer.app

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.

[1]: https://gist.github.com/hampuskraft/780c8fbcc4042689153533ef...

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.

[1]: https://gist.github.com/hampuskraft/780c8fbcc4042689153533ef...

This is happening to me too.

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.

[1]: https://gist.github.com/hampuskraft/7325ba2ad23a9445ebd93c64...

I downloaded it and decompressed it — it's approximately 2.1 terabytes in size.

Fastmail is based in Australia [1], not Germany.

[1]: https://www.fastmail.com/company/about/

Seeing as this is closely related to [1], which I also commented on, and in the hopes that someone finds this useful regarding Discord's ownership of your data (where your messages remain even if you delete your account):

If you'd like to delete your Discord messages en masse, I made an open-source tool for that [2]. It leverages a fairly undocumented process using your Discord data package, providing a UI to explore it and choose what to export. The tool gives you step-by-step instructions and a CSV file that Discord expects when you contact their privacy team. It works across all channels in both servers and DMs, even those you no longer have access to.

[1]: https://news.ycombinator.com/item?id=43276504

[2]: https://discorch.org

If you'd like to delete your Discord messages en masse, I made an open-source tool for that [1]. It leverages a fairly undocumented process using your Discord data package, providing a UI to explore it and choose what to export. The tool gives you step-by-step instructions and a CSV file that Discord expects when you contact their privacy team. It works across all channels in both servers and DMs, even those you no longer have access to.

[1]: https://discorch.org

According to Discord's public server list [1], Midjourney has over 21M members, making it the largest server. Discord published a technical blog post [2] detailing the infrastructure work needed to support Midjourney's unprecedented scale with 1M+ concurrent users.

[1] https://discord.com/servers [2] https://discord.com/blog/maxjourney-pushing-discords-limits-...

Currently, standalone Next.js apps using App Router consume a lot of memory and leak memory over time (issue #49929 has been open for over a month). I would greatly appreciate it if the Next.js team could investigate this matter (see my comment here: https://github.com/vercel/next.js/issues/49929#issuecomment-...). As it stands, this issue is preventing me from adopting App Router for new projects.