Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I mean, yes self hosting a Linux computer in the cloud requires certain skills and time. This is the basis of the business model for the biggest companies on the internet - we will run a service for you so you don’t have to run your own server. This is true even for hosting a basic HTML web page - a whole lot of people do not want to operate their own server, and this in no way means the service is bad.


Wrong! Hosting Mastodon is a different type of challenge, not to mention how much wasteful it is due to the poor choice of Ruby! Yes, Oracle Labs are trying Truffle, but it's not officially supported yet.


If I may suggest, I recommend reading up on the concept of comparative advantage. Economics suggests that an org that spends more on self serving Mastodon or any service outside their core offering costs should be willing to offload that to a specialized service if the service offering is lower.


I know no commercial organization running their own Mastodon - all instances I know are some non-commercial communities who are just too attached to their favorite domain. As communities run by volunteers, the cost is more important than the volunteer effort.


It may not quite count as commercial, but the EU as an entity has their own instance. European Commission and others are on it.

https://social.network.europa.eu/about


Are we now giving bureaucrats as a positive example? I see so many people running closed servers with just a couple of accounts of it, which is another failure of Mastodon - not easily allowing people to use their own domains as identities instead of having to run a whole new server, which is a total waste, and not helping the ecosystem!


> I know no commercial organization running their own Mastodon

Key to remember is yet. The internet started as DARPAnet, after all.


You’ve got an extra D, it was ARPANET.


Serves me right typing on a phone without my glasses.


What does the choice of programming language for a reference implementation have to do with the cost/benefit analysis of the protocol it implements?


Oh, it's now a reference implementation... since when?! Do those people who climb on the Mastodon bandwagon know this is just a POC turned into a Product, which now competes with Twitter?!

The language makes a huge difference as you need to deploy the whole Ruby toolchain, and front it with all the hard choices Rubyists had to deal with for ages to make it kinda work! You don't make a distributed competitor of Twitter following its own wrong design chocies!

Mastodon is old, and it's a shaky foundation, and it should be rebuilt from scratch instead of disappointing the millions of people who suddenly like Dorsey more than Musk... although Dorsey is working on Bluesky, not Mastodon, or ActivityPub!


> Oh, it's now a reference implementation... since when?! Do those people who climb on the Mastodon bandwagon know this is just a POC turned into a Product, which now competes with Twitter?!

Might I suggest you take a deep breath and tell yourself ‘it’s ok, I don’t need to pick fights with random people over trivial things’?

> The language makes a huge difference

If a decentralized social network is a good thing (jury is out imho), guess it’s a good thing that there’s ActivityPub implementations in multiple wildly different languages then?


> Oh, it's now a reference implementation... since when?!

For any software that embodies an open and formally-specified protocol (in this case, the protocol is ActivityPub), any first implementation of it is a reference implementation (as opposed to a defining implementation), because at any point someone else can create another implementation, and then both implementations will have to deal with adhering to the standard, rather than either being able to bully the other into implementing things a certain way. It's not about whether anyone else has implemented a second client for the standard; it's just about whether they can, and what would happen if they did.

Examples of things that are reference implementations of open protocols/formats, where the protocol/format "came from" the reference implementation but then became its own thing, with other implementations: Memcached, Redis, IPFS; PNG, OpenDocument.

Example of something that's not a "reference implementation of an open protocol", despite seeming like it: Amazon S3. There are many other "S3-compatible" servers; but there's no open, formalized standard for what "S3 compatibility" means; and so Amazon can change S3's API at any time, and everyone else will just have to deal with that. (They won't — it's been the same stable API forever — but they could. And what they can do is the point here.)


What's your beef? Seriously.


Seriously? We used to have comptuters with just 48KB RAM and created great software for it. Now, we have mobile apps like Facebook, which is over 2GB in size, and they are just a gigafat client of a server app!!! Mastodon is just like that - slow, wasteful, not scalable! And what's the worst is that people are getting hopeful about it not remembering how Ruby tanked Twitter back then! Doesn't anyone remember the Fail Whale?!


You need to calm down


Actually, I'm pretty calm - I can't say the same about the super excited users of Mastodon in the near future though! And, honestly, all this "movement" or "exodus" being based on Elon Musk taking over, really?! How was Twitter any better before him?! The blatant censorship actually made many people flee Twitter long before ELon Musk and it was heavily infested with bots since day 1 and I find no utility in it. Twitter is an acute form of masochism trying to follow a "conversation" on it. I do have Twitter Blue and I've been a paying subscribero of Threadreader before, but they don't help.

ANyway, just try to imagine the same spammy bots taking down all Mastodon servers when the super eager to leave Twitter move to the next cool thing... It won't be pretty! The Fail Whale will feel like a joke compared to what's about to come.


Characterizing Twitter moderation as "blatant censorship" does not, to my mind, indicate that you are a serious conversant here.

> How was Twitter any better before him?!

Before Musk took over it wasn't saddled with the $13B in debt he took on to buy it. Before Musk took over advertisers weren't fleeing the platform in droves. Before Musk took over no one could impersonate Eli Lilly with a blue checkmark and cause its stock to crash. There's no indication now that Twitter will do anything to stop hate campaigns and abuse when they arise (hate speech is free speech, after all, and isn't illegal in the US). I could imagine some kind of future for Twitter before Musk, but that's immensely more difficult now.

I don't think Mastodon is the solution, mind you. But it's no surprise to me that a lot of folks are looking for an alternative.


For real.


Having actually looked at and run Mastodon, of the problems Mastodon have, and there are quite a few, the choice of Ruby is far down the list, and your focus on it suggests you haven't spent any time looking at where the complexity is.


Why is there no Ruby web framework in the most iconic benchmark [0]?

[0]: https://www.techempower.com/benchmarks/#


You're moving goalposts. Gone from "complexity" to performance. Ironically I'd have been more willing to agree with you that the complexity of Mastodon is a challenge.

But presumably because very few people cares about that benchmark and what is supported depends on what they choose to add. You're the first person I've ever seen mention it.

For a simple reason: Performance on dynamic requests is a choke point only for a miniscule proportion of sites, and the federation that is a selling point for Mastodon ensures that any single Mastodon instance is far less likely to ever approach a size where that becomes an issue. There are certainly sites where I wouldn't run Ruby, even though it's a language I love to use.

But I'll repeat myself: The choice of Ruby is far down the list of issues with Mastodon.

Returning to the benchmark, it's also contrived to reference as a general measure for a web app. Anyone building actual systems using Ruby puts Ruby behind a reverse proxy exactly because we're fully aware you focus on avoiding hitting the Ruby app server for anything static or cacheable, and so the setups on that benchmark (there are at least four frameworks and a couple of dozen entries) are entirely atypical for Ruby app server setups (they all hit the web server hosting the Ruby app directly).

That's fine - they measure what they measure, but they don't measure a realistic web app setup with any relevance to Mastodon.

E.g. the vast majority of traffic for a Mastodon instance is read-only requests to toots and media that are trivially statically cached, and so the vast majority of hits to a Mastodon server set up to actually scale should never hit the app server at all.

I have a deep distaste for Rails, and think Mastodon is more complex than it needs to, and there's plenty to criticise Mastodon for, but you're barking up the wrong tree.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: