[pfraze]

Very well.

> Very nice way to say "AP isn't centralized enough".

You seem to be operating under the misconception that having large secondary indexing services in the system is the same thing as binding the system to single organizations. Anybody can run a relay or appview, same as anybody can run a PDS.

> What's your current timeline to start accepting incoming account migrations back into the bluesky hosted PDS? When will account migrations officially be a recommended operation? Source: https://github.com/bluesky-social/pds/blob/main/ACCOUNT_MIGR...

When the software is sufficiently tested and implemented.

> First of all, self hosting an ActivityPub service is not prohibitively expensive, heck expensive just isn't even a word a would use at all.

This remains true only so long as the network remains under a certain size, and your posts never go viral.

> On the other hand, what's expensive is the cost of hosting the bluesky relay. What you're essentially doing is just taking on the burden/cost of data processing and hiding it from the end user.

We're keeping the most valuable part of the system -- account ownership -- from having its costs bundled with application ops. It's important that there are hundreds of thousands of account hosts. It's only important that there are 5 to 10 microblogging applications, and that users can switch between them as they come and go.

In fact, I would argue that binding user accounts to individual application instances & their governance like AP does is a massive mistake. It's much more important that you guarantee users' continuity of identity as apps come and go.

[S0y]

I Appreciate you taking the time to properly respond.

>large secondary indexing services

We've talked about this before. The relay isn't secondary. proof of the matter is, bluesky last week went down because it was down.

>Anybody can run a relay or appview, same as anybody can run a PDS.

That's just saying anybody can fork the network if they're not happy. that's not very collaborative and social.

>When the software is sufficiently tested and implemented.

I would think this was a more pressing matter seeing your previous response.

>This remains true only so long as the network remains under a certain size, and your posts never go viral.

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. Plus, task queues exist. Yes going viral is taxing on a server. it doesn't mean the solution is just to offload that burden to some centralized server.

>We're keeping the most valuable part of the system -- account ownership -- from having its costs bundled with application ops.

Except the tradeoff is relying on a handful of large organization that have the resources to burden the cost of running a network. Those networks then decide who gets to post or not. account ownership isn't worth much if you can't speak anywhere. If I were to get banned from the bsky relay, I'd be essentially barred from interacting with anyone on the ATmosphere until someone else came along and created a new relay or appview. On activitypub, maybe mastodon.social doesn't like what I say so they ban my instance. But at least I can still interact with the thousand of other instances that exist. Now you can say, don't be an ass and you won't get banned, and I agree. But when you've created a system where only large organizations have the capacity to run a network, Maybe now I get banned because Coca-Cola decided they didn't want anyone saying Pepsi tasted better on their network.

>In fact, I would argue that binding user accounts to individual application instances & their governance like AP does is a massive mistake.

I think we'll agree to disagree on this one.

As always Appreciate the debates pfraze, hopefully these conversation help users decide which platform they like the best.

[elfprince13]

> 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. Plus, task queues exist. Yes going viral is taxing on a server. it doesn't mean the solution is just to offload that burden to some centralized server.

I run a single-user Mastodon instance and replying to a viral post took me offline for like 24 hours.

[pfraze]

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.

[shafyy]

pfraze I appreciate that you take the time to engage here. I understand that you thought that ActivityPub had challenges (rightly so) and that's why you decided to develop ATProto. ActivityPub is far from perfect and needs to be improved. But the decisions you made with ATProto so far make real federation almost impossible.

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 :-)

[pfraze]

Back in 2012, I was the first developer to join Dominic Tarr on Secure Scuttlebutt. I built Patchwork, the first client. If you’re not familiar with SSB, give it a look! It’s an aggressively anarchist technical model. After a year and a half, I had serious concerns about our ability to attract users. I realized that any activist effort needs a theory of change. For a software technology, that’s the market. We need to make better products if we want our technological goal to succeed.

The model we follow is more federal more than confederal. We use strong leadership that can be replaced. We use that in the governance, the technical design, and the execution. We also follow a kind of separation of powers through modularity, and an aggressive focus on the right to exit. SSB was “no authority ever” and it failed to scale. ATProto is “no permanent authority.”

Give the essay The Tyranny of Structurelessness a read sometime. I’ve worked in open source for my entire adult life and I’m now 38. There’s always somebody in charge. It’s not better when you don’t know who.

[shafyy]

> There’s always somebody in charge. It’s not better when you don’t know who.

This is not black and white. And to be honest, it is telling that you throw this statement into the room. Of course, there are also organization / people who have more weight in saying into which direction standards like ActivityPub should be developed, but this is a far cry from the protocol roadmap being owned by a single for-profit company.

> I realized that any activist effort needs a theory of change. For a software technology, that’s the market. We need to make better products if we want our technological goal to succeed.

I agree, and Bluesky is obviously a great product. It is very likely that building on a truely decentralized protocol like ActivityPub has too many drawbacks to build a mass product in today's world. This is beside the point, though.

> The model we follow is more federal more than confederal. We use strong leadership that can be replaced

It can be replaced in almost the same way as you are replacing Twitter. Or any service can be replaced by another. At best, ATProto is a glorified import / export feature in this context.

Your work history has nothing to do with Bluesky's future. Bluesky is not owned by you, and while you currently might have some say, as soon as the VC ROI pressure starts building, nobody will care.

To be clear, I don't doubt your personal intentions. But it is very naive to believe that a protocol developed by a for-profit company that has just taken in $ 23 million is somehow incentivized to build a network for the good of the people first and not for their own profit. And don't tell me that those two are the same thing or aligned somehow, please.

I just would like to know this: How you can say that Bluesky is decentralized while the reality is that all your 20 million users sit on the same service run by the company behind Bluesky. And no, the ability to self-host your own data does not equate to being decentralized.

PS: I will read up on those topics you mentioned.

[elfprince13]

> Bluesky is not owned by you, and while you currently might have some say, as soon as the VC ROI pressure starts building, nobody will care.

Bluesky is a PBLLC which pretty severely limits the rights of their investors.

[elfprince13]

Just gonna throw out a link to this whitepaper co-authored by the now-CEO of Bluesky and one of the lead authors of ActivityPub https://gitlab.com/-/snippets/2535398