@Revertron @kzimmermann IMHO This is why large instances shouldn't be a thing anywhere on the #fediverse .
The sustainable and maintainable approach is smaller instances, and more of them. Individual creators should try to either join small instances or host their own like a website.
@lps the problem is that smaller instances and more of them consume exponentially more resources, making the whole system exponentially more expensive to operate.
That's just how the protocol was designed, unfortunately.
People complain about Bitcoin being resource-intensive, but Fediverse faces a similar problem.
🏴☠️ ✂️
@volkris @lps @Revertron @kzimmermann
yeah, perhaps if you completely ignore the p2p and p2n baked into PeerTube. anyone who has used decentralized media distribution IRL can see through this obvious FUD.
Centralization is only better at gatekeeping, user tracking, and ddos vulnerability.
@errhead I'm referring to the design of ActivityPub at the core of Fediverse.
If you're talking about something else that's fine, but it's not what I'm referring to.
@volkris @lps @errhead @Revertron @kzimmermann What you're saying is not true. Smaller instances don't consume "exponentially more resources". ActivityPub is very easy on resources and servers can run almost anywhere (unless you use some really inefficient bloatware)
@silverpill if you read through the ActivityPub standard, the protocol is designed to scale with number of instances, and it is a scaling factor larger than simply linear.
You say AP is very easy on resources, but that flies in the face of so many instance operators experiencing meltdowns and surprise hosting costs when the resources exploded far higher than they expected.
Which makes sense because, again, the protocol is designed in a way that involves exponential increases.
@volkris @silverpill @lps @Revertron @kzimmermann
You're conflating the horrible federation model of Mastodon with all of ActivityPub
