I was right about ATProto key management
notes.nora.codes
notes.nora.codes
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.
Or to put it another way: Domain names changing hands is how the web works. If you design your system to support web identities in a way that domains can't change hands then you are not supporting web identities but rather something different.
What would work better though? Like are we talking a more hardened identification system tied to personal data that can't change? If that's the case are there negative privacy effects of that, especially with whatever system controls that data?
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.
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.
Email has that problem too, doesn't it?
For email, if the owner changes, the new owner gets full control. This is nice for the new owner, but maybe not so for the old owner, because now any emails meant for the old owner can be read by the new owner.
For ATProto and AP, it sounds like in the event of an owner change, things kind of break. This protects the security of the old owner to some degree, but means the new owner can't really do much.
Anyway other protocols or implementations making the same class of error doesn't change the fact that it's an error and that it causes real world problems for users such as described in the linked page.
The described ATProto/ActivityPub behavior would be like trying keep the address tied to whoever lived there first.
Persistent identities are a nice goal but treating transient identities as persistent is not. A better designed system would use the domain name system only to look up the current identity associated with a name instead of trying to permanently tie the name to an identity.
Actually no. It's not supposed to break implementations that are made according to spec. It's not quite TOFU. Keys can be rotated. An Update activity would not work in this case because the new domain owner will not have the private key to sign it, but a periodic refresh that most implementations do will. The only fundamentally immutable field of any AP object, including an actor, is the ID. In practice, objects usually don't change types either, even though the spec technically doesn't forbid that. The only case I know when they do is when you edit a post and attach a poll, or remove a poll from a post that had one. Then the type changes between Note and Question.
Of course the dependency on DNS isn't nice. But we haven't invented anything better yet, so this will have to do for now.
Account migration on the fediverse is a thing, but it could be better by transferring past content. This is an active area of research right now.
> Account migration on the fediverse is a thing
Has something changed within the past year or so? Because if you're referring to the mechanism where a notification is sent out that A@X has moved to B@Y I hardly consider that to qualify. Proper account migration would mean moving the account itself, not automated assistance coordinating the person behind an account switching from one to the other.
If you do it in a rapid succession, then of course it would not work. You have to wait at least a day, and then, when you send something to another server, there's a good chance it would refresh your actor and pick up the new key. You can also force a refresh on a server where you have an account by pasting your self-hosted account's username or URL into the search.
> Proper account migration would mean moving the account itself
There is no such thing as "account itself" as a separate entity in ActivityPub. The URL that points to the actor object JSON, aka the ID, is your account, and that includes the domain. There are no higher-level identities.
> there's a good chance it would refresh your actor and pick up the new key.
And how will this be displayed to users of remote instances? Last I checked it was a confusing mess on most implementations (ie every one I have experience with) and the mess would persist indefinitely without manual intervention in the db by a given remote admin.
In the event a domain has changed hands then even with remote intervention no truly satisfactory outcome is possible. This is due to, as you rightly point out, there being no higher level identities. The domain is a fundamental part of the account as modeled by AP which makes conflicts a serious problem.
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.)
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.)
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).
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.
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.
Unfortunately that means the implementation needs to reach all the way into the network layer.
You design it with those requirements in mind? There’s no fundamental technical limitation at play here.
People want to build store and forward systems because that is their mental model of the problem. store and forward system are fine, and there are many advantages to them, but direct request systems scale much better. basically have each user fetch their messages from the locations they want rather than delivering the messages to them. think how the web works vs how email works.
Presumably by fusing the P2P and federated models together. There's no particular reason those two models can't coexist within the same protocol. It just hasn't been created yet.
Similar to how a good mesh networking implementation will make use a high bandwidth backhaul such as the internet if it's available.
But people don't want to run an always-online server to send their stuff to peers, so they host it on the main bsky servers. The problem with p2p is UX; people don't want to DIY their server.
What do you think is wrong about Mastodon? Genuinely curious because I also am super skeptical that ATProto brings anything that we really need.
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.
Creating a Mastodon account shouldn't mean supporting the particular political affiliation of the moderators, but I think it feels that way for many of the instances.
I'd like to do so, yes, but that exposes me to a (not insignificant) financial cost, (especially in Germany) a significant legal risk from CSAM/DMCA et al., and a significant amount of effort in maintenance.
Sure, there are "Mastodon as a service" providers that take at least the legal risk and maintenance off of me, but again, these cost even more money, and now I have the risk that the hoster is a fly-by-night operation that one day decides to close up shop for whatever reason.
And if anything happens to that private instance (say, the hoster disappears, the machine disappears without a backup, or the hoster undergoes an orderly shutdown), in the best case I still may have enough preparation to migrate the followers, but the old content is lost in any case. And that is bad.
In contrast with Bluesky and to a lesser degree Twitter, I can at least be reasonably sure that the provider does not vanish over night.
It's true that this solution doesn't work for private posts and DMs, but the n in O(n^2) is much smaller there, so I don't think it's as much of an issue for personal data servers to communicate directly in those cases.
Mastodon doesn't change this, it just changes who the admins are. It lets a person under the jurisdiction of admin A interact with a person under the jurisdiction of admin B, which is better than fully-centralized X, but it doesn't solve the fundamental problem. Your instance admin can still ban you with no recourse (account migration is incomplete, requires cooperation on both sides, and mostly exists to shut up Activitypub opponents who point these problems out). They're still just as (if not vulnerable) to government pressure as centralized social media, and considering that a single lawsuit could probably bankrupt most instances, I suspect they'd fold very very quickly. They can (and very often do) defederate from instances that post "too much nazi content", and if you disagree with the decision, there's again no recourse (you can migrate, but you won't get your lost relationships back).
Worse, they defederate instances that don't also defederate instances that they dislike badly enough so you can't even have neutral instances where you can communicate with everyone.
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.
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 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.
Perhaps you could consider toning down the absolutism. This is true in many or most cases, but certainly not all cases. Let's take, for example, video games. I can afford to purchase any game that interests me, and do. However, I often go several months between new game purchases, because I am not aware of any games that interest me that I do not already own. An advertisement for a game does not need to convince me to purchase it over an alternative product, it simply needs to make me aware of its existence and broadly convey what the game is about so that I will know whether it matches my specific game interests closely enough to investigate further.
Particularly in the modern world of hyper-specialised interests, it's quite easy to get into a niche of a hobby where you have found and already purchased all of the things you are aware of. As another example, there are hyper-specific novel genres where there are at most a couple of dozen entries in that genre and you are able to read every single entry in it. You are still interested in that genre, and will likely purchase anything else in it, should you become aware of it. Enter the benevolent advertisement, which makes you aware of its existence in a mutually beneficial way wherein you get more of the content you are interested in consuming and the creator gets money.
I agree that it does not need to do more than inform you - but that doesn't mean it won't do more. Please show me a single advertisement for a game that doesn't use bombastic language, show highly selective graphics, or appeal to a sense of nostalgia. I for one haven't seen one, even ones for the niche indie games I respect the most. Sure, not all commercials are equally deceitful, but they are all meant to be persuasive more than informative.
Still, I think this is such a tiny minority of real advertisment that it's barely worth mentioning. For example, here is a trailer for the original The Binding of Isaac, which (while being an interesting piece of art in itself, which many ads are) is stil clearly not just meant to inform consumers about the game, but instead is meant to sell a certain image of the game that it may or may not invoke in you:
https://m.youtube.com/watch?v=iDFnMfJnI7s
I'd also note that advertisments for artistic products such as games are some of the most ambiguous about the line between informative and persuasive, as the "feel" (atmosphere, tone, persuasive storytelling etc) of the final product is an intrinsic part of its value in a way that is not relevant for, say, produce, or consumer goods. It could be argued, for example, that the Story trailer for Elden Ring captures a real and important part of the appeal of that game, despite it including 0 details about the gameplay, and despite it being entirely original footage and dialog that is not in any way part of the game itself. The same ambiguity doesn't exist about an ad showing the glamorous lifestyle of someone who gets a mobile phone plan from company X, in contrast.
Nice in theory. In practice spammers will plant malware to steal microtransaction money from random people and push paid content down your throat for almost nothing. When you propose a novel model that will fix all the current problems, the first thing you need to think is how a bad actor would exploit it.
If you make everything explicitly transactional, you will be left with only people trying to make a profit.
There are so many heuristics and models you can use to filter.
And this disregards the simple fact that the only people willing to pay to have their words seen are people who are getting more money out of this - i.e. spammers (and yes, advertising in general, including "influencers", is spam in my book).
If you're a real person, then yes, it is valuable to show you things.
Want to know how I'm right? Because fingerprinting browsers and tracking people is how we establish that they are real in the current advertising world. Advertisers pay for that. Thus it has value.
In fact, judging by the Exodus of non-scammers, only scammers will pay to send you their messages—which makes sense, since they're the ones who expect to turn a profit.
Yeah, but I'm not. It's spam. And the people whose messages I do want to see are overwhelmingly not going to pay $20 to show it to me.
This is a system that selects exclusively for advertisements. Nobody would want this.
No one would want this? Again I don't think you understand what I am proposing.
It isn't a a system that selects exclusively for ads. It selects for people you know, then people they know, and so on, and fades out how often posts show up the further away you get. If someone pays more, then more people will see their message in their network as it compensates people for their attention, starting with the people who value their attention the least.
No one would want this? You think people don't want to get paid for their attention? This is essentially what a job is.
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.
If you want a fair comparison for reasoning about security related challenges and tradeoffs you should probably go with matrix.
Matrix simply doesn't solve some of the problems that email solves, or at least not in an e2e encrypted manner. For example, I can't send a document to a public institution's Matrix account, not in a manner that either (a) isn't e2e encrypted with no realistic risk of a MITM, or (b) doesn't require an out-of-band pre-approval, such as someone from the institution adding my account to some encrypted room.
Also, even if Matrix did find a way to make it easy to send e2e encrypted data to someone else without out-of-band communication, it would then suffer from the problem of spam. Every client would have to filter all incoming messages for spam, instead of being able to centralize this work at the server level.
Out of band confirmation is similarly universal unless you're okay with either TOFU or delegation. (Delegation being recursively subject to the same choice.) TLS on the web goes with delegation and a root certificate store obviously.
My point being that none of this is specific to either email or federation more generally.
Even the web suffers from problems of trust to some extent, with the PKI being a huge vulnerability and relying on the collective action of all browser vendors to act as a check on any CA trying to break the agreed guarantees. But in a world where you would have a hundred, or even 20, different popular browsers, with different geopolitical assignments, it would be far harder to punish a CA that decided to sign certificates improperly, e.g. to allow some government or criminal enterprise to MITM communication.
Establishing identity in a non-centralized manner, and without requiring a second, already secure, communication method than the one you're trying to authenticate, such as an in-person key exchange, is in fact impossible, not just hard. There are partial solutions, with different trade-offs, such as the PKI for the web, the TOFU with optional verification options used in Matrix or SSH, or the web-of-trust model of PGP.
Like at least suggest old school forums, IRC, or usenet.
We need an open protocol of this concept.
That's essentially exactly what they're trying to solve for although focused on the Twitter use case rather than Discord. And also one of the key advantages of ATProto over ActivityPub.
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.
The fundamental distinction between a communication network that is p2p and one that is federated is the storage mechanism.
For p2p the network itself is the storage, and as a participating node you connect and retrieve what is addressed to you while the amorphous data blob that contains said messages remains to float in the network. While for a federated network, the receiving node needs to be present on the network at all times to be able to access/receive the messages addressed to itself, after which the messages are absent from the network (to some degree or another).
Personally the overhead of having the network having to bear the weight of all its nodes data is too large to make it viable.
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.
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.
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.
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.
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.
As part of the IETF work (https://docs.bsky.app/blog/taking-at-to-ietf) this is a hotly debated area and I’d expect some solid evolution to happen as part of that process, super encourage anyone interested to get involved there!
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]
According to whom? It's their personal website, they're allowed to place value on whatever they want.
There is a world of difference between "I prefer x" and criticising something while asserting "everyone should do x (because I prefer x)".
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.
> 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.
And as has been pointed out, you are yourself asserting your opinion about subjective communications as fact (i.e. that you should always make it denotatively clear to readers when you’re going your opinion and when you’re globally asserting something)
> You’re shadowboxing against a claim that the person you replied to never made.
You start with this, and then immediately lead into:
> Communication is more than the simple dictionary definitions of the words being written.
> that you should always make it denotatively clear to readers when you’re going your opinion and when you’re globally asserting something)
Neither of which are claims I made. At no point did I engage in the dictionary-definition pedantry that plagues this site. I was specifically highlighting how the sentiments they expressed in their message come together as a whole. An accusation that one "forgot to take basic principles into account" cannot possibly be construed in any way other than insulting. That phrase denies the possibility that the OP considered readability but consciously chose to make a trade-off in alignment with their own values, asserts the author's view as a matter of principle, and denigrates the person who "forgot" to consider it.
> you are yourself asserting your opinion about subjective communications as fact
Insofar as words have any meaning whatsoever, I am observing a fact about how they chose to communicate. If you really want to play the stupid game the people of this forum love where you play at the margins of language endlessly redefining everything into meaninglessness to score points in an argument, you can count me out.
It's a well-known design principle to not impede the intended function of things by giving them a form that distracts from it. Of course you can deviate from that, especially if you want to make a point of some sort.
However, I presume they publish their writings so they will be read by others. Making this hard will reduce their audience.
If they are making this trade-off willingly, good for them, I suppose. But maybe they're so smitten with the style that they do not realize how hard to read it is.
There's also a point at which the form gets so bad that it starts to disrespect the audience. Again, that can be on purpose, but it might be unintentional.
This being a personal blog, it's not unreasonable to expect that a main purpose of it is communication. I think it's warranted to draw attention to the fact that its design gets in the way of that goal, big time.
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.
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.
The protocol can support all sorts of other social networks. People are building things akin to instagram, tiktok, medium, allrecipies, etc
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.
Decentralization is the new Centralization. For information ownership, the protocol needs to be distributed.
First time I've heard someone say that
feels like the new "btw i use arch"
I think this part of the UX is just being neglected by bluesky.
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.
Honestly, this is making me go further in the other direction, can we just do "twitter but owned by a trust" or something?
Working outside of did:plc is a choice - this project is on the very ragged, least baked edge of Atmosphere development.
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.
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.
Consider something simple like Slack: the selling point is that you can send messages to people. Being able to scroll back to last week is useful. Being able to scroll back 3 years is a nonessential bonus.
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.
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.
????? what data could possibly lead to this conclusion?
Misskey is an independent implementation, and actually what the biggest server instance runs (or at least was a few years ago).
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?
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.
Mastodon started as an alternative software stack for GNU/Social (and Laconica before it) years before ActivityPub even existed. It was created in an already almost decade old community/ecosystem and was competing against a PHP tech stack that was showing its age (which is why Mastodon was created).
Comparatively Bluesky/ATproto was a greenfield project with no pre-existing protocol or community to integrate with. And architecture-wise atproto within like 6 months of their 1.0 release federated/decentralised really really well. Bluesky less so (as it's mainly the appview that is limiting).
Even then though bluesky still works pretty well in a decentralised/federated context if you compare the scale it's operating at relative to mastodon and co back when they were of similar project age. Like the appview architecture at a high level works well but it breaks down once you are at a scale of tens of millions of users. And it'll only take relatively minor tweaks to the internal architecture of the bluesky appview to remove this scaling limitation.
Sorry for the rant but point being the ATproto is doing pretty well decentralisation wise for being ~3 years old and accommodating the sudden explosion of non-technical users on the platform so early in its life.