Comment by ltjbukem

Comment by ltjbukem 3 days ago

2 replies

View on Hacker News

I think that your description of ATproto relays is a conflation of the role of an AppView (or backend) in ATproto and a Nostr relay. Relays (by default) are not designed to be a permanent archive of content, and are really meant as content streams for backends to ingest and index appropriately. The storage cost is also overestimated, as people have begun to host third-party variants of the Bluesky AppView (which is partially open-source due to its dependence on internal code for some non-essential to microblogging functionality): https://whtwnd.com/futur.blue/3ls7sbvpsqc2w

The note at the end about Bluesky being able to censor, verify and ban users from the protocol is also largely incorrect, with some asterisks as is for a complex system. The Turkish accounts that were censored were hidden from the platform in Turkey via the app's labeler system, which allows for "composable moderation". You can use this system to implement geoblocking in Bluesky clients based on your IP address when you open the app, which is what they did to ban those accounts from being seen in Turkey. The application of labelers (outside of Bluesky's main moderation service which the Bluesky-hosted AppView follows) is client-side, and any client that doesn't want to respect the default geoblocking behaviour (or implement mod labels at all) can just ignore it.

The Politico columnist that was banned from Bluesky has their account taken down from the whole network because their account was hosted on a Bluesky PDS, which could be (somewhat because, again, the default AppView follows a default labeler for displaying content through the AppView's API) bypassed by moving their account to another PDS that isn't operated by Bluesky. If your account was banned from Bluesky while also being on a non-Bluesky PDS, you would still have access to the ecosystem (and a half-working version of Bluesky that is basically a shadowban due to the default client and AppView conflicting with the labeler's takedown action).

Speaking of PDSes, they also do quite a bit more than just store user data. As an user's identity is dependent on a PDS to exist as a proper account, most user actions have to be routed through it to allow applications to store their data on-protocol and to authenticate the user.

The verification system is implemented through a record type (or "Lexicon") that is stored on an account that basically confirms that the record owner has verified the target. The system is also odd in that there are two types of verified accounts, "trusted verifiers" (think Twitter's business verification system) and regular verified accounts. Trusted verifiers are chosen by the client and can verify their own set of accounts, giving them the regular checkmark. Clients that haven't implemented support for the checkmarks or allow users to choose their own trusted verifiers can basically see whatever checkmarks they want, or just disable the system altogether (which is possible in the default client).

How Bluesky uses DIDs are... complicated. ATproto supports two DID methods for accounts, did:web and did:plc. Web DIDs are used mainly for services on the network, but can also be used for regular accounts. PLC is a more complicated system, which becomes quite obvious when you find out the original acronym meaning was "placeholder". PLC is (in regards to the general protocol) not a decentralized system, as its current iteration is a DID document pastebin with authentication and version history. I do think that the method's current centralized status can be mitigated somewhat (synchronization between various directories, then having a consensus system for establishing the validity of the documents' current states), but the system could always be replaced at any point to either incorporate new features or to choose a new model for how documents are publicized.

Sorry for the long read but as you see I've wasted way too much time into reading through developer posts and documentation, had to unload it somehow.

tomgag 2 days ago

Thank you for the detailed reply, your points make sense but many of these are, I think, too technical for the intended audience of my blog post, and do not change my overall impression of BlueSky. I will see if I manage to incorporate some of your points in a more digestible way, but reading the blog post you linked (which I didn't know, thanks) confirms my fears: 18 TB and 200$/month to run an instance which is basically serving one user is... insane? And with a lot of features not supported because closed source. I knew about did:web and did:plc and I agree that a future, better, fully decentralized implementation might possible, but at the current state I don't think BlueSky stands up to its promises compared to, e.g., Mastodon.

Reply View 1 reply
  • ltjbukem 2 days ago

    You're welcome. I understand that a lot of what I've said is technical jargon and nonsense to the average *.bsky.social user but a lot of it can be simply dumbed down to "the client can choose to ignore it" or "get off Bluesky servers, lol?".

    At the risk of sounding like a shill, I would also say that the protocol is much less mature than ActivityPub or Nostr, but the rate of progress that I've seen is pretty rapid (compared to APub at least, Nostr is also a rapidly-developing protocol but its harder for me to track its progress as there's no reliable source for protocol updates that is not on Nostr afaik) and with the active developer community surrounding it I firmly believe that most of these issues will be solved within the next few years at worst. Zeppelin has also progressed on bringing back some of these missing features, as video processing and chat have been introduced to the AppView (albeit proxied through Bluesky's services so it's a moot point).

    There's an important distinction to make between AppViews and an APub instance, which is that AppViews handle solely the application portion of the user experience while APub instances typically manage the entirety of the user's experience. As a result, ATproto users can hop between any AppView without any lock-in to a specific AppView provider as their accounts aren't bound to their existence (which means that anyone can switch from using the Bluesky AppView to the Zeppelin AppView with little difficulty (or any other AppView)), while users on the Fediverse cannot easily do the same (applications can authenticate with a Fediverse account to confirm their identity but there are limits to what you can do, such as federating with the identity of that user). They're also not designed to be closed/single-user instances, mainly because the PDS handles the role of user management and platforming users and is where most of that responsibility is placed at. In regards to active usage, enough moderation controversies have happened with Bluesky Social's policies to the point that a small (at this moment) market has opened for a Bluesky with truly user-controllable moderation, and that Zeppelin will be one of the main products to serve that market. The costs also aren't that large compared to some of the larger Mastodon instances, so for the amount of content that it's storing it could be way worse (mstdn.social saved 180 euros when moving to another server apparently but there's definitely other examples of Mastodon unnecessarily ballooning instance costs as it grows in scale, because it's bloatware compared to what's out there. mstdn.social is also a fraction of the activity size of the ATproto network's output on off-peak hours, so eh).

    I will say that this isn't a core attribute of the Fediverse, the base protocol is only slightly less extensive and modifiable than Nostr as projects like ActivityPods and "nomadic identities" (over a decade old!) exist which can perform a similar role to an ATproto PDS but with the Solid protocol but it's seen little adoption due to the lack of focus towards implementing "next-gen" features like these in the current set of APub server software.

    Reply View 0 replies