| Sure. I'm really happy to debate the substance of these designs, because it is interesting and should drive decisions. > The relay isn't secondary. proof of the matter is, bluesky last week went down because it was down. Mmm kind of. The data is primarily stored in the PDSes and there can be a plurality of relays and appviews, none of which are considered authoritative / primary. If a relay goes down, anybody downstream of it is (fire)hosed, but that's just systems. One useful observation -- the relay is a convenience we implemented so that work can be shared. Generally speaking an appview (or any other service) could crawl PDSes directly & sync their event streams. You're right that a ban from the bsky relay is going to affect visibility among anybody downstream of it, and that a relay monoculture would centralize control. This is why we have an organizational goal to get other independent relays running. Regarding costs, there's a laws of physics thing at play. If you want global activity in your app, you're going to pay for it like we are. However -- if youre happy with a subset that's similar to ActivityPub, you can setup an appview which selectively syncs according to the social graphs of registered users and other known links (like URIs of replied-to posts). You could attach it to a PDS if you wanted. You then might want an additional layer for push-notifying peers for activity outside their existing social graph, though that's somewhat optional (you can get a pretty rich dataset from a pull-based crawl model). If it turned out that the global view was cost prohibitive for any org, this is the implementation I'd push for people to develop. This "mode" was in our original plans but cut for time; it's not something the protocol needs to prescribe for or against. >I think you're overestimating how taxing going "viral" is on an ActivityPub server. if one of your posts goes viral, it doesn't get hit for every follower you have. It'll only be a request per instance. Maybe you're right. But we wanted to target an aggressively low capital and management cost for account hosting. >>When the software is sufficiently tested and implemented. >I would think this was a more pressing matter seeing your previous response. Well. We do our best to juggle priorities, but it's a small team with a lot of work on our plates. |
I disagree that data hosting is the most important part. I think switching "servers" and still being part of the network is the most important part.
You are right that ATProto is open-source, but you ignore the fact that there's only one company controlling the development of ATProto. You can decide to close it down tomorrow, or you can decide which contributions to accept and decide the general direction of ATProto at your own discretion.
This is all fine, you can do whatever you want, but don't try to hide behind detailed technical discussions when comparing ActivityPub to ATProto. Because the difference is much more fundamental than the question how much RAM my server needs if a post goes viral.
Don't say Bluesky is decentralized and federated, because it is not today.
I understand that you are not one of the founders and you probably see this from a naive technical perspective. But working for a company that needs to show VC-level returns, I think you are being ignorant of how the future will look like.
Finally: If the team at Bluesky sincerely thought that ActivityPub is not good enough, why not work with the ActivityPub team to improve the standard and address the challenges? Or, why not give ownership of ATProto to an independent standards organization? I understand that you don't want to do this because you want to control how to develop the protocol, you want the speed and flexibility. That's fine. But don't act like ATProto is the same as ActivityPub in terms of openness.
Sorry for the long post :-)