> why is a centralized “burn” able to completely prevent me from interacting with people using Bluesky?
Presumably to stop credential reuse attacks on Bluesky itself?
Bluesky is one instance and they should enforce security on that instance. If you use a previously burnt ID, they have no way to tell it's you (indeed that's the whole point!)
I've done some work in the DID space. Not really a fan, and the space is full of half working implementations like this post documents.
There are different types of attacks possible though, most broadly you can divide them into "design holes" and "implementation holes". This seems to be about preventing a design hole, and those you need to prevent with architecture/design, you can't just fix those once the implementation and documentation is done.
> I've done some work in the DID space. Not really a fan, and the space is full of half working implementations like this post documents.
I would be curious to hear your broader thoughts. I haven't actually worked with did but I did read through a large portion of the spec back before bluesky first launched. My impression was that it's a genuinely useful direction to go in but the standard seemed verbose and overly complex to me given what it does. But then that's not an uncommon thought to have about something you don't properly understand. (TBF I also feel that way about a lot of standards that I do understand reasonably well so perhaps I'm the problem here.)
Not the parent poster, but the cynical impression I had from very early on for DID is that almost all of its complexity and much of the reason its space is full of half-working implementations rather than working ones is pretty obviously because it was designed to be an abstraction layer on top of "namecoins" and when the "namecoin" dependency was removed (for good reasons) there were not enough good ideas for what to replace that dependency with, sort of intentionally leaving what was left of the design in a sort of guaranteed perpetual state of half-implementation (including implementations based on some of the original "namecoin" ideas).
Much of DID itself is basically a standardization of the idea behind Keybase, ie, using control of a private key as a marker of identity.
This in itself is a pretty good idea (with some bad usability, but at least technically interesting)
DID falls over because it has a bad interop story, and much of it is based on crypto-based implementations (again, technically interesting but bad usability plus a monetary incentive to go after your details).
So suppose someone had a domain and a Bluesky identity associated with it. They deleted their account for whatever reason and let the domain expire. Later, someone else bought the domain, but since it had a previously-deleted account associated with it, it's permanently banned from identifying a Bluesky account ever again. Do you really think that's adequate?
I really like the ActivityPub approach more. There, if a domain changes hands, so potentially do all accounts associated with it. An account can be permanently deleted by sending a Delete{Person} activity to the network, but that doesn't prevent an account with the same username from being created again.
I agree that the ATProto situation described is ridiculous. However the situation with AP is not nearly as cheery as you describe. The protocol commits the exact same sin, essentially baking in the assumption that any given ICANN DNS entry will only ever be controlled by a single entity for all time. Real world implementations then associate keys with nodes using a TOFU scheme (which makes perfect sense) and if the domain ever changes hands (thus the key changes) all sorts of stuff breaks in frustrating ways.
Even worse are the assumptions that a given node will never migrate between DNS entries or appear at multiple DNS entries simultaneously. In practice this comes up all the time because people regularly stand a node up on a cheap VPS using an off the cuff domain. Then some time later they either forget to renew the domain or have second thoughts about it.
While I appreciate that it's always easy to criticize things in hindsight there's no lack of aggravating real world problems related to the way AP models identity.
I’m trying to understand how “burning” works here. If I understand correctly:
1. Someone has a domain, example.net. They set up a did:web:example.net, and a handle @example.net pointing to it.
2. They deleted their account and let the domain expire.
3. I register the domain, but can’t set up did:web:example.net again. But I assume I can still set up did:web:mynewdid.example.net, and then point @example.net to that DID instead.
I won’t have access to the original account, but I will be able to use that domain as a handle for a new one.
(This, of course, is only my assumption. I’ve been able to switch my domain from one did:plc to another, but I haven’t tried it for did:web.)
If you mean the buggy and badly documented process, sure.
But the complaint it builds up to is that instance-wide bans can ruin you when there are super big instances, and that's not something that can be fixed.
I see this as a mistake caused by really poor docs that should explain what to do and warn not to do the thing this person did.
It's also true that big instances have a lot of power and it's going to require a lot of growth of alternative instances to fix that, which will take time. At least it's possible, though. It's an intended outcome.
We should only build peer to peer social protocols.
Websites and communities should simply sample from the swarm and make it easy for non-technical users to post and consume. They should be optional and not central points of failure (or control).
{Twitter, YouTube, Reddit, Instagram, TikTok, WhatsApp, Discord} should work like {Email, BitTorrent, PGP}.
Bluesky and Mastodon are the wrong architecture.
The web, fancy javascript UI/UX, and microservices shouldn't be the focus. The protocol should be the focus.
A fully distributed protocol would dictate the solution to this exact problem.
Bluesky is designed the way it is because of scale. How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping? Bsky is designed so that the microservices themselves can be decentralized and so multiple different types of apps can be built on the same protocol/infra.
Obviously, it’s early days, and hopefully there is even more experimentation in the p2p space. But atproto architecture is a very fair experiment in this space. I can store my data on my own server, use a client app I wrote, subscribe to a specific aggregation/feed service I prefer, use the moderation list I want… all while still being connected to the larger protocol & network. It’s pretty neat.
So I agree with you that they should work like email -- but I've always said that Mastodon is better because it is like email; aka the power is in the nodes.
What do you think is wrong about Mastodon? Genuinely curious because I also am super skeptical that ATProto brings anything that we really need.
Email is the prime example of federated communication. From protocol inception to painful expansion and aging protocol all until corporate apropriaton. But I still think federation is the way forward, absolute centralisation is bad I'll let you figure why, but absolute decentralization is also bad, limitations due to its nature, unusual working for most users... Meanwhile federation is right in the middle, and users already use it with email without even noticing!
We don't need large scale social networks in the first place. The Discord model of small communities is the way forward. Keep groups small enough for natural human social rules to apply. Slows down global dissemination of information for sure, but that's what the news is for, and anything important will eventually travel between communities anyway.
I don't disagree, but I'm baffled that, with P2P as your preferred outcome, your orientation toward federated infrastructure is one of opposition rather than support. It feels philosophically confused to me; they're your natural allies, they're a step in your preferred direction and they have an instance of real world success (well, to a degree) which is important. Whatever theory of change motivates this form of criticism of federated services can't be one that's, say, intentional or strategic about outcomes. It feels more first principles.
One might also ask why P2P thesis statements only ever show up deep in the weeds in comment sections in response to the fediverse when logically speaking they would make just as much sense if not more in response to, say, any post about Facebook as a company or social media writ large, or business news about acquisitions, consolidation of web infrastructure into fewer hands, enshittification, or escalations of control over platforms.
Again, I'm fully on board with the dream of P2P but it feels like Buzz Aldrin criticizing Neil Armstrong for not doing enough to bring humanity into the space age.
Unfortunately, the swarm is 99.99999% advertisements for penis enlargement pills. How can a P2P system filter them out? A federated system relies on each admin to filter them out. A centralised system does even better, relying on a single dictator to filter them out. A P2P system requires every user to filter every spam message, together consuming far more effort than the spammer needed to send it.
fair enough, the did:web flows are not documented even for technical atproto developers, and there needs to be a self-serve way to heal identity/account problems elsewhere in the network (the "burn" problem).
I do think that did:plc provides more pragmatic freedom and control than did:web for most folks, though the calculus might be different for institutions or individuals with a long-term commitment to running their own network services. But did:web should be a functional alternative on principle.
I'm glad that the PDS was easy to get up and running, and that the author was able to find a supportive community on discord.
Thanks for responding, Brian. While I don't agree with a lot of decisions Bluesky and the broader ATProto community have made, I am very excited that progress towards real decentralization is happening; Blacksky's app view, for instance, was the trigger for me to try to finally try to set up an account. I would love to see more of a focus on the parts of the system that make this difficult, so that myself and other people who are tired of coupling ourselves to centralized systems can participate. It's hard for me to trust that this is the direction the community is interested in moving, but I hope you prove me wrong.
Because of your blog post I went through the process of setting up a did:web account myself this afternoon, and it was painful. Eg, I found a bug in our Go SDK causing that "deactivated" error (https://github.com/bluesky-social/indigo/pull/1281). I kept notes and will try to get out a blog post and update to 'goat' soon.
We've also been making progress on the architecture and governance of the PLC system. I don't know if those will assuage all concerns with that system immediately, but I do think they are meaningful steps in reducing operational dependency on Bluesky PBC.
You can host your own instance, but resolving forks is not self-authenticating and requires some central trust (because of the 72 hour rollback window for higher priority rotation keys). Not counting that, you could essentially run your own fully independent instance where the worst that could happen is that you lack some newer updates to people's did documents (but anyone can upload them since they're self-authenticating). Some people do run their own instances for caching reasons, but these just ingest operations from the official one.
In terms of "credible exit", if the community at large could decide to move to a different PLC host, it would be technically possible for everyone to switch over.
Worth mentioning that Bluesky PBC is relinquishing legal control over the PLC and spinning it off into its own entity based in Switzerland.[1]
I wrote a Bluesky app in preparation for a client project. ATProto is over-engineered for my purposes, though probably justifiably carefully engineered for the purposes of a big social Twitter-like thing. But since I didn't have to do the engineering, so what? It's a very solid platform for many kinds of multi-user information-sharing systems.
This article does give me the impression that I should make and use more test accounts than I currently do when mucking around with ATProto/Bluesky.
Indeed, it's a pity that the author placed so much focus on a cool looking font that they forgot to take basic properties like "good readability" into account. Form should follow function, not the other way around.
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
Backseat moderating is also against the guidelines. If you believe the comment needs moderator attention, flag it. It's pretty ironic you can't say this rule without breaking it
I'd like to add to my sibling comments that this blog's design is so atrocious for its readability that it deserves to be called out.
In fact, I'd like for such a comment to be at the top here, so that I can decide to avoid following the link until I have read enough comments to determine whether it's worth it.
Complexity acts like a gate. When we make the code too hard to understand, we are telling regular people that they are not allowed to participate. True ownership of your data is only possible if you can actually afford to host it yourself. We should focus on making things simple enough for anyone to use.
Can you clarify - are you implying that BlueSky team made protocol hard on purpose, in order to "tell regular people that they are not allowed to participate"?
No, OP is saying that they have over-engineered the protocol, and that this acts as an *effective* barrier to participation, regardless of whether it was intended or not. Bluesky's protocol is focused on twitter-scale use-cases, where every node in the network needs to be able to see and process every other event from every other user in able to work properly. This fundamentally limits the people who can run a server to only the people who are able to operate at the same scale.
My experience using ATProto is that it is somewhat like how the nascent blockchain apps were when they first came out: there's no written content that is viable. Instead, you're supposed to use ephemeral conversations and read a widely disparate set of notes in order to use it. In the end, the upshot of all this is that you get to use a slightly worse form of Twitter - which is already rather unpleasant to use for me because there's a lot of rage content there.
Microblogs are fun, and very often I can't justify a whole blog post, but I have seen that others just post their thoughts intermingled and it makes me wonder if perhaps that is what I should do. There's not that much utility to the wide audience anyway. Talking to people who understand you is much nicer anyway.
Blockchain is still like that. Today I am setting up a blockchain node. The chain is actually two chains that recursively depend on each other. The docs say to start one of them first and wait for it to fully sync. It prints a timeout error for every block, saying the other chain node software was unreachable, and is estimated to catch up to current block height in about 200 years, which can't be right. Maybe I need to run both nodes at once contrary to the explicit instructions in the docs which say not to do so.
I wouldn't be surprised if half of all blockchains were vulnerable to some kind of trivial double–spend attack because it's not possible that all the complexity has eyes on it.
Edit: you're supposed to download a 2GB JSON file containing the state as of the last migration.
The normal way to set up most blockchain nodes these days is to rsync someone else's node's working directory. Obviously this is worthless as far as a decentralised and trustless system goes.
Im sorry this is stupid. If you have to rely on one organization or a chain of systems where there is single point that can be effected, If your data does not live on your machine (PDS) then you are not in control.
Decentralization is the new Centralization. For information ownership, the protocol needs to be distributed.
Bluesky also randomly bans new accounts saying they violated the ToS. Like right after signup before you do anything. It says you'll receive an email with details (never happens) and offers a form to appeal. The form goes nowhere and you never hear anything again. This happened to me a couple months ago so it's probably still an issue. It seems more like sloppy, careless engineering than malice, however.
Happened to me a few weeks ago. I replied/filled out the form, and after a day it was unlocked. Seems to be very hit and miss, maybe depending on who is seeing your replies? Regardless, definitely a sucky issue...
This happened to me and I made a new account, which isn't banned yet but it could be any day now if they detect "ban evasion". Why I don't trust centralised systems.
Key management shouldn't have to be difficult. Consider another open microblogging protocol nostr. There a keypair is crucial to the experience and every client automatically generates one if you don't have one to import.
I think this part of the UX is just being neglected by bluesky.
Well-deserved criticism. The colors, too. Without reader mode, this is the equivalent of someone shining a high beam into your eyes at night while trying to communicate with you.
This is the kind of thing I click away from unless there's a strong outside signal that the content is worth engaging with.
I hope the author reconsiders these stylistic choices. I'm sure they lose readers because of it.
This continues to confirm for me that there's nothing particularly valuable about ATProto, and that some of the percieved "flaws" in models like Mastodon's model are features just as much as bugs.
Honestly, this is making me go further in the other direction, can we just do "twitter but owned by a trust" or something?
Not exactly—a PBC is allowed to "balance" shareholder profit with "stakeholder interests. But at the end of the day, the money is still coming from the shareholders, and they're still looking for a return. They're required to be transparent, but that's about it. And there aren't really any penalties for not complying either.
The bigots and sociopaths will need a place to exercise their freeze peach. Groups that don't want to be involved with that rancor need a way to evict such people when they are disruptive. Wikipedia hangs on with its NPOV policy. You can't do that on centralized open fora where opinion is the currency of the realm.
No we can't. Beacuse at anytime people like Elon Musk can come in and mess everything up. If all of your data is in someones server you are one ban away from becoming noone. Of course that is still true with atproto since majority of users are on bluesky PDS's. But the whole tech is being designed in such a way to prevent such issues while still looking and acting qs traditional social media.
What you're saying is: working outside of centralization is a choice. did:plc is a centralized database controlled by Bluesky.
Bluesky talks a big game about decentralization when it's extremely centralized. Everyone uses the centralized did:plc because it's the one way to really make it function. Until very recently, everyone used the centralized Bluesky AppView - and even now, well over 99% do. Bluesky will say things like "the protocol is locked open", but Bluesky could decide to shut off their firehose at anytime (leaving third parties cut off) and could decide to stop taking incoming data from third parties (leaving anyone on non-Bluesky servers cut off from basically everyone).
In a lot of ways, Bluesky is more like Twitter a decade or so ago. It offers APIs that third parties can use to build off of - but at any time, Bluesky could shut down those APIs. Back then, you could read the Twitter firehose and store the tweets and create your own app view with your own front-end if you wanted. Tweets would need to be sent to the Twitter APIs, but that's not really different than your third-party PDS server sending them to Bluesky if you want anyone else to read them.
You aren't open if someone controls the vast majority of a system because at any time they can decide "why are we doing this open thing? we could probably force the <1% of people elsewhere to migrate to our service if we cut off interoperability." Google Talk (GChat) offered XMPP federation and a lot of people bought into the platform because it was open. At some point, Google realized that the promise of openness had served its purpose and closed it off.
And it's important to think about the long-run here. Twitter was that benevolent dictator for a long time. Bluesky is still early and looking to grow - when they want people building off their system, giving them engagement, ideas, and designs they can copy. We're around year-5 of Bluesky. A decade from now after Bluesky builds its popularity on the back of "we're open and decentralized" while making decentralization extremely difficult, will that change? If Bluesky gets to a few hundred million users and then a third party starts looking like a potential threat, maybe they'll cut that off before they have genuine competition.
Maybe that won't happen with Bluesky. Maybe their investors won't care about the potential for a pay day. But if they have control (either through centralization like did:plc or by controlling the vast majority of the network), there will always be the potential for them to break interoperability. If they start monetizing Bluesky, why should they keep hosting, processing, and serving all that data for third party clients they can't monetize? Why shouldn't they stop federating with third parties before a third party becomes competition?
It is in a sense by design because the focus was creating a decentralize-able/federate-able protocol and infrastructure that can scale more or less indefinitely first and foremost, community second.
The community is working on actually decentralising the network now that things mostly "just work" (assuming you are using did:plc/generally a happy path user).
- Building out PDS communities that are trusted takes time and nowadays there's a few outside of bluesky PBC (one or two big ones and a bunch of smaller ones). People are eager to move off because a lot of users really really don't like bluesky PBC leadership but it's a matter of waiting for these third party communities to reach critical mass.
- Relay infra is already pretty much decentralised. Lots of people still rely on the main relay but it's trivial to use a third party relay and there's more of them than you can count.
- There are a lot of really high quality third party clients and afaict a lot of users do actually use third party clients but there's basically no metric for tracking these stats.
- Appviews are expensive currently and there's work on making them easier to host but there's already one "full" alternative appview for bluesky.
- There are a lot non-bluesky apps/services that are genuinely high quality experiences and they are gaining their own communities.
The main technical barrier to true decentralisation outside of improving UX is introducing other did:methods and/or spreading trust of did:plc across the community (ex: clustered via raft or paxos across major operators) but there's just not a reason to pursue this over the other fires that need fighting in the ecosystem right now (and keeping did diversity low reduces another source of complexity the space just doesn't need to tackle yet).
--------------
TLDR: it is intentional because the goal is to in order of priorities:
1. get the architecture for eventual decentralisation right.
2. make it exist.
3. make it good.
4. make it easy to use for normal people.
5. build community.
6. focus on decentralisation.
Decentralisation in theory is the first priority but in practice it's the last priority. Being able to decentralise is always the utmost importance but forcing it to happen is not ever the top priority because that's on the community, not on the developers.
> why is a centralized “burn” able to completely prevent me from interacting with people using Bluesky?
Presumably to stop credential reuse attacks on Bluesky itself?
Bluesky is one instance and they should enforce security on that instance. If you use a previously burnt ID, they have no way to tell it's you (indeed that's the whole point!)
I've done some work in the DID space. Not really a fan, and the space is full of half working implementations like this post documents.
But this particular criticism seems unfounded.
It seems backwards to worry about attacks when basic functionality is undocumented/broken.
There are different types of attacks possible though, most broadly you can divide them into "design holes" and "implementation holes". This seems to be about preventing a design hole, and those you need to prevent with architecture/design, you can't just fix those once the implementation and documentation is done.
3 replies →
> I've done some work in the DID space. Not really a fan, and the space is full of half working implementations like this post documents.
I would be curious to hear your broader thoughts. I haven't actually worked with did but I did read through a large portion of the spec back before bluesky first launched. My impression was that it's a genuinely useful direction to go in but the standard seemed verbose and overly complex to me given what it does. But then that's not an uncommon thought to have about something you don't properly understand. (TBF I also feel that way about a lot of standards that I do understand reasonably well so perhaps I'm the problem here.)
Not the parent poster, but the cynical impression I had from very early on for DID is that almost all of its complexity and much of the reason its space is full of half-working implementations rather than working ones is pretty obviously because it was designed to be an abstraction layer on top of "namecoins" and when the "namecoin" dependency was removed (for good reasons) there were not enough good ideas for what to replace that dependency with, sort of intentionally leaving what was left of the design in a sort of guaranteed perpetual state of half-implementation (including implementations based on some of the original "namecoin" ideas).
1 reply →
Much of DID itself is basically a standardization of the idea behind Keybase, ie, using control of a private key as a marker of identity.
This in itself is a pretty good idea (with some bad usability, but at least technically interesting)
DID falls over because it has a bad interop story, and much of it is based on crypto-based implementations (again, technically interesting but bad usability plus a monetary incentive to go after your details).
So suppose someone had a domain and a Bluesky identity associated with it. They deleted their account for whatever reason and let the domain expire. Later, someone else bought the domain, but since it had a previously-deleted account associated with it, it's permanently banned from identifying a Bluesky account ever again. Do you really think that's adequate?
I really like the ActivityPub approach more. There, if a domain changes hands, so potentially do all accounts associated with it. An account can be permanently deleted by sending a Delete{Person} activity to the network, but that doesn't prevent an account with the same username from being created again.
I agree that the ATProto situation described is ridiculous. However the situation with AP is not nearly as cheery as you describe. The protocol commits the exact same sin, essentially baking in the assumption that any given ICANN DNS entry will only ever be controlled by a single entity for all time. Real world implementations then associate keys with nodes using a TOFU scheme (which makes perfect sense) and if the domain ever changes hands (thus the key changes) all sorts of stuff breaks in frustrating ways.
Even worse are the assumptions that a given node will never migrate between DNS entries or appear at multiple DNS entries simultaneously. In practice this comes up all the time because people regularly stand a node up on a cheap VPS using an off the cuff domain. Then some time later they either forget to renew the domain or have second thoughts about it.
While I appreciate that it's always easy to criticize things in hindsight there's no lack of aggravating real world problems related to the way AP models identity.
9 replies →
Just to be clear, this is specific to did:web, did:plc does not have the same downsides (it has different ones).
I’m trying to understand how “burning” works here. If I understand correctly:
1. Someone has a domain, example.net. They set up a did:web:example.net, and a handle @example.net pointing to it.
2. They deleted their account and let the domain expire.
3. I register the domain, but can’t set up did:web:example.net again. But I assume I can still set up did:web:mynewdid.example.net, and then point @example.net to that DID instead.
I won’t have access to the original account, but I will be able to use that domain as a handle for a new one.
(This, of course, is only my assumption. I’ve been able to switch my domain from one did:plc to another, but I haven’t tried it for did:web.)
It's written in anger, but I'm optimistic that this will eventually get fixed, and documenting bad experiences like this will help.
If you mean the buggy and badly documented process, sure.
But the complaint it builds up to is that instance-wide bans can ruin you when there are super big instances, and that's not something that can be fixed.
I see this as a mistake caused by really poor docs that should explain what to do and warn not to do the thing this person did.
It's also true that big instances have a lot of power and it's going to require a lot of growth of alternative instances to fix that, which will take time. At least it's possible, though. It's an intended outcome.
Any system that can ruin a spammer can also ruin someone who isn't a spammer, since the system can't tell the difference.
There's a bug about it, and it's already marked WONTFIX
https://github.com/bluesky-social/atproto/issues/3143
Peer to peer, not federation, is the way forward.
We should only build peer to peer social protocols.
Websites and communities should simply sample from the swarm and make it easy for non-technical users to post and consume. They should be optional and not central points of failure (or control).
{Twitter, YouTube, Reddit, Instagram, TikTok, WhatsApp, Discord} should work like {Email, BitTorrent, PGP}.
Bluesky and Mastodon are the wrong architecture.
The web, fancy javascript UI/UX, and microservices shouldn't be the focus. The protocol should be the focus.
A fully distributed protocol would dictate the solution to this exact problem.
Bluesky is designed the way it is because of scale. How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping? Bsky is designed so that the microservices themselves can be decentralized and so multiple different types of apps can be built on the same protocol/infra.
Obviously, it’s early days, and hopefully there is even more experimentation in the p2p space. But atproto architecture is a very fair experiment in this space. I can store my data on my own server, use a client app I wrote, subscribe to a specific aggregation/feed service I prefer, use the moderation list I want… all while still being connected to the larger protocol & network. It’s pretty neat.
9 replies →
So I agree with you that they should work like email -- but I've always said that Mastodon is better because it is like email; aka the power is in the nodes.
What do you think is wrong about Mastodon? Genuinely curious because I also am super skeptical that ATProto brings anything that we really need.
16 replies →
Email is the prime example of federated communication. From protocol inception to painful expansion and aging protocol all until corporate apropriaton. But I still think federation is the way forward, absolute centralisation is bad I'll let you figure why, but absolute decentralization is also bad, limitations due to its nature, unusual working for most users... Meanwhile federation is right in the middle, and users already use it with email without even noticing!
9 replies →
We don't need large scale social networks in the first place. The Discord model of small communities is the way forward. Keep groups small enough for natural human social rules to apply. Slows down global dissemination of information for sure, but that's what the news is for, and anything important will eventually travel between communities anyway.
8 replies →
I don't disagree, but I'm baffled that, with P2P as your preferred outcome, your orientation toward federated infrastructure is one of opposition rather than support. It feels philosophically confused to me; they're your natural allies, they're a step in your preferred direction and they have an instance of real world success (well, to a degree) which is important. Whatever theory of change motivates this form of criticism of federated services can't be one that's, say, intentional or strategic about outcomes. It feels more first principles.
One might also ask why P2P thesis statements only ever show up deep in the weeds in comment sections in response to the fediverse when logically speaking they would make just as much sense if not more in response to, say, any post about Facebook as a company or social media writ large, or business news about acquisitions, consolidation of web infrastructure into fewer hands, enshittification, or escalations of control over platforms.
Again, I'm fully on board with the dream of P2P but it feels like Buzz Aldrin criticizing Neil Armstrong for not doing enough to bring humanity into the space age.
3 replies →
Unfortunately, the swarm is 99.99999% advertisements for penis enlargement pills. How can a P2P system filter them out? A federated system relies on each admin to filter them out. A centralised system does even better, relying on a single dictator to filter them out. A P2P system requires every user to filter every spam message, together consuming far more effort than the spammer needed to send it.
23 replies →
fair enough, the did:web flows are not documented even for technical atproto developers, and there needs to be a self-serve way to heal identity/account problems elsewhere in the network (the "burn" problem).
I do think that did:plc provides more pragmatic freedom and control than did:web for most folks, though the calculus might be different for institutions or individuals with a long-term commitment to running their own network services. But did:web should be a functional alternative on principle.
I'm glad that the PDS was easy to get up and running, and that the author was able to find a supportive community on discord.
Thanks for responding, Brian. While I don't agree with a lot of decisions Bluesky and the broader ATProto community have made, I am very excited that progress towards real decentralization is happening; Blacksky's app view, for instance, was the trigger for me to try to finally try to set up an account. I would love to see more of a focus on the parts of the system that make this difficult, so that myself and other people who are tired of coupling ourselves to centralized systems can participate. It's hard for me to trust that this is the direction the community is interested in moving, but I hope you prove me wrong.
Thanks for the response Nora.
Because of your blog post I went through the process of setting up a did:web account myself this afternoon, and it was painful. Eg, I found a bug in our Go SDK causing that "deactivated" error (https://github.com/bluesky-social/indigo/pull/1281). I kept notes and will try to get out a blog post and update to 'goat' soon.
We've also been making progress on the architecture and governance of the PLC system. I don't know if those will assuage all concerns with that system immediately, but I do think they are meaningful steps in reducing operational dependency on Bluesky PBC.
I'm not too familiar, but isn't there a way to host your own did:plc auth server?
You can host your own instance, but resolving forks is not self-authenticating and requires some central trust (because of the 72 hour rollback window for higher priority rotation keys). Not counting that, you could essentially run your own fully independent instance where the worst that could happen is that you lack some newer updates to people's did documents (but anyone can upload them since they're self-authenticating). Some people do run their own instances for caching reasons, but these just ingest operations from the official one.
In terms of "credible exit", if the community at large could decide to move to a different PLC host, it would be technically possible for everyone to switch over.
Worth mentioning that Bluesky PBC is relinquishing legal control over the PLC and spinning it off into its own entity based in Switzerland.[1]
[1] https://docs.bsky.app/blog/plc-directory-org
No, did:plc is centralised, not federated or anything. The whole ecosystem relies on a server at Blue Sky PBC
2 replies →
I wrote a Bluesky app in preparation for a client project. ATProto is over-engineered for my purposes, though probably justifiably carefully engineered for the purposes of a big social Twitter-like thing. But since I didn't have to do the engineering, so what? It's a very solid platform for many kinds of multi-user information-sharing systems.
This article does give me the impression that I should make and use more test accounts than I currently do when mucking around with ATProto/Bluesky.
"View -> Page Style -> Basic Page Style" is required to read any of the text.
Indeed, it's a pity that the author placed so much focus on a cool looking font that they forgot to take basic properties like "good readability" into account. Form should follow function, not the other way around.
> Form should follow function, not the other way around.
According to whom? It's their personal website, they're allowed to place value on whatever they want.
11 replies →
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
https://news.ycombinator.com/newsguidelines.html
Backseat moderating is also against the guidelines. If you believe the comment needs moderator attention, flag it. It's pretty ironic you can't say this rule without breaking it
2 replies →
I wish there was a rule against rule lawyering. Those comments are way more annoying than gp. (queue recursive replies)
I'd like to add to my sibling comments that this blog's design is so atrocious for its readability that it deserves to be called out.
In fact, I'd like for such a comment to be at the top here, so that I can decide to avoid following the link until I have read enough comments to determine whether it's worth it.
Or just toggle reader view (Firefox).
I don't have any issues with it but I've been computing since the 8 bit days which basically looked exactly like that :)
I wonder if it renders differently for different people.
Complexity acts like a gate. When we make the code too hard to understand, we are telling regular people that they are not allowed to participate. True ownership of your data is only possible if you can actually afford to host it yourself. We should focus on making things simple enough for anyone to use.
Can you clarify - are you implying that BlueSky team made protocol hard on purpose, in order to "tell regular people that they are not allowed to participate"?
No, OP is saying that they have over-engineered the protocol, and that this acts as an *effective* barrier to participation, regardless of whether it was intended or not. Bluesky's protocol is focused on twitter-scale use-cases, where every node in the network needs to be able to see and process every other event from every other user in able to work properly. This fundamentally limits the people who can run a server to only the people who are able to operate at the same scale.
3 replies →
My experience using ATProto is that it is somewhat like how the nascent blockchain apps were when they first came out: there's no written content that is viable. Instead, you're supposed to use ephemeral conversations and read a widely disparate set of notes in order to use it. In the end, the upshot of all this is that you get to use a slightly worse form of Twitter - which is already rather unpleasant to use for me because there's a lot of rage content there.
Microblogs are fun, and very often I can't justify a whole blog post, but I have seen that others just post their thoughts intermingled and it makes me wonder if perhaps that is what I should do. There's not that much utility to the wide audience anyway. Talking to people who understand you is much nicer anyway.
ATProto can be used be used for a lot more than just microblogs
https://tangled.org/
So can ActivityPub, as far as I know. Most of the social coding projects agreed upon a shared vocabulary: https://codeberg.org/fediverse/delightful-fediverse-experien...
That is a really cool project, thanks for posting
Blockchain is still like that. Today I am setting up a blockchain node. The chain is actually two chains that recursively depend on each other. The docs say to start one of them first and wait for it to fully sync. It prints a timeout error for every block, saying the other chain node software was unreachable, and is estimated to catch up to current block height in about 200 years, which can't be right. Maybe I need to run both nodes at once contrary to the explicit instructions in the docs which say not to do so.
I wouldn't be surprised if half of all blockchains were vulnerable to some kind of trivial double–spend attack because it's not possible that all the complexity has eyes on it.
Edit: you're supposed to download a 2GB JSON file containing the state as of the last migration.
The normal way to set up most blockchain nodes these days is to rsync someone else's node's working directory. Obviously this is worthless as far as a decentralised and trustless system goes.
Nice to meet a third person who both works with blockchain and understands distributed systems ;)
>you get to use a slightly worse form of Twitter
The protocol can support all sorts of other social networks. People are building things akin to instagram, tiktok, medium, allrecipies, etc
I'm building a place review system.
Is there an advantage to using this protocol instead of a more application–specific one? Perhaps the shared identity?
1 reply →
Im sorry this is stupid. If you have to rely on one organization or a chain of systems where there is single point that can be effected, If your data does not live on your machine (PDS) then you are not in control.
Decentralization is the new Centralization. For information ownership, the protocol needs to be distributed.
Bluesky also randomly bans new accounts saying they violated the ToS. Like right after signup before you do anything. It says you'll receive an email with details (never happens) and offers a form to appeal. The form goes nowhere and you never hear anything again. This happened to me a couple months ago so it's probably still an issue. It seems more like sloppy, careless engineering than malice, however.
Happened to me a few weeks ago. I replied/filled out the form, and after a day it was unlocked. Seems to be very hit and miss, maybe depending on who is seeing your replies? Regardless, definitely a sucky issue...
This happened to me and I made a new account, which isn't banned yet but it could be any day now if they detect "ban evasion". Why I don't trust centralised systems.
"Because I use NixOS, this was very easy."
First time I've heard someone say that
"I use NixOS btw"
Looks like the author solved some issues but didn‘t document them as part of this blogpost. A shame.
> Because I use NixOS
feels like the new "btw i use arch"
Key management shouldn't have to be difficult. Consider another open microblogging protocol nostr. There a keypair is crucial to the experience and every client automatically generates one if you don't have one to import.
I think this part of the UX is just being neglected by bluesky.
OMG that website's font choices, good god, my poor eyes
Well-deserved criticism. The colors, too. Without reader mode, this is the equivalent of someone shining a high beam into your eyes at night while trying to communicate with you.
This is the kind of thing I click away from unless there's a strong outside signal that the content is worth engaging with.
I hope the author reconsiders these stylistic choices. I'm sure they lose readers because of it.
This continues to confirm for me that there's nothing particularly valuable about ATProto, and that some of the percieved "flaws" in models like Mastodon's model are features just as much as bugs.
Honestly, this is making me go further in the other direction, can we just do "twitter but owned by a trust" or something?
Isn't that literally Bluesky? A PBC must act in the public interest.
Not exactly—a PBC is allowed to "balance" shareholder profit with "stakeholder interests. But at the end of the day, the money is still coming from the shareholders, and they're still looking for a return. They're required to be transparent, but that's about it. And there aren't really any penalties for not complying either.
Twitter but run by a bunch of NGO PMCs sounds even worse than twitter.
The bigots and sociopaths will need a place to exercise their freeze peach. Groups that don't want to be involved with that rancor need a way to evict such people when they are disruptive. Wikipedia hangs on with its NPOV policy. You can't do that on centralized open fora where opinion is the currency of the realm.
No we can't. Beacuse at anytime people like Elon Musk can come in and mess everything up. If all of your data is in someones server you are one ban away from becoming noone. Of course that is still true with atproto since majority of users are on bluesky PDS's. But the whole tech is being designed in such a way to prevent such issues while still looking and acting qs traditional social media.
The authors’ difficulty is legitimate and real, but there are less than 50 functioning did:web identities total on the planet.
Working outside of did:plc is a choice - this project is on the very ragged, least baked edge of Atmosphere development.
> Working outside of did:plc is a choice
What you're saying is: working outside of centralization is a choice. did:plc is a centralized database controlled by Bluesky.
Bluesky talks a big game about decentralization when it's extremely centralized. Everyone uses the centralized did:plc because it's the one way to really make it function. Until very recently, everyone used the centralized Bluesky AppView - and even now, well over 99% do. Bluesky will say things like "the protocol is locked open", but Bluesky could decide to shut off their firehose at anytime (leaving third parties cut off) and could decide to stop taking incoming data from third parties (leaving anyone on non-Bluesky servers cut off from basically everyone).
In a lot of ways, Bluesky is more like Twitter a decade or so ago. It offers APIs that third parties can use to build off of - but at any time, Bluesky could shut down those APIs. Back then, you could read the Twitter firehose and store the tweets and create your own app view with your own front-end if you wanted. Tweets would need to be sent to the Twitter APIs, but that's not really different than your third-party PDS server sending them to Bluesky if you want anyone else to read them.
You aren't open if someone controls the vast majority of a system because at any time they can decide "why are we doing this open thing? we could probably force the <1% of people elsewhere to migrate to our service if we cut off interoperability." Google Talk (GChat) offered XMPP federation and a lot of people bought into the platform because it was open. At some point, Google realized that the promise of openness had served its purpose and closed it off.
And it's important to think about the long-run here. Twitter was that benevolent dictator for a long time. Bluesky is still early and looking to grow - when they want people building off their system, giving them engagement, ideas, and designs they can copy. We're around year-5 of Bluesky. A decade from now after Bluesky builds its popularity on the back of "we're open and decentralized" while making decentralization extremely difficult, will that change? If Bluesky gets to a few hundred million users and then a third party starts looking like a potential threat, maybe they'll cut that off before they have genuine competition.
Maybe that won't happen with Bluesky. Maybe their investors won't care about the potential for a pay day. But if they have control (either through centralization like did:plc or by controlling the vast majority of the network), there will always be the potential for them to break interoperability. If they start monetizing Bluesky, why should they keep hosting, processing, and serving all that data for third party clients they can't monetize? Why shouldn't they stop federating with third parties before a third party becomes competition?
If Bluesky wants to be taken seriously they need to invest in decentralization themselves and not leave it as an exercise for the reader.
How many users actually care about decentralization?
1 reply →
Unfortunately most people couldn't care less. Bluesky has been lying about being decentralized since day 1, and yet they have millions of users.
13 replies →
This blog has a man page aesthetic. The problem is I immediately dont want to read it, because i dont like to read man pages.
That's fine but we don't need to know about that. Comment on the article, not on the format in which it is presented.
The article that they are having trouble reading due to its format?
1 reply →
BlueSky has to be centralized right now because the quality of the federated network is too poor right now.
I am not convinced that is not by design.
It is in a sense by design because the focus was creating a decentralize-able/federate-able protocol and infrastructure that can scale more or less indefinitely first and foremost, community second.
The community is working on actually decentralising the network now that things mostly "just work" (assuming you are using did:plc/generally a happy path user).
- Building out PDS communities that are trusted takes time and nowadays there's a few outside of bluesky PBC (one or two big ones and a bunch of smaller ones). People are eager to move off because a lot of users really really don't like bluesky PBC leadership but it's a matter of waiting for these third party communities to reach critical mass.
- Relay infra is already pretty much decentralised. Lots of people still rely on the main relay but it's trivial to use a third party relay and there's more of them than you can count.
- There are a lot of really high quality third party clients and afaict a lot of users do actually use third party clients but there's basically no metric for tracking these stats.
- Appviews are expensive currently and there's work on making them easier to host but there's already one "full" alternative appview for bluesky.
- There are a lot non-bluesky apps/services that are genuinely high quality experiences and they are gaining their own communities.
The main technical barrier to true decentralisation outside of improving UX is introducing other did:methods and/or spreading trust of did:plc across the community (ex: clustered via raft or paxos across major operators) but there's just not a reason to pursue this over the other fires that need fighting in the ecosystem right now (and keeping did diversity low reduces another source of complexity the space just doesn't need to tackle yet).
--------------
TLDR: it is intentional because the goal is to in order of priorities:
1. get the architecture for eventual decentralisation right.
2. make it exist.
3. make it good.
4. make it easy to use for normal people.
5. build community.
6. focus on decentralisation.
Decentralisation in theory is the first priority but in practice it's the last priority. Being able to decentralise is always the utmost importance but forcing it to happen is not ever the top priority because that's on the community, not on the developers.
2 replies →
Nothing will improve unless they force it to decentralize.