Benvenuto nel Poliverso

jonny (good kind)

11 mesi fa • •

jonny (good kind)
11 mesi fa • •

Compare figure 3 here in the #atproto / #bluesky paper
bsky.social/about/bluesky-and-…
To the diagram here:
bsky.social/about/blog/5-5-202…

The paper figure is a lot cuter, but by linearizing it and presenting it as two parallel tracks they have obscured the most salient feature of the network: the big relay in the middle. Beyond "centralization bad," that pins down most of the undesirable and dangerous features of the protocol, and makes it seem like theres a lot more choice than there is.

Since the design purposefully hides the architecture: you dont know where your feed generators are drawing from, or those used by your friends. So you cant know what the effect of choosing a different relay would be, aka the main relay is always indispensable. Importantly the relays subscribe to you, you dont push to the relay, and since you arent really supposed to operate your own data store, you can be dropped from the network without knowing - the relay serves as an unaccountable point of moderation.

Federation Architecture Overview - Bluesky

Soon, we’re launching a sandbox environment for federation. In advance, we want to share some technical details about our design decisions.

^Bluesky

reshared this

in reply to jonny (good kind)

jonny (good kind)

in reply to jonny (good kind) • 11 mesi fa • •

They describe another real weakness in the protocol on page 4 that also makes the single relay indispensable: fedi has backfilling problems, but its possible to solve them because you can at least know who does have the complete picture - the OP server knows of all interactions (that it wants to). Since there are no backlinks, and PDSes are not dereferenceable by username, the only way the whole thing works is if someone has a relatively complete picture of the whole network - otherwise eg. you would have no idea who to deliver a post to.

in reply to jonny (good kind)

jonny (good kind)

in reply to jonny (good kind) • 11 mesi fa • •

Its this part for me that tells the whole story: #atproto was designed for a new kind of advertising market, and when their VC money and puttering domain registration revenue streams dry up, control over the main firehose relay is a big gaping profit vector waiting to be capitalized on.

While operating a small PDS is designed to be cheap, operating
an indexer that ingests the entire network requires greater comput-
ing resources. We therefore expect that there will be fewer hobbyist
indexers than self-hosted PDSes. Nevertheless, as Bluesky grows,
there are likely to be multiple professionally-run indexers for var-
ious purposes. For example, a company that performs sentiment
analysis on social media activity about brands could easily create a
whole-network index that provides insights to their clients. Web
search engines can incorporate Bluesky activity into their indexes,
and archivists such as the Internet Archive can preserve the activity
for posterity

#atproto

Steffo (moving) likes this.

reshared this

in reply to jonny (good kind)

jonny (good kind)

in reply to jonny (good kind) • 11 mesi fa • •

They continue to misunderstand or refuse to acknowledge the risks of the protocol, and this paragraph is a decent example - you are free to choose a different service if you dont like something. Its a market, consumer choice solves. Notice the "well behaved" part though. Adversarial actors can and will follow you, and there's very little you can do about that since identity is so cheap on the protocol. You can just infinitely spawn accounts and troll someone into oblivion in a way that isnt possible on other mediums. You can simply block all new contact, but then that activity will likely still be visible to everyone else on the platform, shrouding everything you post in hate, spam, etc.

Id love to be wrong about this, but when they truly open federation I cant see how it wont go off like a bomb, or else require really strident relay-based moderation, as the devs described to me here: github.com/bluesky-social/atpr…

To display this information in the user’s client app, the client
queries the user’s own PDS, which then fetches the neccessary data
from an App View. The App View is also responsible for enforcing
moderation controls: for example, if one user has blocked another,
and one of the users’ repositories contains a record of an interaction
that should not have been allowed due to the block, then the App
View drops that interaction so that nobody can see it in the client
apps. This behavior is consistent with how blocking works on
Twitter/X [ 61 ], and it is also the reason why blocks are public
records in Bluesky: every protocol-conforming App View needs to
know who is blocking who in order to enforce the block [ 16 , 41 ]. If
users are unhappy with the moderation rules applied by the App
View operated by Bluesky Social PBC, it is always possible for
third parties to operate alternative App Views that index the same
firehose and present the data in a different way

Upcoming Disruptive Protocol and Infra Changes (2023 / early 2024) · bluesky-social atproto · Discussion #1711

