Notices by Émilio Gonzalez (res260@infosec.exchange)

@cwebber I'm hanging out there a lot and yes there is a lot of vibecoding. However, they don't seem to vibecode more than the average paid software dev.

In 2024, I'd say about 20% of my friends vibecoded. Today the number looks more like 90%. This is not specific to atproto, my understanding is that most people vibecode nowadays.

@evan That would make sense. For ATProto, not being required to think about the PDS and the relays implementations must help a ton to get projects off the ground quickly. Hope the Social API changes that 🙏

I love #activitypub but seeing how slow its development is compared to #atproto makes it hard to be excited about it. This goes for both protocol development and ecosystem development.

ATproto has many cool projects popping up every month, the vision is clear and platforms integrate with each other.

I don't see this excitement and work on the ActivityPub side :(

@cwebber I apologize this was poorly worded. The asterisk was used as a way to signal a mistake and I meant to apply it to the whole post not just "women".
I agree with the statements you made!

@cwebber and for trans I meant AFAB not women*

@cwebber Goes for most "woke" stuff from caring about climate change to being trans to being vegan

@evan @res260 I'll look this up thank you Evan. Is this not implemented much because it's a new thing, because of cultural fediverse chalenges or because of some other thing?

I wish #ActivityPub allowed for a single identity to be used on myltiple services.

I don't want to create a mastodon account AND a loops account AND a pixelfed account AND a lemmy account. Why can't I just have @res260? :(

If AP steals one idea from #ATProto, it should be this.

@BeAware I would maybe nuance your first phrase like this: "so basically, it's not decentralized, but the technology is there if some people with a medium amount of resources want it to be decentralized."

It's currently not entirely up to bluesky to decide how decentralized the network is. They have in their roadmap things planned that with help with decentralization, but everything is currently there for people to make it more decentralized.

However, the BlueSky company COULD make it harder to decentralize, for example by only allowing THEIR AppView to consume from their Relays (firehose). This is why having more independant relays will be key to ensure that ATProto becomes more decentralized. If you know about TOR nodes, it's kind of the same things. If one entity controls most TOR nodes, this entity owns the TOR network, which is not supposed to happen.

TOR as a protocol and network kind of has a similar problem, as running a TOR node can be expensive.

A few facts and thoughts about #BlueSky being decentralized or not:

1. #ATProto (the protocol behind bluesky) is decentralized and open-source, but is controlled by a for-profit (albeit fiscally a public benefit) organization, "Bluesky Social PBC".

2. "Bluesky" refers to a sum of ATProto concepts, notably the AppView (bsky.app), the main Personal Data Servers (PDS, bsky.social), and the Relays (or firehose, bsky.network). There are others, but they're the 3 important ones.

3. Anyone can run their own AppView, PDS or Relay AND consume the content from/get their content consumed by the Bluesky infrastructure. HOWEVER, not everything is trivial or cheap to run.

3.1 A PDS, which contains your data (account details but also posts, likes, follows, etc), is trivial and cheap to self-host. Cheaper than hosting a mastodon instance, even, because it does way less stuff and receives way less requests. See https://github.com/bluesky-social/pds

3.1 An AppView (the presentation layer, where users interact with ATProto content) can be created by anyone, but the bsky.app backend is NOT open-source, so there are not a ton of options right now.

3.2 Running a relay is trivial but expensive to self-host. This is because its purpose is to act as an aggregator for all the PDS so that AppViews can consume the data in a way that scales better. The Bluesky relay implementation (bigsky) is open-source: https://github.com/bluesky-social/indigo/blob/main/cmd/bigsky/README.md
About 2.5 months ago, 4.5TB of storage was needed and an OVH server costing 150$/month worked to host a full-atmosphere relay (more on that later).

1. To make a comparison with #ActivityPub (the protocol behind #mastodon ), the AppView and PDS is the same thing in ActivityPub, and the concept of relay doesn't exist. There are advantages and drawbacks to both architectures, I might do a future post highlighting those.

2. With those definitions out of the way, some observations:

5.1 A lot of users self-host their PDS, but the vast majority of users chose the simpler option.

5.2 There are some alternative AppViews built on ATProto, but the vast majority of users visit bsky.app.

5.3 There are very little non-bluesky self-hosting of relays, mostly because of their prohibitive cost. Running the bigsky relay is expensive partly because of design decisions for ATProto and partly because it takes ALL content from ALL accounts for ALL the network on the atmosphere (in this case atmosphere == fediverse but for ATProto). This is like if your Mastodon instance queried ALL servers for ALL accounts querying ALL posts. In the future, there might exist relays that don't scrape ALL data but only a subset of it, which would bring down costs, but it's not yet the case.

1. So "is Bluesky decentralized?"

6.1 In theory, yes, everything that bluesky does on ATProto can be.

6.2 In practice, however, the most decentralized part of Bluesky is the PDS, where the user data is stored, and even that is not that decentralized.

6.3 Will it stay this way? I'm hopeful it won't, but I don't know. ATProto is fairly new compared to ActivityPub, and the ecosystem around it was mostly built by the BlueSky company, but I expect this to change in the future. However, the cost of entry for things built on ATProto will always be more than the cost of entry for things built on ActivityPub.

6.4 Things built on ActivityPub will always be more decentralized than things built on ATProto, because of design decisions from both of these protocols.