zlacker

Things to learn about the FediVerse from the 429 error:

* The FediVerse is lots of WWW sites. Some are WWW-hosting companies showing off, with all of the acoutrements of high-end WWW sites, including CloudFlare protection and lots of tweaking of the back end stuff. Others are one-person sites where someone has just set up the vanilla Mastodon/Pleroma/Pixelfed/Friendica/whatever software on a cheap hosted VM somewhere. There are lots of in-betweens. I have an account on two sites, at each of the aforementioned extremes, one with well over 20,000 users and the other with around 40.

* It's really easy to deny service to the one-person sites, and many of the low-end ones.

* Chaos.Social's about page explains that it's a couple of people running a WWW site in their spare time on spare hardware. That's a little misleading, as they've upgraded the hardware a bit. But it's still 2 people, with ~5800 users. For more, start at https://meta.chaos.social/resources .

* There's nothing global in the FediVerse. Nothing gets sent everywhere. Some commenters here can see the post cached by their local WWW sites where they have accounts. But I'm in the opposite situation: None of the places where I have accounts have cached that post, and since the Chaos.Social sysop put the 429 error in place to combat the server overloading, they actually cannot pull that post with just its URL entered directly, although simple tricks like searching for @jonty@Chaos.Social instead and reading the user timeline work just fine.

* There's nothing global in the FediVerse. Using the aforementioned trick, I see a different view of the thread from Mastodon.Scot to what I see from Toot.Wales, and both of those are different to what's seen from other places.

>>JdeBP+(OP)
So server software is not written with high performance in mind?

I've read somewhere that federation is done via regular HTTP requests which ends up really hogging down servers if someone has a lot of followers.

>>jespre+73
Mastodon is written in Ruby on Rails and there are some inherent performance issues with that, it generates a huge number of Sidekiq jobs that can bog down a server quite easily. There are other, non-Ruby implementations aiming for compatibility with the Mastodon API though, so I’m curious to see how it will all shake out.

>>JdeBP+(OP)
Just FYI, that 429 was explicitly placed on the specific URL HN links to. The remainder of chaos.social is up and running perfectly fine.

[Edit: already mentioned above, I just misread it.]

>>eqvino+N4
The aforementioned trick wouldn't work if it wasn't. But before the 429 error was put into place the entire site was affected across the board by Hacker News. See https://chaos.social/@ordnung/110312020977014678 .

>>JdeBP+B7
Ah, yes, sorry, I misunderstood your comment. My bad.

>>JdeBP+(OP)
Most of us are just browsing for interesting light reading anyway, so blocking us if they can’t serve a Hackernews worth of users seems basically… like an appropriate amount of robustness, for light reading.

Maybe the FediVerse is just not friendly to the idea of a “global top among thousands of users” rating.

>>afavou+l4
People can make a case for the developer productivity benefits of rails to a startup or business, but it’s hard to see it as worth the cost to the Mastodon community as a whole. But maybe it’s won the Fediverse market because of the depth of features which is a benefit of that productivity.

>>jeremy+9l
FWIW, there are some - maybe one or two - alternate implementations of Mastodon server brewing out there. Not of a generic ActivePub server, but specifically a server with an intention to be fully compatible with Mastodon.

So in the future, there may be more, hopefully more efficient choices.

>>JdeBP+(OP)
Thank you for the explanation, that actually makes sense. But I still think that serving a 429 is some kind of backwards old-school sysop kind of response. "It's the right HTTP-Code! hohoho!". It's obviously running nginx and serving a static copy of that url or setting up caching would take the same amount of time as serving the 429. It's 2023, it's possible to serve some thousand requests to static content on pretty much everything now.

>>jeremy+9l
My read is it's mostly social, there's a lot of people accustomed to Mastodon and not much interest in exploring other options. There are implementations in Elixir (Pleroma, Akkoma) and work being done in Rust (Calckey, currently node but moving towards a Rust implementation). Mastodon dev team are not particularly open to criticism so my general sense is that admins should choose another project.

>>mal-2+2s1
Yes, I’ve explored all this but I think Mastodon has won mainly because of its admin functionality, a huge fraction of dev effort is focused on tools to manage content moderation, spam policies and so on. Pleroma has a bad reputation because it was behind on that stuff at one time - maybe still - and a lot of instances had to be blocked because they couldn’t be managed effectively enough. I think it’s easy to underestimate how wide that moat is.

>>jeremy+8O1
That's fair, I've heard complaints that mastodon's moderation tools also leave something to be desired but it might still be the best. I haven't been an admin so I can't comment firsthand.

>>afavou+l4
While Rails doesn't help, it also isn't really the problem here. The problem is a mix of deployment instructions that are complex and doesn't emphasise the need for robust caching enough (this should be behind a properly configured Nginx cache, and the entire site also ought to be behind a CDN), combined with a Mastodon-specific architecture that as you say is really aggressively generating async jobs. Mastodon is really unnecessarily heavy to run.