Gregory's ServerThere 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.
|
22 comments
  @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...  |
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