| Brian Newbold has some posts contrasting the design decisions of AP vs Bsky, in reply to this EFF article, > a design tradeoff between atproto appviews and mastodon instances is that atproto appviews are generally "big world" and index the entire network, so the cost to run the indexing component scales with the size of network. (there is also read-volume scaling, separately) > in activitypub, the scaling needs of an instance roughly go with the number of users, and the volume of interactions they have with entire network (read and write). so instances can start small (fewer resources) > the point I was getting at is that actually you can have an atproto appview which doesn't index the entire network, just PDS instance of interest. > this has some "cheap and totally independent" benefits, but trades off against not being able to see and interact with entire network > aka, "full" appviews are more resource-intensive to get started, but have huge value. > (also, the protocol is designed to make it way way cheaper than web crawling or other trad indexing, both in terms of compute resources and in terms of admin/ops labor) https://bsky.app/profile/bnewbold.net/post/3kva4vxi45s2q Bsky's as a distributed distribution mechanism has yet to be tested in any major way, but the premise of bulk transmission seems more built-in where-as AP was crafted more as a person-to-person relationship. I'm less familiar with Mastadon's own protocols. It does seem like trying to keep Mastadon's sidekiq egress queues from flooding is a damned hard job for a lot of growing instances, at least it was ~2 years ago when I was active there. |