> ATProto is a better looking protocol already.
Are there benchmarks for this? What's the level of difference here? Request frequency seems closely linked to activity and XRPC bodies are JSON just as ActivityPub so message size should be within order of magnitude at least. Are there architectural differences that reduce request frequency significantly?
> If this had to scale to a larger instance the costs would spiral fast.
Are we talking bandwidth costs or processing. I know the popular ActivityPub implementation is widely considered to be pretty inefficient processing-wise for reasons unrelated to the protocol itself: is that a factor here?
Now on my single instance it's not too bad because 1. I follow maybe 40 people and 2. I have like max 10 followers. For an instance with people with high follower counts across multiple other instances it could get to be a problem fast.
I think the weirdness is with Bluesky all that cost is still there but it's now handled by a small group of massive megacorps which is a real tangible benefit to self-hosters but you could have that on top of AP by running your service off what would essentially be a massive global cache of AP content which is what the indexer is.
I haven't implemented AP from scratch so I may be missing technical details precluding this, but it sounds like it may at least partially be covered by https://www.w3.org/TR/activitypub/#shared-inbox-delivery
... in which case it may be an implementation issue?
Mind you, there is liberal use of "MAY" there which I find is always a problem with specs: that would likely lead to mandatory chattiness of outgoing requests if you're federated with a lot of instances without shared inbox support, but should at least solve for incoming.
Which is why most browser-server communitcation is still limited by HTTP/1.0.
Except it isn't. That's not how this works out when there are benefits to all participants to implement these optimizations.
1. server with the sender constructs a map by receiving server that contains a list of all users on that server who should receive the message.
2. sending server iterates the map. If the receiving server has multiple recipients do a check to see if the receiving server supports this kind of 'bundled' delivery.
2a. If so send the message once with a list of receivers.
2b. receiving service processes the one message and delivers it to all the users.
Starting from scratch, just because you can theoretically design a better system, is one of the worst thing to do to users. Theoretically better also rarely wins in the marketplace anyway.
If you want a slightly lighter position: Software needs to be built to be migrated from and to, as a base level requirement. Those communities that do this tend end up with happy users who don't spend lots of toil trying to keep up. This is true regardless of whether the new thing is compatible with the old - if it doesn't take any energy or time, and just works, people care less what you change.
Yes, it is hard. yes, there are choices you make sometimes that burn you down the road. That is 100% guaranteed to happen. So make software that enable change to occur.
The overall the amount of developer toil and waste created en masse by people who think they are making something "better", usually with no before/after data (or at best, small useless metrics sampled from a very small group), almost always vastly dwarfs all improvement that occurs as a result.
If you want to spend time helping developers/users, then understand where they spend their time, not where you spend your time.
From a purely technical analysis ATProto looks better as a protocol to me. But I don't use Bluesky I use ActivityPub because the people I want to be connected to are there and not on Bluesky. I do think you could probably make improvements to ActivityPub that reduce operational costs. It's not something I feel the need to tackle right this moment because my usage doesn't incure those costs really.
The whole point is that it needs to be reasonably easy for people to run and scale their own servers. If people are constantly being burned out, quit, or run out of money, then it has an impact on regular users.
I don't think most projects do ;)
> If you want to spend time helping developers/users, then understand where they spend their time, not where you spend your time.
You're spending your time with ActivityPub, so this advice should apply to you, too. The bulk of potential users are spending their time on anything but ActivityPub. And as for developers, one of course needs to attract them, but I hear the people behind BlueSky have a couple of bucks, the ambition to create a huge potential new market, and a track record of creating a couple of things. I don't think they'll have trouble finding developers.
If BlueSky comes up with a better architecture, ActivityPub clients should rebase. BlueSky should pretend they don't exist, except if they have some nice schemas or solved some problem efficiently, try to maintain compatibility with that unless there's even the slightest reason to deviate.
Didn't ActivityPub have enough of a head start? Why didn't ActivityPub just use Diaspora? Why prioritize ActivityPub over OStatus?
Says everyone everywhere who thinks they made something better!
"If BlueSky comes up with a better architecture, ActivityPub clients should rebase. BlueSky should pretend they don't exist, except if they have some nice schemas or solved some problem efficiently, try to maintain compatibility with that unless there's even the slightest reason to deviate."
Look, i'm not suggesting whoever does it first gets to dictate it, but literally everyone thinks their thing will be better enough to attract lots of users or be worth it, and most never actually do/are. They do, however, cause lots and lots and lots of toil!
Your position is exactly what leads people over this cliff - better architecture does not matter. it doesn't. Technical goodness is not an end unto itself. Its a means, often to reduce cost or increase efficiency, and unfortunately rarely, deliver new features or better experience. Reducing cost or increasing efficiency are great. But architecture is not the product. The product is the product.
So, why is the Fedi not built on RSS/Websub/etc. then?
This is true everywhere?
However from an Ops perspective ActivityPub is incredibly chatty. If this had to scale to a larger instance the costs would spiral fast. Operationally and cost efficiency wise ATProto is a better looking protocol already. From a single individual user this won't necessarily be obvious right off the bat. But it will tend to manifest in either overworked operations people or slow janky instance performance.
While it's certainly a reasonable question whether the world needs another federated social protocol or not ATProto definitely solves real problems with the ActivityPub protocol.