Email or username:

Password:

Forgot your password?
jonny (good kind)'s posts Post Back to profile
Top-level
jonny (good kind)

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
6 February at 15:27 | Open on neuromatch.social
24 comments
jonny (good kind)

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.

6 February at 15:31 | Open on neuromatch.social
jonny (good kind)

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

6 February at 15:38 | Open on neuromatch.social
jonny (good kind)

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.

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....

6 February at 15:44 | Open on neuromatch.social
jonny (good kind)

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.

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...

6 February at 15:51 | Open on neuromatch.social
Jon Leibowitz

@jonny is the community discord still open? there were good people there.

6 February at 17:42 | Open on jonleibowitz.social
jonny (good kind)

@jon
I think they may have shut it down, it was linked to the matrix rooms and they would always talk about how the discord was silent except for bot spammers

6 February at 17:54 | Open on neuromatch.social
Jon Leibowitz

@jonny @jon The "community" was renamed to remove its formal connection with the actual Bluesky biz dsocialcommons.org

6 February at 17:55 | Open on jonleibowitz.social
Jan
Tim Bray

@jonny I was part of the early discussions, drifted away before they actually incorporated the non-profit. I was interviewed by Jack & Parag while they were still at Twitter: β€œThanks but no, not a candidate to lead this thing." My impression is that most of the discussion was unsurprising. They worried really a lot about portable identity. I like a lot of the Bluesky theory but your point about cheaply spawning infinite sock-puppet identities is something I hadn't thought of.

6 February at 21:32 | Open on cosocial.ca
Tim Bray

@jonny My impression is that Jay Graber & Paul Frazer & posse are decent people trying to do a good thing. Another impression is that Dorsey hasn't been significantly involved in really a long time and generally is no longer relevant to discussion of Bluesky.

6 February at 21:33 | Open on cosocial.ca
jonny (good kind)

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.

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,"...

7 February at 6:56 | Open on neuromatch.social
small circle πŸ•Š in calmness

@jonny yea, I mentioned some time ago that the renaming to "Relay" felt a bit like newspeak obscuring this point of centralization.

In the HN thread I tooted about yesterday, there's a lotta Bsky team interaction, divulging interesting tidbits. E.g. on Relays they say "not centralized, anyone can spin them up". They mention a biz model and multiple others in the works for the future. See: social.coop/@smallcircles/1118

7 February at 7:22 | Open on social.coop
small circle πŸ•Š in calmness

@jonny

I suspect they're still on a gradual roll-out strategy, not fully public.

Their site is still quite tech-focused, not an end-user product presentation. That may be because they wanna build an ecosystem for many of the complex bits of the architecture. To learn yet another lesson from other protocols: have solid libs, frameworks and tools in place to make solution designers happy.

And keep the lead, of course.

Phone no. signup. Another deliberate friction, to avoid unmanageable influx?

7 February at 7:29 | Open on social.coop
jonny (good kind) replied to small circle πŸ•Š in calmness

@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."

@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?

7 February at 8:36 | Open on neuromatch.social
small circle πŸ•Š in calmness replied to jonny (good kind)

@jonny

You're right. Thx btw for drawing attention to the paper.. I missed it on the HN thread. Wonder what Martin's connection is to BS.

I am as suspicious as most people wrt their commercial strategy and biz models, esp. given their VC funding.

So am speculating a bit around that, plus noticing stuff that may give them an advantage in uptake wrt other protocols esp. the fedi. Less focused on the technical nitty gritty.

Imagining a careful dance and rollout and decentralized biz experiment.

7 February at 8:46 | Open on social.coop
small circle πŸ•Š in calmness replied to small circle πŸ•Š in calmness

@jonny

Oh, btw just see that there's another HN discussion, this one related to the paper directly: news.ycombinator.com/item?id=3

7 February at 9:02 | Open on social.coop
maegul

@jonny

Potentially interesting / relevant thread on bsky: bsky.app/profile/bnewbold.net/

Signals here are that as a relay is basically a crawler + firehose, interop between relays is up to PDSs and AppViews and whether they allow/disallow a relay to crawl and consume/ignore a relay's firehose.

The bsky dev here is saying portability and sync between "new" relays *should* be fine.

Doesn't change your analysis about revenue streams, but makes indie spaces on ATProto seem viable.

@jonny

Potentially interesting / relevant thread on bsky: bsky.app/profile/bnewbold.net/

Signals here are that as a relay is basically a crawler + firehose, interop between relays is up to PDSs and AppViews and whether they allow/disallow a relay to crawl and consume/ignore a relay's firehose.

8 February at 5:28 | Open on hachyderm.io
jonny (good kind)

@maegul
Right. Portability is a red herring though. Its effectively meaningless - who cares if i can move my website host. Who cares if its technically possible to block google from crawling me if everyone i know can only find me through that. Worse, if they can only find me through something that doesnt tell anyone where it gets its websites from. What benevolent organization has the resources to crawl everything without ulterior motive, and again how would i even know? If we organize a mass movement away from the main relay because its downright dangerous to have everything public, we would also need to make that relay break the protocol to be private access to similarly safe feed generators and app views, host our own PLC resolver - breaking the chain that makes migration possible, even if i still technically hold the git repo with the right hash, they own the means of finding it.

