However, I stand by my assertions that Bluesky is not meaningfully decentralized and that it is certainly not federated according to any technical definition of federation we have had in a decentralized social network context previously. To claim that Bluesky is decentralized or federated in its current form moves the goalposts of both of those terms, which I find unacceptable.

[–] cypherpunks@lemmy.ml 4 points 3 days ago (1 children)

The blog post also says this:

There is one other thing which Bluesky gets right, and which the present-day fediverse does not. This is that Bluesky uses content-addressed content, so that content can survive if a node goes down. In this way (well, also allegedly with identity, but I will critique that part because it has several problems), Bluesky achieves its "credible exit" (Bluesky's own term, by the way) in that the main node or individual hosts could go down, posts can continue to be referenced. This is possible to also do on the fediverse, but is not done presently; today, a fediverse user has to worry a lot about a node going down. indeed I intentionally fought for and left open the possibility within ActivityPub of adding content-addressed posts, and several years ago I wrote a demo of how to combine content addressing with ActivityPub. But nonetheless, even though such a thing is spec-compatible with ActivityPub, content-addressing is not done today on ActivityPub, and is done on Bluesky.

My comment should have been clearer; what I meant when i said it is more "decentralized architecturally" I was referring to the data model part of the architecture as opposed to the physical server infrastructure currently operating it. The latter is obviously quite centralized still, but the former is designed for resilience against nodes unexpectedly (and permanently) failing.

[–] jivandabeast@lemmy.browntown.dev 5 points 3 days ago (2 children)

Okay yes this makes sense. Although, honestly i think I'd prefer the AP method of doing it because BlueSky sends ALL content to all nodes, so it's MUCH less cost effective to join with a private server.

I run my own lemmy instance, so i know the data volume since 2023 has been probably like a terabyte or so. But, with BlueSky I'd have to account for the data volume of all users on the platform as a whole, bringing the data volume way up to tens of terabytes (a guess based almost entirely on nothing).

So it really boils down to yes I agree that AP has problems with data accessibility, but I'd prefer that over unnecessary data redundancy

[–] cypherpunks@lemmy.ml 4 points 3 days ago (1 children)

with BlueSky I’d have to account for the data volume of all users on the platform as a whole, bringing the data volume way up to tens of terabytes

I think this is a common misconception based on some critics' incorrect assumptions and back-of-the-envelope math. See the atproto overview for the different components involved, and then this post (from a BlueSky employee) "A Full-Network Relay for $34 a Month" for some numbers.

If I understand correctly, to run a "full nework relay" does mean to consume all of the text posts from all known servers, but not necessarily all of the media, and not necessarily to keep data you aren't interested in for any long period of time.

Also, you can run your own PDS and/or App Views without running your own relay at all. And, you can also use multiple other people's relays.

Disclaimer: I'm not an atproto expert, and I haven't set any of this up myself.

[–] irelephant@lemmy.dbzer0.com 2 points 2 days ago

You can design an appview that crawls PDSes directly, no relay needed.

AppViewLite does that

[–] irelephant@lemmy.dbzer0.com 1 points 2 days ago

You can actually do it like mastodon and only take on data from specific users or PDS. Wafrn does this.