Gregory's ServerThey 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.
|
35 comments
 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. 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: https://neuromatch.social/@jonny/110552684614320107 They make repeated allusions to designing the system like the web, but really they designed it like Google  @jon @jonny @jon The "community" was renamed to remove its formal connection with the actual Bluesky biz https://dsocialcommons.org  @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.  @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: https://social.coop/@smallcircles/111885573051096864 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? 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. Oh, btw just see that there's another HN discussion, this one related to the paper directly: https://news.ycombinator.com/item?id=39275203 @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 @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?  @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.  @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...   @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. @jonny also, this part, “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” is crying to repeat Cambridge Analytica. Moreover, it is reinforced in their FAQ as “designed to support public conversations”, which robs author from agency to control their conversation (e.g. quote-posts to toxic communities).  @jonny What do you mean by "PDSes are not dereferenceable by username"? @mackuba @mackuba @jonny more than that, I think there was like 5 did:web's last time I checked  |
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.