It all seems nice until you think about how any of it would actually play out. It would be cool to be wrong, id love to see a web utopia spring up from a platform billionaires pocket change, it would be such sweet irony. but seeing the same focus on account portability trotted out again and again without answering any of the hard questions keeps demonstrating how shallow this pipe dream really is. Moving accounts on the fedi is too hard, true, but to still think thats the main barrier and the answer being to give me literally only that and my ability to shop for a new algorithmic slop bucket as agency is just demonstrably wrong the second you think twice about it.

App views invert identity, and thats sort of interesting for a minute - instead of me subscribing to a platform, the platform subscribes to me. Except wait wasnt a series of platforms that mine all my data to serve me targeted shit the whole problem in the first place? Why is it compelling to require any indie app view to require me to surrender literally all my data to something they literally and uncritically call the firehose to be viable? Even if the indie app view is beautiful and lovely, it structurally depends on Sidechannel Information Leaks As A Service where now instead of a single platform having to win my trust to harvest my data, to merely exist online i literally must allow literally everyone to harvest it so i can have the privilege of them telling me what to look at.

They talk about how many thousands of algorithms have been created, but take a look at the list of them, it shows you how many people subscribe to them, sorted by popularity, descending. Compare that to the number of accounts on bluesky. Try and find the source code for the most popular feeds. If you can, are they doing anything more interesting than a manually curated list of accounts or posts that contain a hashtag? Try and find an algo that does actual account-level recommendation. Are there any? Youll find a handful of open source ones that have shut down. Try and run one. What happens? Who has the resources to run something like that? For how many accounts? Sample the firehose for a week, including all your feeds. Compare the number of accounts and posts that show up there to the number of accounts active in the firehose. If it really worked, youd expect to see a lot of different algorithms serving a lot of different posts from a lot of different people to a lot of different people. Evaluating how far that is from reality is left as an exercise to the reader.

And thats the network working as designed - saying nothing about the intrinsic impossibility of safety given the identity model.

I find very little of it compelling. I was interested in lexicons until i saw how they are used in practice as a wildly ineffective and repetitive API spec. I was interested in the use of DNS and DIDs for lightweight identity beacons until i saw how almost a year (?) later there are no viable plans to replace PLC with anything but Identity As A Service. I was interested in the PDS as a signed data store until i saw how it was only discoverable and useful by being crawled by a single public relay. Its a hodgepodge of half finished ideas that could be cool if any critical feedback would actually affect the design.

As i always say when i talk about this, id love to be wrong, and if it turns out to be really cool ill happily join.
#bluesky #atproto

@maegul
Right. Portability is a red herring though. Its effectively meaningless - who cares if i can move my website host. Who cares if its technically possible to block google from crawling me if everyone i know can only find me through that. Worse, if they can only find me through something that doesnt tell anyone where it gets its websites from. What benevolent organization has the resources to crawl everything without ulterior motive, and again how would i even know? If we organize a mass movement...

8 February at 6:20 | Open on neuromatch.social
Ben Lockwood, PhD

@jonny bluesky is starting from the premise that it needs to make money, correct? At least eventually. Seems like that incentive always explains any bad faith engineering

6 February at 15:52 | Open on fediscience.org
Eth

@jonny similarly, AFAICT they talk about making it easy to change PDS, but not how re-keying & re-signing everything is supposed to work, given that the recommendation is that private keys are held by the app service? to move PDS you need to change your DID document, but the keys needed to change the DID document are held by the PDS, leaving most users just as at-risk to sudden shutdowns, uncooperative admins, etc?

6 February at 20:46 | Open on chaos.social
Kevin Marks

@jonny what the design reminds me of is Google Wave - a lot of cleverness in the lower layers, and then genuinely terrible choices about object inheritance and byte offsets into text for links that make interop really annoying.

7 February at 9:02 | Open on xoxo.zone
Kuba Suder β€’ @mackuba.eu on πŸ¦‹

@KevinMarks @jonny We've had quite a few discussions about the byte offsets, but as I understand the main issue and the origin of this is JavaScript and how it uses UTF-16 (or "WTF-16") instead of UTF-8 for strings internally, and to get UTF-8 you need to convert it first, and at that point it's easier to work with bytes than Unicode code points - and since being able to use the protocol from JavaScript somewhat easily is kinda important, it was considered the least bad solution...

8 February at 1:20 | Open on martianbase.net
Tim Chambers
Irenes (many)

@jonny for what it's worth, we entirely agree with this part of your analysis (we haven't read the rest yet) and this is how we've felt about it from the beginning. the invisible hand has a history of giving people from marginalized backgrounds the finger, and we see no reason to expect differently in this context.

6 February at 19:50 | Open on mastodon.social
Go Up