This document tracks currently-planned changes to atproto (the protocol) and Bluesky (the company) infrastructure services which may impact the larger ecosystem of developers and services. These ar...

^GitHub

in reply to jonny (good kind)

jonny (good kind)

in reply to jonny (good kind) • 11 mesi fa • •

There is amazingly little detail - still - on how the labeling services, the core piece of safety technology on the protocol, work. Its one paragraph here. That speaks volumes.

Edit: this is no longer true, this system is reasonably well described now

Questa voce è stata modificata (2 mesi fa)

Oblomov reshared this.

in reply to jonny (good kind)

jonny (good kind)

in reply to jonny (good kind) • 11 mesi fa • •

I said this about 6 months ago when I first read the protocol, but as far as I can tell its still true: atproto is about as federated or decentralized as google alerts: neuromatch.social/@jonny/11055…

They make repeated allusions to designing the system like the web, but really they designed it like Google

Dr. jonny phd (@jonny@neuromatch.social)

so far, #BlueSky / #ATProtocol seems like a federated system the same way Google Alerts is a federated system. - you can self host your website or uses Google sites.

^{Neuromatch Social}

reshared this

in reply to jonny (good kind)

jonny (good kind)

in reply to jonny (good kind) • 11 mesi fa • •

Unlike threads, I genuinely want atproto to work. Multiple protocols working concurrently with different ideas, collaborating or competing, is good! There are and were plenty of good people that I genuinely admire that worked on this thing. There's enough shallowness and magical thinking in the end result, though, and not enough self-criticism or means of critical feedback to actually address the glaring abuse vectors, that I am pessimistic about bluesky and atproto becoming another healthy neighbor. When you're explicitly and uncritically calling it a marketplace in your whitepaper, I'm not interested.

in reply to jonny (good kind)

jonny (good kind)

in reply to jonny (good kind) • 11 mesi fa • •

I am interested in speaking off the record with anyone who knows anything about the early to middle history of the protocol development, from when Jack summoned a bunch of bright people into a private chatroom through when public designs started appearing. Ive found the public matrix rooms and read a decent amount of them, so im talking about before that/in private alongside that. If thats u, hmu. I know its fresh history and people justifiably dont want to speak ill of their friends, my questions are all about the transition of ideas, what got ruled out, when certain ideas got cemented into place. Not shit talking, archaology.

in reply to jonny (good kind)

jonny (good kind)

in reply to jonny (good kind) • 11 mesi fa • •

In case anyone reaches the end of this and reads it as me abjectly shitting on the protocol as being equivalently bad to eg. Twitter, threads, facebook, etc. Thats not what I meant at all. First priority: get people out of surveillance platform traps. BSky is not that YET, and is a sort of decompression chamber with similar aggressive and desperate vibe to twitter. Breaking dependence is hard, bsky is harm reduction. There is a sort of intrinsic visceral truth to "first as a tragedy, then as a farce," once people see a pattern, it's easier to raise critical resistance. Second priority: build a healthy web, p2p the fedi.

Questa voce è stata modificata (11 mesi fa)

Unknown parent

jonny (good kind)

Unknown parent • 11 mesi fa • •

@smallcircles i'm aware they say anyone can spin up a relay, what i'm saying here is that while that is technically true, it is not in practice possible to not use the main relay. even if anyone can spin up a relay, if all your friends subscribe to feeds that draw from the main relay (and they would have no way of knowing that was the case, since relay choice is doubly obscured through app views and feed generators), who cares?

agreed that "big graph server" was a huge branding miss and renaming it to relay is very funny.

the PDF linked in OP is titled "Usable Decentralized Social Media" - one thing's for sure, they are end-user product presentation first. they did not develop the backend server technology and then the client. they developed the client and then the backend server technology. this is actually super important to what is going wrong here - they imagine the primary problem with decentralized social media being that people don't want to see complexity, and thus an algorithmic marketplace where everyone provides for you, the hapless consumer, is the only solution.

and omfg i did not know they were doing PHONE NUMBER SIGN UP when their ENTIRE PROTOCOL is designed around PORTABLE IDENTITY. the FIRST ITEM in the protocol overview is "Users are identified by domain names on the AT Protocol."

@small circle 🕊 in calmness

Oblomov reshared this.

⇧