The appview needs to index the relay contents to build a view of the whole network, the relay is just a type of CDN, and is NOT that expensive. There are multiple individuals maintaining full copies right now, while the network is at double digit millions of users. The relay is by far less expensive.
You’re looking at poorly matched cloud options in that article. The individuals doing it does it easily on a NAS and equivalent. The cost from running public relays will come from traffic, not storage
It’s the appview that needs to be made lighter, and that work is progressing. Like building variants you can self host which are selective and only care about content from your network (and only fetching other content as needed)
The appview needs to index the relay contents to build a view of the whole network, the relay is just a type of CDN, and is NOT that expensive. There are multiple individuals maintaining full copies right now, while the network is at double digit millions of users. The relay is by far less expensive.
Great, but how much do these people pay to maintain a relay of the entire network? I bet a lot more than for a fediverse server that only has to maintain a small fraction of the whole network.
There is another problem: these other relays are all copies of the Bluesky relay, where the official app publishes the messages of its users, so they are not independent from each other; if I publish my posts on a relay other than Bluesky’s I will not be able to communicate with them.
Fediverse servers can quickly get more expensive if you have a few thousand users, or even a few dozen but somebody has a post go viral. That’s because every retrieval of a post always goes to the original user’s server, every like does too, etc, and this generates a flood of events which quickly gets expensive to process.
Just ask the maintainers of the botsin.space Mastodon server who couldn’t afford to keep it running, and now put the server in archival mode and not allowing new posts.
A PDS only publishes static data and don’t have to process incoming events, making it very easy to run one behind a caching server very cheaply.
There is another problem: these other relays are all copies of the Bluesky relay, where the official app publishes the messages of its users, so they are not independent from each other; if I publish my posts on a relay other than Bluesky’s I will not be able to communicate with them.
Not entirely correct.
Every individual users’ account host (PDS) publishes directly locally, the relay then collects published posts from known PDS servers (including both bluesky’s own and others’ self hosted servers) and display everything. A PDS server can sync to multiple relays. Relays can even sync to each other, which is practical because PDS servers publish through content addressing for posts in user repositories so it’s easy to verify completeness.
So sure if somebody uses an app connected to a filtering / partial / out of sync relay they might not see everything. This is not an architectural limit in the protocol, however.
The relay is very expensive, it collects and receives messages from the whole network.
The appview it’s not the problem, that’s just an user of the relay.
See this article
The appview needs to index the relay contents to build a view of the whole network, the relay is just a type of CDN, and is NOT that expensive. There are multiple individuals maintaining full copies right now, while the network is at double digit millions of users. The relay is by far less expensive.
You’re looking at poorly matched cloud options in that article. The individuals doing it does it easily on a NAS and equivalent. The cost from running public relays will come from traffic, not storage
It’s the appview that needs to be made lighter, and that work is progressing. Like building variants you can self host which are selective and only care about content from your network (and only fetching other content as needed)
Great, but how much do these people pay to maintain a relay of the entire network? I bet a lot more than for a fediverse server that only has to maintain a small fraction of the whole network.
There is another problem: these other relays are all copies of the Bluesky relay, where the official app publishes the messages of its users, so they are not independent from each other; if I publish my posts on a relay other than Bluesky’s I will not be able to communicate with them.
Fediverse servers can quickly get more expensive if you have a few thousand users, or even a few dozen but somebody has a post go viral. That’s because every retrieval of a post always goes to the original user’s server, every like does too, etc, and this generates a flood of events which quickly gets expensive to process.
Just ask the maintainers of the botsin.space Mastodon server who couldn’t afford to keep it running, and now put the server in archival mode and not allowing new posts.
A PDS only publishes static data and don’t have to process incoming events, making it very easy to run one behind a caching server very cheaply.
Not entirely correct.
Every individual users’ account host (PDS) publishes directly locally, the relay then collects published posts from known PDS servers (including both bluesky’s own and others’ self hosted servers) and display everything. A PDS server can sync to multiple relays. Relays can even sync to each other, which is practical because PDS servers publish through content addressing for posts in user repositories so it’s easy to verify completeness.
So sure if somebody uses an app connected to a filtering / partial / out of sync relay they might not see everything. This is not an architectural limit in the protocol, however.