> 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.
> 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.)
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 and an off the cuff domain that they then forget to renew or have second thoughts about some time later.
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.
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.
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?
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.
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.
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!
Email is by far the least secure form of communication in common use right now. It's trivial to impersonate others over email, and every MTA that processes your email has access to the full contents, because they are never encrypted except in flight (and except by a few tiny disparate groups using PGP, and even these groups can't authenticate one another). And not for lack of trying, I should add.
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.
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.
The problem with centralized social media is that the admins have power over you. They can ban your account with no recourse, censor some of your posts (or some posts you want to read), or even post something from your own account that you don't approve of.
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).
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
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.
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 understand how you can seriously pose Discord as an alternative in this conversation as it's entirely centralized and full of all sorts of toxic behavior and failure modes.
Like at least suggest old school forums, IRC, or usenet.
Discord is technically centralised but in a way that mostly doesn't matter at the point of use, and its design avoids many of the failure modes of old school forums, IRC, or usenet where moderator cabals take control of any community and bully lowly users.
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.
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.
Micropayments are actually a huge problem, which is a big reason why no one has ever successfully implemented what you're suggesting on any large scale. Email spam is a major problem, and has been almost since its inception, yet the only effective solutions have been the ones that increased centralization and made it harder and harder to run your own email server. And even with all of these modern solutions, a LOT of compute is burned by every single MTA to filter out the spam that goes through for their users based on content filtering.
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 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.
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.
> 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.
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.
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).
Advertising is never going to inform you - it is by definition about persuasion, not information. An advertisement is always designed to try to convince you to buy a different product than you would rationally choose yourself. Even a seller in a physical market telling you their tomatoes are very sweet and juicy is simply trying to get you to buy: they have no idea, and don't care, if their tomatoes really are sweet and juicy (and definitely not sweeter and juicier than all the others tomatoes in the market), they just think you're more likely to buy from them if you hear that.
> An advertisement is always designed to try to convince you to buy a different product than you would rationally choose yourself.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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?
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.
> I lost my Mastodon account history because I moved once
Your posts still exist on every server that federated with you, there's just no central authority to coordinate reclaiming them.
> couldn't interact with half the network or apps because I was on a non-Mastodon codebase instance
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.
> lost my account again because I stopped paying for access to the instance I was on
That's just how paying for services works. You could host your own instance, and nobody but yourself can revoke your access.
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'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.
> 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.
Misskey is an independent implementation, and actually what the biggest server instance runs (or at least was a few years ago).
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.
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.
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.
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.)
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 and an off the cuff domain that they then forget to renew or have second thoughts about some time later.
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?
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.
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.
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.
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.
You design it with those requirements in mind? There’s no fundamental technical limitation at play here.
Unfortunately that means the implementation needs to reach all the way into the network layer.
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.
What do you think is wrong about Mastodon? Genuinely curious because I also am super skeptical that ATProto brings anything that we really need.
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).
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.
Like at least suggest old school forums, IRC, or usenet.
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.
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 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.
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.
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.
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 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.
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.
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.
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.
https://news.ycombinator.com/newsguidelines.html
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.
https://tangled.org/
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.
The protocol can support all sorts of other social networks. People are building things akin to instagram, tiktok, medium, allrecipies, etc
Decentralization is the new Centralization. For information ownership, the protocol needs to be distributed.
First time I've heard someone say that
I think this part of the UX is just being neglected by bluesky.
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.
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?
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.
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.
Misskey is an independent implementation, and actually what the biggest server instance runs (or at least was a few years ago).
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.
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.