I was right about ATProto key management
notes.nora.codes123 points by todsacerdoti 10 hours ago
123 points by todsacerdoti 10 hours ago
> 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.
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.
Just to be clear, this is specific to did:web, did:plc does not have the same downsides (it has different ones).
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.
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.
> How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping?
You design it with those requirements in mind? There’s no fundamental technical limitation at play here.
You use routers as the beefy servers. Unicast, multicast, broadcast.
Unfortunately that means the implementation needs to reach all the way into the network layer.
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.
Yep. Once a system gets too large, its starts to break down and everything you do to make work ends up centralizing the process just like in real life. If you want things to work you keep it small and distributed.
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.
ActivityPub supports a less compelling user experience for many people: you only have a partial view of the network (you won’t see all the replies to the posts of people you follow on other servers), no global search, etc
Technically the internet also doesn't have "global search" but people are able to get along just fine most of the time.
> What do you think is wrong about Mastodon?
The same problems as always. Allow federation and you get...
- federation wars and moderators conducting these wars using their own users as hostages - I left Mastodon years ago when some particularly dumb morons decided to do bitchfights regarding Israel / Palestine. No I'm not interested in your pointless squabble, but I do care when I suddenly don't see posts from a bunch of users without even getting a notification...
- Mastodon-specific, when you move your account from one instance to another (e.g. as response to above-mentioned BS) your followings and followers migrate - but all your posts and media do not
- spam, trolls and griefers abusing the system, up to and including sending around CSAM material that inevitably gets sucked in by your instance, making you liable in the eyes of the law
- security issues. Mastodon has been full of these, no thanks I don't have the time to be constantly on guard lest I be exploited from above-mentioned griefers.
- other instances not giving a flying fuck about moderation or abuse going out from their instances.
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!
People often mention email as an example of federated communication, but the way email works in practice doesn't entirely live up to that ideal. Good luck getting your own self-hosted email server to send emails that actually reach anyone using a major email provider; they'll just be blocked as spam.
In practice, email is much less federated than it seems. A significant proportion of people are just using gmail. You probably don't have to include that many providers to cover a majority of people in the US.
I think federation has promise, but federation in itself is not a solution. Technical approaches do not address the more fundamental issue that, regardless of the mechanics of the system, big players will have more influence on its operation and evolution. Thus we will always need sociopolitical mechanisms to restrict big players.
Federation does at least give you the choice of providers, even a little bit of competition goes a long way to improving a company's behavior.
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.
This isn't, and has never been a hard problem. Just pay for people's attention. People you follow don't have to pay, and make that transitive. Penalize people in your network who propagate spam by increasing the cost to get your attention.
If a scammer, advertiser, or some other form of spammer can get a payout just 1% of the time, they will be willing to pay much more than the average person posting the average tweet.
If you make everything explicitly transactional, you will be left with only people trying to make a profit.
Penis enlargement spam is worth like $0.00000001 per message. Any number higher than that makes them lose money. The real problem is that nobody will post on a social media network where you have to pay to post.
You have the graph of everything you follow, the graph of what they like, second order graphs ...
There are so many heuristics and models you can use to filter.
This is one of the most interesting properties of peer-to-peer networks.
You can run your own ingestion algorithms, and one of the things you can do is set up inbound rules that incorporate micro transactions.
We have to build a lot of infrastructure to make this work, but it seems ideal for a world full of agents and autonomous systems acting on our behalf.
Do the outbound rules of other participants include microtransactions?
And who besides a spammer would pay more than $0 to have their message read by you? If I wrote a blog post about vulnerabilities of blockchains, or how I ran Doom on a pregnancy test, and you don't read it because I'm not paying you, you're losing value, not me. You guarantee an inbox of only spam — but at least you get paid for it.
If you've got great content, I would just follow you. Or someone I follow would follow you, and through the network it would lead to discovery. I want your content, so unless you charge for it, nobody's paying anyone.
If someone wants me to ingest something novel from far outside my network, one way to gain reputation might be to pay a microtransaction fee. I'd be free to choose to set that up as a part of my ingestion algorithm. Or maybe my peers do it, and if they "upvote" the content, I see it.
If my peers start acting poorly and sending spam, I can flag disinterest and my algorithm can naturally start deboosting that part of the network.
With such systems-level control, we should be able to build really excellent tooling, optimization, and statistical monitoring.
Also, since all publications are digitally signed, your content wouldn't have to be routed to me through your node at all. You could in fact never connect to the swarm and I could still read your content if you publish it to a peer that has distribution.
I still think that any content anyone is paying for you to see is necessarily spam.
I don't agree. I think the chief problem with advertising is that it is extremely repetitive. I'm not, in principle, opposed to being informed about new things relevant to my interests existing. In a world that is completely oversaturated with content, it is hard to gain traction on something new with word-of-mouth alone, even if it is of very high quality. There is a point to being informed about something existing for the first time (maybe I'll use it), and there is a reason why people would have to pay to make use of that informational system (the barrier to entry is necessary to make the new thing stand out in the ocean of garbage).
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?
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.
According to them. They shared their opinion.
No, they asserted their opinion as a fact.
There is a world of difference between "I prefer x" and criticising something while asserting "everyone should do x (because I prefer x)".
It's not normal to wrap all opinions in "I prefer". The average opinion statement looks superficially like a factual statement, without intent to actually claim it's a fact.
> No, they asserted their opinion as a fact.
Interesting idea, let's see if they confirm they were talking facts. I'll be very surprised.
I'm the worst person to take issue with this. This has been my biggest pet peeve for the longest time as well. Right until my frame of mind flipped randomly, and I recognized that by getting upset over blatantly subjective matters being discussed with zero cushioning like this, I'm doing little more than intentionally misreading the other person, and upsetting myself on purpose.
You're reacting to the smoke, not the fire. For example, this may have very well been a perfectly cromulent alternative reply:
> Sounds subjective, and indeed, I disagree. Not a fan of dogma like this anyhow.
There is no ambiguity that needs further clarification, I am talking about the words as written. Their entire message clearly conveys they believe there is an objective design standard that everyone should strive to adhere to, and they are criticising a website for daring to deviate from their ideal standard as though it were an objective flaw and not a matter of personal preference.
> getting upset over blatantly subjective matters being discussed with zero cushioning like this, then I'm doing little more than intentionally misreading the other person until I upset myself. You're reacting to the smoke, not the fire.
It's not about cushioning. They are explicitly criticising the website ("pity", "forgot to take basic principles into account"), and saying broadly that everyone should do X, where X is their own preference. That is the fire. That will invariably rub people the wrong way. It is inherently not an amicable way to communicate about differences in design opinions.
That's not to say you can't give critical feedback. "I'm not a fan of the font, I prefer fonts that are easier to read" would be perfectly reasonable. It's specifically the assertion that there is a way that things ought to be done, as though there are not trade-offs depending upon what each person values but rather one objectively superior way, that causes friction.
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.
I don't have any issues with it but I've been computing since the 8 bit days which basically looked exactly like that :)
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.
>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
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.
"Because I use NixOS, this was very easy."
First time I've heard someone say that
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.
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?
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.
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.
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.
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?
None, and it's okay to make a centralised platform but I wish people wouldn't fall for the decentralised marketing hype.
Unfortunately most people couldn't care less. Bluesky has been lying about being decentralized since day 1, and yet they have millions of users.
Bluesky has been asymptotically approaching full decentralisation. A few years ago the gap was everything except a decentralised design, then it was AppViews, now it's "tooling and documentation" for the bit of the PKI that only 50 entities have done.
Meanwhile I lost my Mastodon account history because I moved once, couldn't interact with half the network or apps because I was on a non-Mastodon codebase instance, lost my account again because I stopped paying for access to the instance I was on, all classic signs of centralisation.
> all classic signs of centralisation.
> I lost my Mastodon account history because I moved once
> couldn't interact with half the network or apps because I was on a non-Mastodon codebase instance
> lost my account again because I stopped paying for access to the instance I was on
On Mastodon, if something goes wrong, nobody can cut you off the network entirely. On Bluesky, the author deleted an empty test account and is now blacklisted network-wide until Bluesky support decides to help. That is a classic sign of centralization.
Being beholden to a particular server I have no control over sounds like what happened with Twitter/X.
The posts might exist, but they aren't associated with me. Why not? Because I was locked into somewhere and unable to vote with my feet and go elsewhere.
Maybe I stopped paying because the instance owner enforced sanctions against my country? Why should I lose my identity because of that?
> Independent implementations having compatibility issues is what happens when there's no central authority enforcing conformance. Frustrating, yes, but it's a symptom of decentralization.
Compatibility issues means lock-in to instances under individual control. Shared protocols means lock-in to a protocol, but ultimately freedom to move. We know that open protocols trumps opt-in collaboration by private entities for freedom.
> You could host your own instance, and nobody but yourself can revoke your access.
See also: instances not federating with other instances that are too small. You technically can, but in practice it goes nowhere.
> On Mastodon, if something goes wrong, nobody can cut you off the network entirely.
Bluesky is not perfect, but where it's approaching full decentralisation quickly on a solid foundation, ActivityPub has become the Mastodon show, and is less a decentralised social network, and more a federated set of centralised services with little accountability to users. You can't move, you can't control the content you see, you can't even search. It's a reversion to the days of 14 year olds drunk on power as a mod on a phpbb forum, or the Reddit mods of today.
I honestly can't tell if this comment is trolling.
I'll admit it's a bit charged, but I'm frustrated with bad faith takedowns of ATProto/Bluesky, while Mastodon (and it is Mastodon, not ActivityPub) solves almost none of the actual problems. I tried implementing my own ActivityPub server and the spec is so hilariously lacking that it's understandable that everyone just uses the Mastodon API instead.
ActivityPub isn't actually the spec of Mastodon. Treat claims of "Mastodon is ActivityPub" the same as you treat claims of "Bluesky is decentralised."
Just expose the same interface Mastodon does and you'll be fine. Noting that almost nothing cares about the exact URLs you use, except for webfinger, but does care about the domain being the same as the right side of the @ sign.
> Treat claims of "Mastodon is ActivityPub" the same as you treat claims of "Bluesky is decentralised."
Not sure if you meant this in the way I read it, but I believe that Bluesky is pretty much decentralised and tidying up the last bits of that, and I also believe that Mastodon is functionally ActivityPub and probably mopping up the last bits where the open spec meant anything.
The problem with ActivityPub is that it was missing at least half of what would be necessary to do anything with it, maybe more. You certainly can't create clients with it, it doesn't define anything about writing, etc. It's good that it's an open spec, but I see it as closer to Open Graph tags on web pages than it is to a social network foundation. That's fine... but we treat "Mastodon" as open because of ActivityPub, when in reality almost the entire system is defined by a Rails API implementation and its idiosyncrasies. I see it as a problem that you can't participate in the network without implementing an API with one implementation, rather than by implementing to a spec.
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.
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.