OmnipresentWalrus

joined 5 days ago
[–] OmnipresentWalrus@feddit.uk 1 points 3 hours ago

ActivityPub based platforms (Mastodon, Pixelfed) are monolithic services. You have to run the entire instance (account hosting, feed generation, moderation etc.) all in one place on one machine.

While you can do work with loads balancing to manage high traffic moments, this approach is still brittle to spikes in load.

ATP separates each of these services and handles how's these services communicate and operate. I can't really explain it better than their documentation, but one easy example to point to is how you can self-hodt your own PDS (Personal Data Server) which stores your account data and posts, meaning you can keep it stored entirely on your own hardware separate from whoever provides your feed building and presentation service.

I'd highly recommend reading both the ATP and ActivityPub documentation as both are very well written and communicated these differences more effectively.

If I have to explain why separation of concerns in the way that ATP approaches things is more scalable, I might suggest doing some reading on web application architecture patterns and the pros, cons, and practical applications of each.

The TL;DR version is that if the different components of your application run independently of each other, it's easier to have redundancy and extra resources in place for the specific components that require it.

This is also helpful for federation, as the end goal of ATP is to be able to host your personal data where you want, use the feed builder that you want, the labeller that you want, the app view that you want, regardless of who runs each service.

[–] OmnipresentWalrus@feddit.uk 1 points 3 hours ago (2 children)

The "how so" is evident if you try to use any of these platforms regularly. ActivityPub based platforms chug slowly and/or just don't load feeds at all. Mastodon and Pixelfed have been very disappointing. The software is heavy to run and the monolithic structure means your provider has to run everything in one stack. If that stack can't keep up with demand at any link in the chain, the whole thing falls over

As for why they're waiting, they're waiting on public release because they're in active development. They are working with a number of independent devs. This is all explained in the ATP documentation.

As for why you should trust them, the question is trust them with what? If you don't trust them with holding your data, self host your PDS and you can host your account and all it's posts yourself. If you don't trust their feed, you can use one of the community's many other feed algorithm options.

Personally I don't have a problem with the current "distributed data, centralised presentation" model since you still have the option to select your own feeds.

I highly recommend reading both the ActivityPub and ATP docs as they're both freely available and easy to read. The difference in design philosophy is apparent in both, and anyone who's ever worked on webscale projects will be able to see why ATPs more distributed model is more scalable.

[–] OmnipresentWalrus@feddit.uk 0 points 10 hours ago* (last edited 10 hours ago) (6 children)

ATP is also federated, and the model is much more scalable than ActivityPub. You're already free to host all of your Bluesky account and all your posts on your own PDS. They're opening up the other services to federation as they reach maturity.

[–] OmnipresentWalrus@feddit.uk 13 points 5 days ago* (last edited 5 days ago) (2 children)

Interesting way to say you don't understand federalisation. While using a federated platform.