It feels like you haven’t read my comment thoroughly.
To start, relays do not require large capital to run. This has been a misconception from the very beginning. I linked to this blog post, where a bluesky engineer runs a relay for ~$34 a month. If relays really had astronomical costs to run, I doubt Bluesky would run a whole separate one.
AppViews aren’t limited to one relay, most I know point to blacksky’s one as well.
technically, users can leave. Technically, you can self-host. Technically, you can run your own relay. The capability exists at every layer.
There’s no need to self host as there’s already public third party instances you can switch to. The alternatives already exist at each layer.
I do agree that too many users are on bluesky’s servers, but that’s not a fault of the protocol, and it’s not something the fediverse is immune to either.
They never have with any protocol. Not email, not RSS, not XMPP. The default wins. Always.
This is just incorrect. RSS is probably one of the least centralised protocols right now, it’s not even federated, which makes me question why the author even included it as an example.
If anything, this reads as an argument against federation, rather than an argument for the fediverse.
It costs $34 a month for an experiment. It doesn’t cost anywhere near that for a node that is running, used by thousands/millions of people, ingesting millions of pdses. Don’t be misled by a nice experiment. You need servers, backups, people to run that. See what real world deployment looks like: a little bit under 100k a year for the only independent full stack.
There’s no need to self host as there’s already public third party instances you can switch to.
Yes it’s possible. It’s just not the default. That’s the issue
it’s not something the fediverse is immune to either.
true, although no one said the contrary
This is just incorrect. RSS is probably one of the least centralised protocols right now, it’s not even federated, which makes me question why the author even included it as an example
The argument isn’t whether something exists, it’s what people use: rss is amazing but it’s far from being mainstream. The default path to following isn’t rss, which is the point (and the problem).
It’s not an argument against federation. It’s an argument to look beyond the niceness of a tech.
It feels like you haven’t read my comment thoroughly.
To start, relays do not require large capital to run. This has been a misconception from the very beginning. I linked to this blog post, where a bluesky engineer runs a relay for ~$34 a month. If relays really had astronomical costs to run, I doubt Bluesky would run a whole separate one.
AppViews aren’t limited to one relay, most I know point to blacksky’s one as well.
There’s no need to self host as there’s already public third party instances you can switch to. The alternatives already exist at each layer.
I do agree that too many users are on bluesky’s servers, but that’s not a fault of the protocol, and it’s not something the fediverse is immune to either.
This is just incorrect. RSS is probably one of the least centralised protocols right now, it’s not even federated, which makes me question why the author even included it as an example. If anything, this reads as an argument against federation, rather than an argument for the fediverse.
It costs $34 a month for an experiment. It doesn’t cost anywhere near that for a node that is running, used by thousands/millions of people, ingesting millions of pdses. Don’t be misled by a nice experiment. You need servers, backups, people to run that. See what real world deployment looks like: a little bit under 100k a year for the only independent full stack.
Yes it’s possible. It’s just not the default. That’s the issue
true, although no one said the contrary
The argument isn’t whether something exists, it’s what people use: rss is amazing but it’s far from being mainstream. The default path to following isn’t rss, which is the point (and the problem).
It’s not an argument against federation. It’s an argument to look beyond the niceness of a tech.