I don't really agree with the characterization of a lot of this post, but one specific technical detail:
> If Bluesky Social, PBC decided to show ads (or do something else you don’t like), it would be very hard for you to switch to a different Relay and still be able to interact with all the other folks who stayed at the Bluesky Social, PBC Relay.
This is backwards, as far as I know. Relays aggregate information from PDSes. If you decide that you want a relay that ignores certain PDSes, and then use an AppView that listens to that relay, you could use it. Your posts would still end up in your PDS. The BlueSky Relay could still be told about your posts, just like your relay would be told about your posts. This doesn't require any other people to do anything.
The issue to be worried about with relays is the other way around: If Bluesky's relay decides to ignore your PDS, then folks that use that relay would have issues seeing your posts. Just like how your relay would be ignoring the ads.
To be fair to them, they have done a significant amount of work to design the network to be open to competing servers, and I think it would be quite tricky to unpick that. In comparison to successful networks like TikTok, Twitter, Facebook, LinkedIn, ATP gives a far fairer playing field and Bluesky hasn't done anything (aside from taking funding) to suggest they're not going to run with it.
You are right that they could change their architecture so that their Relay is more trusted or blocks others in some way, once they capture the market. I am not sure what guarantee they could give with the current ATP arch - perhaps a committee would help, but other social networks have no incentive to support ATP.
They have done everything to have the appearance of an open protocol and use that as a competitive advantage against incumbents. However, if you look at the reality, it's a very centralized service run by the same company which controls and develops the protocol.
If they are serious about this, they should hand over ATProto to an organization like W3C.
They said that they don't think ActivityPub is good enough – but why not work with the ActivityPub team to make it better instead of building their proprietary protocol? Why should we trust them?
We looked quite closely at ActivityPub. Here's why we didn't go with it:
1. AP doesn't have the facilities for global aggregation which can power search, discovery, algorithms, and metrics. The user community has been very clear that they do not want it to be introduced. We felt the connectivity of a shared global network was extremely important to the UX, but we felt it would be wrong to fly in the face of the AP world's established norms & wishes.
2. We felt that strong account portability was an extremely important feature of the system, to ensure that users don't get locked into a specific host. AP's redirection model of account migration concerned us.
3. We're concerned about the cost structure of AP. We're concerned that self-hosters are going to pay a prohibitively high price for virality. This is why we designed the network to avoid placing heavy load on PDS.
I know that the AP world is frustrated with the competition between the protocols and suspicious of how we've chosen to do things. It's a shame because I think we're after similar things, and hold similar values. We didn't set out to sabotage the AP world; we just felt like there were important changes that needed to happen for this mission to work.
Note, however: Our software is not proprietary. It's open-source. The specs are open. The network firehose is open. We're working on getting every piece of the infrastructure into good governance and straightforward self-hosting. It just takes time.
>AP doesn't have the facilities for global aggregation which can power search, discovery, algorithms, and metrics.
Very nice way to say "AP isn't centralized enough".
>We felt that strong account portability was an extremely important feature of the system, to ensure that users don't get locked into a specific host. AP's redirection model of account migration concerned us.
>We're concerned about the cost structure of AP. We're concerned that self-hosters are going to pay a prohibitively high price for virality. This is why we designed the network to avoid placing heavy load on PDS.
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. 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. The fact that ATProto requires a relay is at complete odds with the premise of decentralization and federation. You're no more decentralized than google search giving you results from different websites.
>I know that the AP world is frustrated with the competition between the protocols and suspicious of how we've chosen to do things. It's a shame because I think we're after similar things, and hold similar values. We didn't set out to sabotage the AP world; we just felt like there were important changes that needed to happen for this mission to work.
We're frustrated with bluesky describing itself as decentralized and federated when it isn't. Look, I get it, You guys are trying to run a business. You can't control ActivityPub so you made ATProto. It's your thing so you can make what you want with it. You can make it open-source, but at the end of the day, you guys decide. Just be honest about it.
Believe it or not, it’s possible to have meaningful differences about the way to design a system while maintaining the same motives. It’s clear that you’re happy with the ActivityPub design. I’m not. And your argument right now is akin to saying the Web isn’t decentralized because it uses search engines.
If you actually cared about having a meaningful conversation you wouldn't be tip-toeing around my arguments. There's clear dissonance between the words you're speaking and the actual reality of how ATProto/Bsky works. You say you have the same motives yet this is not what the technology shows.
>your argument right now is akin to saying the Web isn’t decentralized because it uses search engines.
> 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.
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.
> 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.
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.
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.
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.
> 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.
No, the fact that it's a PBC does not necessarily limit the right of their investors. PBC just means that they need to commit a certain percentage of their profit to a cause. It's still a for-profit company owned by shareholders. They have not publicly disclosed their charter or other information.
That is not what this means at all. Legally, it means that the company has other priorities that it must consider equally to creating profit. This means that investors have a much higher standard to have standing to sue the company or oust the CEO if they don't return a profit or don't return profits directly to investors.
A good example of what this means in practice is developer awards from Bluesky Social. As I understand it, once Bluesky PBC starts making some profit they are planning to begin placing something akin to bounties on successful app projects within the protocol. I believe Graber called this "Coopetition" at some point, where developers are "competing" within the ecosystem but simultaneously working together to make the protocol's foundation stronger.
This is something that a PBC structure makes immeasurably easier to do. Why? Because the company has more responsibilities than simply returning profit to shareholders. The shareholders can't simply sue the company or oust Graber because of this, since Bluesky Social also has a legal responsibility to "develop and drive large-scale adoption of technologies for open and decentralized public conversation". Please do get read on what it actually means to be a PBC.
> Legally, it means that the company has other priorities that it must consider equally to creating profit.
Ok, so it's even more vague than how I understood it. This could mean anything.
Venture capital does not care about profits, they just care about selling their share at a considerably higher price than they bought it within ~ 7 years. In reality, most of the time, this happens through an acquisition. Many times this happens without the acquired company making a single cent of profit.
So how does it matter that Bluesky Social is a PBC in this context? It is still owned and controlled by shareholders, many of them venture capitalists. It can still be sold at an uncapped profit to the share holders.
I think you should reread my comment, as I have already answered this. The "control" that shareholders have over the company is severely limited, and they have limited legal recourse against company leadership if they decide to use profits in a manner they disagree with, but fulfills their charter. It should be fairly obvious in my example that it is not in the best interests of the shareholders to quite literally give away profits.
> a public benefit corporation shall be managed in a manner that balances the stockholders’ pecuniary interests, the best interests of those materially affected by the corporation’s conduct, and the public benefit or public benefits identified in its certificate of incorporation.
There is no language about committing a percentage of profits to a cause.
You are right that it's not specifically required do donate a certain percentage of your profits. It's even more vague than that. It basically just means that you need to commit to a certain "public benefit" in your certificate of incorporation:
"The Certificate of Incorporation of a benefit corporation commits the company to spending some of its profits or resources (or both) in support of a specific public benefit. If a benefit corporation decides to stop doing business and dissolves, the shareholders receive the proceeds of the sales of assets, after liabilities are paid." (from https://www.delawareinc.com/blog/non-profit-corporation-vs-p...)
I fully agree that a PBC isn’t a panacea. That doesn’t change the fact that you’re confidently asserting incorrect things. I don’t expect that you’ll change your mind, so I’m not trying to convince you, I just want to make sure that the facts are laid out.
What I'm saying is that very likely Bluesky will grow for a few years without making a cent of profit, and be acquired by another company. And this has not much to do with if they are a PBC or LLC or whatever...
% of VC-funded tech startups that exit via appreciable >$0 acquisition is actually not particularly high relative to total failure/success, which makes sense if you think about it. The odds would seem even lower in this case just for mentioning the word "federated," regardless of the tech.
How am I wrong? If I'm wrong it's that even more vague what a PBC needs to legally do to support its public cause, but in reality many PBCs end up with donating a certain % of their profits. But my understanding is that there are also other ways to support your public cause.
We don't know what Bluesky Social PBC has committed to in their certificate of incorporation.
A standard C corp (and more relevantly its officers) is legally obligated to maximize profit for shareholders at the expense of any mission.
For a B-corp if the investors sue the board or CEO for breaching fiduciary duty for not maximizing profit, the response is "we were following the mission (and you knew we would be following the mission going in), GFY"
Who cares about profit? We're in the VC world now, where many companies grow quickly without making a cent of profit and then get sold off. How does a B corp help here?
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
Mainly because your here and replying, I looked at self hosting the PDS and bounced off because there wasn't really any documentation on day 2 ops. How do I do backups/disaster recovery? What data is stored here and what happens if it's lost? What kind of traffic should I expect to see? What are the risks around updates?
I can probably figure this stuff out by learning the protocol, but I wish the documentation around hosting was deeper than "run this script to install it, run this other one to update"
> Compare this to Mastodon, where you can easily switch to a new server and most your follower won’t even notice and business as usual carries on.
I would like to think this is true, but there are just too many frustration stories of confusion of 'which instance' to choose, losing posts due to admins (and followers) shutting down instances and having to tell your followers where to go next.
Best part is the instance they are most likely switching to is the main instance (mastodon.social) since that is the biggest one and less likely to go down, and encourages centralization.
To solve this, they should close sign ups. Why haven't they done that yet?
>To solve this, they should close sign ups. Why haven't they done that yet?
They do periodically closes signups.
>I would like to think this is true, but there are just too many frustration stories of confusion of 'which instance' to choose, losing posts due to admins (and followers) shutting down instances and having to tell your followers where to go next.
Except on bluesky, you don't even get to be confused because it doesn't support any kinds of moves!
It's pretty simple really, Bluesky hasn't magically figured out how to make proper federation work. they just say they're federated but in reality they're really just centralized.
> Except on bluesky, you don't even get to be confused because it doesn't support any kinds of moves!
This is simply not true. There's hundreds of folks who have moved their stuff over. I haven't yet but will be doing so, been too busy with other stuff. But I follow a bunch of people that have moved, and there was zero disruption on my end.
I personally find Mastodon confusing and I'm always unsure if I'm on the "correct" instance or not. I understand that all the instances can talk to each other, but it still feels disjointed to me; like I'm missing part of the conversation because it's happening in the other room.
Bluesky doesn't have the same problem. I understand that they don't have true federation today but that's not really a blocker for me. I'm don't want to limit my reach just because something isn't perfect right now. If they get true federation working in the future, great! If they don't then I'll just deal with moving to the next platform. Granted, I don't make money or anything from any social platforms, but it's not the end of the world if you have to start over. At least not for me.
The issues you describe are integral parts of decentralized protocols, and they can't be solved by technology. The reason Bluesky does not have these problems is because they are de facto centralized. No confusion of choosing servers if there's only one server, right?
> having to tell your followers where to go next.
On Mastodon, you can set up an automatic forwarding so your followers automatically follow your new account, they don't even notice you have switched instances if they don't look closely at your handle.
Mastodon migration is not atomic and requires the instance you are migrating from to remain operational (and non-adversarial) long enough for all of your friends' instances to notice you have moved and update their contacts. It doesn't preserve your follows. On Bluesky you just need to push your repo onto a new PDS and sign a new DID telling the network which PDS has your data. Everything else is seamless and atomic.
However, I also have grown to absolutely love Mastodon and its so many different communities. Whats become clear to me is, I want both, Bluesky and Mastodon.
As I've said many many times before, when it comes to free time, We like different vibes at different times. Sometimes we want a discord night, or maybe an indie movie theater, sometimes we want a drunken dance night, sometimes we want a goth club, sometimes we want a quiet night around a camp fire.
I'm super skeptical when this same set of VC people keep trying to jam all of us into the same place and they keep desperately trying to convince us "This is the only place you want to be! All of you. All at once!" its super weird. and a staggering lack of understanding of humans.
I fell in love with big cities for these exact reasons--there is always something different to do no matter what my mood is. And this is why i fell in love with the wider internet. Always something to do depending on the vibe im hunting. No i dont want to go to the same place with every single other person night after night and no i definitely dont want to hang out with people i dont like at all--thats a weird suggestion.
I want so many options depending on my mood.
At the end of the day both Bluesky and Mastodon are incredible and I dont see one "erasing" the other.
As the article suggests, ideally Bluesky will protect against the inevitable VC vampire suckification and finally actually truly decentralize.
> Compare this to Mastodon, where you can easily switch to a new server and most your follower won’t even notice and business as usual carries on.
But this isn't true, there already were horror stories where users were held hostage by non-cooperating server blocking the transfer - because you can't easily switch as described here, your data doesn't belong to you, that's one big area where bluesky is architectured much better
I find the factionalism among nerds over Mastodon and Bluesky to be a fascinating display of clique dynamics at work. Perhaps the most amusing bit is the folks most focused on fighting out these clique dynamics are the ones most likely to think they're the rational types that don't get involved in social dynamics.
At the end of the day, you opt-into either network. My only wish is that the networks interoperate, which is possible right now but as an opt-in thing is patchy and voluntary.
I can tell you that personally, if Bluesky wasn't so miss-reported as being federated and decentralized I wouldn't be caring as much as I did.
I'm happy that bluesky is successful. what I'm not happy about is that it's claiming to be something it isn't and in doing so, undermining all the work people have put into an ecosystem that is TRULY federated and decentralized.
In the short-term, yes. In the long-term, I hope not. You are probably right, but I want to keep supporting initiatives like ActivityPub and hope that when Bluesky fucks up, Mastodon and other services are still around.
I'm kind of being doom'n'gloom, but unfortunately, this always seems to happen, and folks who previously disavowed Twitter/X when Elon took over still stuck around for 2 years.
I don't believe the whole "I don't know what server to pick" complaint about Mastodon, because the mainsite literally has a huge button that says "Join mastodon.social"[1]
> If Bluesky Social, PBC decided to show ads (or do something else you don’t like), it would be very hard for you to switch to a different Relay and still be able to interact with all the other folks who stayed at the Bluesky Social, PBC Relay.
This is backwards, as far as I know. Relays aggregate information from PDSes. If you decide that you want a relay that ignores certain PDSes, and then use an AppView that listens to that relay, you could use it. Your posts would still end up in your PDS. The BlueSky Relay could still be told about your posts, just like your relay would be told about your posts. This doesn't require any other people to do anything.
The issue to be worried about with relays is the other way around: If Bluesky's relay decides to ignore your PDS, then folks that use that relay would have issues seeing your posts. Just like how your relay would be ignoring the ads.