> why is a centralized “burn” able to completely prevent me from interacting with people using Bluesky?
Presumably to stop credential reuse attacks on Bluesky itself?
Bluesky is one instance and they should enforce security on that instance. If you use a previously burnt ID, they have no way to tell it's you (indeed that's the whole point!)
I've done some work in the DID space. Not really a fan, and the space is full of half working implementations like this post documents.
But this particular criticism seems unfounded.
It seems backwards to worry about attacks when basic functionality is undocumented/broken.
There are different types of attacks possible though, most broadly you can divide them into "design holes" and "implementation holes". This seems to be about preventing a design hole, and those you need to prevent with architecture/design, you can't just fix those once the implementation and documentation is done.
But the design hole is treating (IMO unfortunately) transient identities (the web's domain name system) as something that should persistently identify something. Adding hacks like this doesn't fix the underlying mismatch but creates new issues as seen in the article.
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.
I totally agree. This is the fundamental reason I've stayed off there until now. I'm not about to tie my permanent identity to a domain which I might not own tomorrow. And did:plc is not an option for obvious reasons.
Even though naively I treat my own domain as my online identity I see what you mean since they can be taken away by actions outside of our control.
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've done some work in the DID space. Not really a fan, and the space is full of half working implementations like this post documents.
I would be curious to hear your broader thoughts. I haven't actually worked with did but I did read through a large portion of the spec back before bluesky first launched. My impression was that it's a genuinely useful direction to go in but the standard seemed verbose and overly complex to me given what it does. But then that's not an uncommon thought to have about something you don't properly understand. (TBF I also feel that way about a lot of standards that I do understand reasonably well so perhaps I'm the problem here.)
Not the parent poster, but the cynical impression I had from very early on for DID is that almost all of its complexity and much of the reason its space is full of half-working implementations rather than working ones is pretty obviously because it was designed to be an abstraction layer on top of "namecoins" and when the "namecoin" dependency was removed (for good reasons) there were not enough good ideas for what to replace that dependency with, sort of intentionally leaving what was left of the design in a sort of guaranteed perpetual state of half-implementation (including implementations based on some of the original "namecoin" ideas).
This is fairly accurrate
Much of DID itself is basically a standardization of the idea behind Keybase, ie, using control of a private key as a marker of identity.
This in itself is a pretty good idea (with some bad usability, but at least technically interesting)
DID falls over because it has a bad interop story, and much of it is based on crypto-based implementations (again, technically interesting but bad usability plus a monetary incentive to go after your details).
So suppose someone had a domain and a Bluesky identity associated with it. They deleted their account for whatever reason and let the domain expire. Later, someone else bought the domain, but since it had a previously-deleted account associated with it, it's permanently banned from identifying a Bluesky account ever again. Do you really think that's adequate?
I really like the ActivityPub approach more. There, if a domain changes hands, so potentially do all accounts associated with it. An account can be permanently deleted by sending a Delete{Person} activity to the network, but that doesn't prevent an account with the same username from being created again.
I agree that the ATProto situation described is ridiculous. However the situation with AP is not nearly as cheery as you describe. The protocol commits the exact same sin, essentially baking in the assumption that any given ICANN DNS entry will only ever be controlled by a single entity for all time. Real world implementations then associate keys with nodes using a TOFU scheme (which makes perfect sense) and if the domain ever changes hands (thus the key changes) all sorts of stuff breaks in frustrating ways.
Even worse are the assumptions that a given node will never migrate between DNS entries or appear at multiple DNS entries simultaneously. In practice this comes up all the time because people regularly stand a node up on a cheap VPS using an off the cuff domain. Then some time later they either forget to renew the domain or have second thoughts about it.
While I appreciate that it's always easy to criticize things in hindsight there's no lack of aggravating real world problems related to the way AP models identity.
> if the domain ever changes hands (thus the key changes) all sorts of stuff breaks in frustrating ways
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.
Yeah it's a fair point that the spec as written doesn't preculde handling domains in a more sensible manner. But in practice it's a headache. Spin up a VPS, create A@X, send out some messages, nuke the VPS, spin up a new VPS and create a new A@X, send out some more messages, and check how well remote instances handle the situation. Maybe things have improved since the last time I encountered that? I doubt it though.
> 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.
> Spin up a VPS, create A@X, send out some messages, nuke the VPS, spin up a new VPS and create a new A@X, send out some more messages, and check how well remote instances handle the situation.
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.
Exactly my point. Account migration simply isn't supported. Not in any practical sense.
> 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.
"the assumption that any given ICANN DNS entry will only ever be controlled by a single entity for all time."
Email has that problem too, doesn't it?
It might be the case that the designers of email and the designers of ATProto and the designers of AP all assumed the owner never changes. But I think the actual behavior of the protocols in the event of a change is different.
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.
Email is more like physical mail - you send something to an address and whoever lives at that address gets the mail.
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.
No, since email is delivered to whoever owns the domain at the time the email is delivered. Besides a spam reputation score — which is a problem — one mail server doesn't retain a long-term trust relationship with any other.
Not really? Email is a dinosaur of a protocol that doesn't properly handle authentication to begin with.
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.
I’m trying to understand how “burning” works here. If I understand correctly:
1. Someone has a domain, example.net. They set up a did:web:example.net, and a handle @example.net pointing to it.
2. They deleted their account and let the domain expire.
3. I register the domain, but can’t set up did:web:example.net again. But I assume I can still set up did:web:mynewdid.example.net, and then point @example.net to that DID instead.
I won’t have access to the original account, but I will be able to use that domain as a handle for a new one.
(This, of course, is only my assumption. I’ve been able to switch my domain from one did:plc to another, but I haven’t tried it for did:web.)
Just to be clear, this is specific to did:web, did:plc does not have the same downsides (it has different ones).
It's written in anger, but I'm optimistic that this will eventually get fixed, and documenting bad experiences like this will help.
If you mean the buggy and badly documented process, sure.
But the complaint it builds up to is that instance-wide bans can ruin you when there are super big instances, and that's not something that can be fixed.
I see this as a mistake caused by really poor docs that should explain what to do and warn not to do the thing this person did.
It's also true that big instances have a lot of power and it's going to require a lot of growth of alternative instances to fix that, which will take time. At least it's possible, though. It's an intended outcome.
Any system that can ruin a spammer can also ruin someone who isn't a spammer, since the system can't tell the difference.
Peer to peer, not federation, is the way forward.
We should only build peer to peer social protocols.
Websites and communities should simply sample from the swarm and make it easy for non-technical users to post and consume. They should be optional and not central points of failure (or control).
{Twitter, YouTube, Reddit, Instagram, TikTok, WhatsApp, Discord} should work like {Email, BitTorrent, PGP}.
Bluesky and Mastodon are the wrong architecture.
The web, fancy javascript UI/UX, and microservices shouldn't be the focus. The protocol should be the focus.
A fully distributed protocol would dictate the solution to this exact problem.
Bluesky is designed the way it is because of scale. How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping? Bsky is designed so that the microservices themselves can be decentralized and so multiple different types of apps can be built on the same protocol/infra.
Obviously, it’s early days, and hopefully there is even more experimentation in the p2p space. But atproto architecture is a very fair experiment in this space. I can store my data on my own server, use a client app I wrote, subscribe to a specific aggregation/feed service I prefer, use the moderation list I want… all while still being connected to the larger protocol & network. It’s pretty neat.
> How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping?
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.
ATProto may be the closest we'll get to that. PDSes are granular enough to serve individual users, and you can (theoretically) pull from a relay and index only posts from users you're interested in for your appview, if you're hardware-limited. Relays are fungible and pretty lightweight themselves, so you're not depending too much on any central server.
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.
You invert the problem.
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.
RSS! But you can't make a personalized timeline with a pull model, and that's where the money seems to be.
I think finding where the money _isn't_ is a fun way to find interesting projects.
> How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping?
You design it with those requirements in mind? There’s no fundamental technical limitation at play here.
There kind of is: the computers the "p" run don't allow incoming connections and don't allow long lived processes.
You use routers as the beefy servers. Unicast, multicast, broadcast.
Unfortunately that means the implementation needs to reach all the way into the network layer.
Multicast doesn't work on the global internet, and can't, due to problems of scalability and billing. It's sometimes possible to negotiate with specific ISPs to use multicast in specific ways on their network.
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).
> 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.
Yes, very good point sure. I (as a Black not-right-wing person) have huge problems with the whole "The Bad Place" thing (long story short, Black folks that I generally agree with politically are absolutely horribly ban-heavy and way too power-trippy on moderation.)
A lot of us are our own instance admins, with our own accounts being the only accounts associated with our domains. I don't self-host though; I pay a dedicated hosting provider to handle this for me. This means I end up having a very similar relationship to my Mastodon provider as to my email- and cloud storage providers.
Is there any other way to deal with spammers that can't be applied to non-spammers by a malicious admin?
ActivityPub supports a less compelling user experience for many people: you only have a partial view of the network (you won’t see all the replies to the posts of people you follow on other servers), no global search, etc
Technically the internet also doesn't have "global search" but people are able to get along just fine most of the time.
This is how offline social networks work, and it might be fundamentally the only way social networks end up working. If each instance can't filter what it receives, then spam is too easy. If every message is globally flooded, the system scales as O(N^2) and is easily vulnerable to DoS.
AT solves these problems. Even if AT turns out to be a bust, they have an excellent architecture.
AT works by the use of global relays which see everything.
Sure, but it shows global replies, it provides global search, it's not O(n^2), it's not easily DOSed, and it's highly amenable to spam filtering, which are the issues you raised.
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.
> What do you think is wrong about Mastodon?
The same problems as always. Allow federation and you get...
- federation wars and moderators conducting these wars using their own users as hostages - I left Mastodon years ago when some particularly dumb morons decided to do bitchfights regarding Israel / Palestine. No I'm not interested in your pointless squabble, but I do care when I suddenly don't see posts from a bunch of users without even getting a notification...
- Mastodon-specific, when you move your account from one instance to another (e.g. as response to above-mentioned BS) your followings and followers migrate - but all your posts and media do not
- spam, trolls and griefers abusing the system, up to and including sending around CSAM material that inevitably gets sucked in by your instance, making you liable in the eyes of the law
- security issues. Mastodon has been full of these, no thanks I don't have the time to be constantly on guard lest I be exploited from above-mentioned griefers.
- other instances not giving a flying fuck about moderation or abuse going out from their instances.
Sounds like you want to run your own private instance. That way you control your own moderation and federation policies
I think the problem is that it's too onerous to run your own instance, but being on anything but the "default" instance means dealing with volunteer moderators imposing their worldview on the available discourse.
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.
And then you are also on the hook to be a sysadmin (including all the legal aspects thereof). That's generally a bit much to ask of someone who just wants to chat with their friends online.
> Sounds like you want to run your own private instance.
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.
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.
Comes across as an ad hominem. Email is insecure due to being dated, having a massive amount of inertia, and being essentially impossible to upgrade in the necessary ways without breaking backwards compatibility. None of that has anything to do with federation vs p2p vs centralization.
If you want a fair comparison for reasoning about security related challenges and tradeoffs you should probably go with matrix.
I don't agree with this at all. There are fundamental tradeoffs, and the reason no one has added e2e encryption to email, while we did add it to the web, is not because of backwards compatibility, it's because there was no compelling solution to some of these trade-offs.
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.
Doesn't the spam filtering complaint apply in equal measure to _any_ E2EE messaging solution? Signal can't implement content based filtering either.
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.
None of this is fundamental to the federated model. It's only because email is older than modern security practices.
It very much is.
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.
People often mention email as an example of federated communication, but the way email works in practice doesn't entirely live up to that ideal. Good luck getting your own self-hosted email server to send emails that actually reach anyone using a major email provider; they'll just be blocked as spam.
In practice, email is much less federated than it seems. A significant proportion of people are just using gmail. You probably don't have to include that many providers to cover a majority of people in the US.
I think federation has promise, but federation in itself is not a solution. Technical approaches do not address the more fundamental issue that, regardless of the mechanics of the system, big players will have more influence on its operation and evolution. Thus we will always need sociopolitical mechanisms to restrict big players.
Federation does at least give you the choice of providers, even a little bit of competition goes a long way to improving a company's behavior.
But in practice in doesn't always give you a choice, because the biggest providers will embrace and extend and start providing things other providers don't. Or they'll just make it difficult to export your data, etc.
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.
The GP didn't say Discord itself, but the Discord-like model of small communities. Ironically it's also the old web forum model.
Almost. The key difference is I can log in to Discord once and post in unlimited communities. The auth UX is excellent. Joining communities is very cheap.
We need an open protocol of this concept.
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.
how does it avoid that? i have experienced just as many power tripping mods on discord as i have on irc. the only difference to me is that i have never seen an irc channel with over 20 million users
By making it very easy for every user to start their own server, rather than the multiple tiers of ircops/server admins/etc. where some users genuinely do have more power (and/or a level of technical ability that becomes a difference in power) than others.
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.
I think supporters of P2P as "the one true way" perhaps don't realize that federation is just as peer to peer if your user count is 1.
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.
This is a flawed argument. If someone wants X they don't need to also support Y just because it's closer to X than other alternatives.
It's not a logical syllogism. And I would hope you have more to say about the coherence of a position than that it's merely not forbidden by logic, which is something less than an affirmative defense of its coherence and its motivations. It's about the perfect being the enemy of the good. "Well it's not forbidden by logic" is about as pathetically empty handed as it gets, in terms of accounting for which battles you're picking.
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.
You can centralize spam lists while still having the base communication protocol decentralized - that way people have the option on making their own decisions on whether "advertisements for penis enlargement pills" are really a problem - and let's be honest that's far from the only thing that gets moderated.
This isn't, and has never been a hard problem. Just pay for people's attention. People you follow don't have to pay, and make that transitive. Penalize people in your network who propagate spam by increasing the cost to get your attention.
If a scammer, advertiser, or some other form of spammer can get a payout just 1% of the time, they will be willing to pay much more than the average person posting the average tweet.
If you make everything explicitly transactional, you will be left with only people trying to make a profit.
Penis enlargement spam is worth like $0.00000001 per message. Any number higher than that makes them lose money. The real problem is that nobody will post on a social media network where you have to pay to post.
You have the graph of everything you follow, the graph of what they like, second order graphs ...
There are so many heuristics and models you can use to filter.
Twitter is thronging with blue-check spambots. This idea has been comprehensively disproven. People will pay to spam you.
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.
You did not understand what my original post suggested. I'm not suggesting people pay to be certified. If a spammer wants to pay me $20 to see their message, I am happy to see it.
> If a spammer wants to pay me $20 to see their message, I am happy to see it.
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.
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).
Should I create 1 million accounts with bots that scroll endlessly to harvest microtransactions?
This is one of the most interesting properties of peer-to-peer networks.
You can run your own ingestion algorithms, and one of the things you can do is set up inbound rules that incorporate micro transactions.
We have to build a lot of infrastructure to make this work, but it seems ideal for a world full of agents and autonomous systems acting on our behalf.
Do the outbound rules of other participants include microtransactions?
And who besides a spammer would pay more than $0 to have their message read by you? If I wrote a blog post about vulnerabilities of blockchains, or how I ran Doom on a pregnancy test, and you don't read it because I'm not paying you, you're losing value, not me. You guarantee an inbox of only spam — but at least you get paid for it.
If you've got great content, I would just follow you. Or someone I follow would follow you, and through the network it would lead to discovery. I want your content, so unless you charge for it, nobody's paying anyone.
If someone wants me to ingest something novel from far outside my network, one way to gain reputation might be to pay a microtransaction fee. I'd be free to choose to set that up as a part of my ingestion algorithm. Or maybe my peers do it, and if they "upvote" the content, I see it.
If my peers start acting poorly and sending spam, I can flag disinterest and my algorithm can naturally start deboosting that part of the network.
With such systems-level control, we should be able to build really excellent tooling, optimization, and statistical monitoring.
Also, since all publications are digitally signed, your content wouldn't have to be routed to me through your node at all. You could in fact never connect to the swarm and I could still read your content if you publish it to a peer that has distribution.
> 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 still think that any content anyone is paying for you to see is necessarily spam.
I don't agree. I think the chief problem with advertising is that it is extremely repetitive. I'm not, in principle, opposed to being informed about new things relevant to my interests existing. In a world that is completely oversaturated with content, it is hard to gain traction on something new with word-of-mouth alone, even if it is of very high quality. There is a point to being informed about something existing for the first time (maybe I'll use it), and there is a reason why people would have to pay to make use of that informational system (the barrier to entry is necessary to make the new thing stand out in the ocean of garbage).
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.
> 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.
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.
I don't exactly go around saving advertisements, but plainly informational ones do exist here and there. Off of memory, an example of an indie game trailer I think is well-made is that of Wargroove[1]. It's a simple and clear clip reel of gameplay showing off a variety of content and features, and if I recall correctly, advertisements for it were simply smaller slices of the trailer. I think there's nothing offensive about advertisements like this existing (although, that said, the number of times I wish to see such an advertisement is still exactly once).
I will grant you that this type of advertisement is indeed benign (though if I were really really really nitpicky, I could claim that the pace of gameplay shown in the trailer is probably not indicative of how you'd play the actual game, and I'm not sure if the music is part of the game soundtrack).
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.
fair enough, the did:web flows are not documented even for technical atproto developers, and there needs to be a self-serve way to heal identity/account problems elsewhere in the network (the "burn" problem).
I do think that did:plc provides more pragmatic freedom and control than did:web for most folks, though the calculus might be different for institutions or individuals with a long-term commitment to running their own network services. But did:web should be a functional alternative on principle.
I'm glad that the PDS was easy to get up and running, and that the author was able to find a supportive community on discord.
Thanks for responding, Brian. While I don't agree with a lot of decisions Bluesky and the broader ATProto community have made, I am very excited that progress towards real decentralization is happening; Blacksky's app view, for instance, was the trigger for me to try to finally try to set up an account. I would love to see more of a focus on the parts of the system that make this difficult, so that myself and other people who are tired of coupling ourselves to centralized systems can participate. It's hard for me to trust that this is the direction the community is interested in moving, but I hope you prove me wrong.
Thanks for the response Nora.
Because of your blog post I went through the process of setting up a did:web account myself this afternoon, and it was painful. Eg, I found a bug in our Go SDK causing that "deactivated" error (https://github.com/bluesky-social/indigo/pull/1281). I kept notes and will try to get out a blog post and update to 'goat' soon.
We've also been making progress on the architecture and governance of the PLC system. I don't know if those will assuage all concerns with that system immediately, but I do think they are meaningful steps in reducing operational dependency on Bluesky PBC.
I'm not too familiar, but isn't there a way to host your own did:plc auth server?
You can host your own instance, but resolving forks is not self-authenticating and requires some central trust (because of the 72 hour rollback window for higher priority rotation keys). Not counting that, you could essentially run your own fully independent instance where the worst that could happen is that you lack some newer updates to people's did documents (but anyone can upload them since they're self-authenticating). Some people do run their own instances for caching reasons, but these just ingest operations from the official one.
In terms of "credible exit", if the community at large could decide to move to a different PLC host, it would be technically possible for everyone to switch over.
Worth mentioning that Bluesky PBC is relinquishing legal control over the PLC and spinning it off into its own entity based in Switzerland.[1]
No, did:plc is centralised, not federated or anything. The whole ecosystem relies on a server at Blue Sky PBC
While did:plc was intended to be centralised from the start and under open governance (https://docs.bsky.app/blog/plc-directory-org), did: provided a framework to adopt other key resolution methods.
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!
Having a framework to provide alternative key resolution methods isn't enough. You need alternative key resolution methods.
I wrote a Bluesky app in preparation for a client project. ATProto is over-engineered for my purposes, though probably justifiably carefully engineered for the purposes of a big social Twitter-like thing. But since I didn't have to do the engineering, so what? It's a very solid platform for many kinds of multi-user information-sharing systems.
This article does give me the impression that I should make and use more test accounts than I currently do when mucking around with ATProto/Bluesky.
"View -> Page Style -> Basic Page Style" is required to read any of the text.
Indeed, it's a pity that the author placed so much focus on a cool looking font that they forgot to take basic properties like "good readability" into account. Form should follow function, not the other way around.
> Form should follow function, not the other way around.
According to whom? It's their personal website, they're allowed to place value on whatever they want.
> According to whom? It's their personal website, they're allowed to place value on whatever they want.
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.
According to them. They shared their opinion.
No, they asserted their opinion as a fact.
There is a world of difference between "I prefer x" and criticising something while asserting "everyone should do x (because I prefer x)".
It's not normal to wrap all opinions in "I prefer". The average opinion statement looks superficially like a factual statement, without intent to actually claim it's a fact.
You're allowed to criticize something without engaging in social legalese.
> No, they asserted their opinion as a fact.
Interesting idea, let's see if they confirm they were talking facts. I'll be very surprised.
I'm the worst person to take issue with this. This has been my biggest pet peeve for the longest time as well. Right until my frame of mind flipped randomly, and I recognized that by getting upset over blatantly subjective matters being discussed with zero cushioning like this, I'm doing little more than intentionally misreading the other person, and upsetting myself on purpose.
You're reacting to the smoke, not the fire. For example, this may have very well been a perfectly cromulent alternative reply:
> Sounds subjective, and indeed, I disagree. Not a fan of dogma like this anyhow.
There is no ambiguity that needs further clarification, I am talking about the words as written. Their entire message clearly conveys they believe there is an objective design standard that everyone should strive to adhere to, and they are criticising a website for daring to deviate from their ideal standard as though it were an objective flaw and not a matter of personal preference.
> getting upset over blatantly subjective matters being discussed with zero cushioning like this, then I'm doing little more than intentionally misreading the other person until I upset myself. You're reacting to the smoke, not the fire.
It's not about cushioning. They are explicitly criticising the website ("pity", "forgot to take basic principles into account"), and saying broadly that everyone should do X, where X is their own preference. That is the fire. That will invariably rub people the wrong way. It is inherently not an amicable way to communicate about differences in design opinions.
That's not to say you can't give critical feedback. "I'm not a fan of the font, I prefer fonts that are easier to read" would be perfectly reasonable. It's specifically the assertion that there is a way that things ought to be done, as though there are not trade-offs depending upon what each person values but rather one objectively superior way, that causes friction.
Subjectivity is implied. You’re shadowboxing against a claim that the person you replied to never made. Communication is more than the simple dictionary definitions of the words being written.
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)
I will give you credit, you have an art for writing absolutely infuriating comments. How is it that you manage to so perfectly encapsulate the exact thing you baselessly accuse one of doing?
> 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.
You are asserting your opinion as fact
One should not have to preface every single thing with "In my opinion" or some variant for you to realize that that's what they're talking about.
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
Backseat moderating is also against the guidelines. If you believe the comment needs moderator attention, flag it. It's pretty ironic you can't say this rule without breaking it
It's not a rule, but I'd like it to be
No it isn't.
I wish there was a rule against rule lawyering. Those comments are way more annoying than gp. (queue recursive replies)
I'd like to add to my sibling comments that this blog's design is so atrocious for its readability that it deserves to be called out.
In fact, I'd like for such a comment to be at the top here, so that I can decide to avoid following the link until I have read enough comments to determine whether it's worth it.
Or just toggle reader view (Firefox).
I don't have any issues with it but I've been computing since the 8 bit days which basically looked exactly like that :)
I wonder if it renders differently for different people.
My experience using ATProto is that it is somewhat like how the nascent blockchain apps were when they first came out: there's no written content that is viable. Instead, you're supposed to use ephemeral conversations and read a widely disparate set of notes in order to use it. In the end, the upshot of all this is that you get to use a slightly worse form of Twitter - which is already rather unpleasant to use for me because there's a lot of rage content there.
Microblogs are fun, and very often I can't justify a whole blog post, but I have seen that others just post their thoughts intermingled and it makes me wonder if perhaps that is what I should do. There's not that much utility to the wide audience anyway. Talking to people who understand you is much nicer anyway.
ATProto can be used be used for a lot more than just microblogs
So can ActivityPub, as far as I know. Most of the social coding projects agreed upon a shared vocabulary: https://codeberg.org/fediverse/delightful-fediverse-experien...
That is a really cool project, thanks for posting
Blockchain is still like that. Today I am setting up a blockchain node. The chain is actually two chains that recursively depend on each other. The docs say to start one of them first and wait for it to fully sync. It prints a timeout error for every block, saying the other chain node software was unreachable, and is estimated to catch up to current block height in about 200 years, which can't be right. Maybe I need to run both nodes at once contrary to the explicit instructions in the docs which say not to do so.
I wouldn't be surprised if half of all blockchains were vulnerable to some kind of trivial double–spend attack because it's not possible that all the complexity has eyes on it.
Edit: you're supposed to download a 2GB JSON file containing the state as of the last migration.
The normal way to set up most blockchain nodes these days is to rsync someone else's node's working directory. Obviously this is worthless as far as a decentralised and trustless system goes.
Nice to meet a third person who both works with blockchain and understands distributed systems ;)
>you get to use a slightly worse form of Twitter
The protocol can support all sorts of other social networks. People are building things akin to instagram, tiktok, medium, allrecipies, etc
I'm building a place review system.
Is there an advantage to using this protocol instead of a more application–specific one? Perhaps the shared identity?
A few things. Shared identity is one of them. Another is that applications can understand each other's data and mix them together, if they wish, or keep them separate, if they wish. An instagram-like client can read the posts made by the microblogging client and re-use posts that include images, for example. Same goes with the social graph: re-use one from another application, or create your own.
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.
Great, so what's the alternative? What's the "properly engineered" protocol?
Email, RSS, blogs, even Mastodon protocol (it's not ActivityPub) scales better. Anything that only sends data between interested parties, instead of to everyone.
Im sorry this is stupid. If you have to rely on one organization or a chain of systems where there is single point that can be effected, If your data does not live on your machine (PDS) then you are not in control.
Decentralization is the new Centralization. For information ownership, the protocol needs to be distributed.
Bluesky also randomly bans new accounts saying they violated the ToS. Like right after signup before you do anything. It says you'll receive an email with details (never happens) and offers a form to appeal. The form goes nowhere and you never hear anything again. This happened to me a couple months ago so it's probably still an issue. It seems more like sloppy, careless engineering than malice, however.
Happened to me a few weeks ago. I replied/filled out the form, and after a day it was unlocked. Seems to be very hit and miss, maybe depending on who is seeing your replies? Regardless, definitely a sucky issue...
This happened to me and I made a new account, which isn't banned yet but it could be any day now if they detect "ban evasion". Why I don't trust centralised systems.
"Because I use NixOS, this was very easy."
First time I've heard someone say that
"I use NixOS btw"
Looks like the author solved some issues but didn‘t document them as part of this blogpost. A shame.
> Because I use NixOS
feels like the new "btw i use arch"
OMG that website's font choices, good god, my poor eyes
Well-deserved criticism. The colors, too. Without reader mode, this is the equivalent of someone shining a high beam into your eyes at night while trying to communicate with you.
This is the kind of thing I click away from unless there's a strong outside signal that the content is worth engaging with.
I hope the author reconsiders these stylistic choices. I'm sure they lose readers because of it.
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?
Isn't that literally Bluesky? A PBC must act in the public interest.
Not exactly—a PBC is allowed to "balance" shareholder profit with "stakeholder interests. But at the end of the day, the money is still coming from the shareholders, and they're still looking for a return. They're required to be transparent, but that's about it. And there aren't really any penalties for not complying either.
Twitter but run by a bunch of NGO PMCs sounds even worse than twitter.
The bigots and sociopaths will need a place to exercise their freeze peach. Groups that don't want to be involved with that rancor need a way to evict such people when they are disruptive. Wikipedia hangs on with its NPOV policy. You can't do that on centralized open fora where opinion is the currency of the realm.
No we can't. Beacuse at anytime people like Elon Musk can come in and mess everything up. If all of your data is in someones server you are one ban away from becoming noone. Of course that is still true with atproto since majority of users are on bluesky PDS's. But the whole tech is being designed in such a way to prevent such issues while still looking and acting qs traditional social media.
The authors’ difficulty is legitimate and real, but there are less than 50 functioning did:web identities total on the planet.
Working outside of did:plc is a choice - this project is on the very ragged, least baked edge of Atmosphere development.
> Working outside of did:plc is a choice
What you're saying is: working outside of centralization is a choice. did:plc is a centralized database controlled by Bluesky.
Bluesky talks a big game about decentralization when it's extremely centralized. Everyone uses the centralized did:plc because it's the one way to really make it function. Until very recently, everyone used the centralized Bluesky AppView - and even now, well over 99% do. Bluesky will say things like "the protocol is locked open", but Bluesky could decide to shut off their firehose at anytime (leaving third parties cut off) and could decide to stop taking incoming data from third parties (leaving anyone on non-Bluesky servers cut off from basically everyone).
In a lot of ways, Bluesky is more like Twitter a decade or so ago. It offers APIs that third parties can use to build off of - but at any time, Bluesky could shut down those APIs. Back then, you could read the Twitter firehose and store the tweets and create your own app view with your own front-end if you wanted. Tweets would need to be sent to the Twitter APIs, but that's not really different than your third-party PDS server sending them to Bluesky if you want anyone else to read them.
You aren't open if someone controls the vast majority of a system because at any time they can decide "why are we doing this open thing? we could probably force the <1% of people elsewhere to migrate to our service if we cut off interoperability." Google Talk (GChat) offered XMPP federation and a lot of people bought into the platform because it was open. At some point, Google realized that the promise of openness had served its purpose and closed it off.
And it's important to think about the long-run here. Twitter was that benevolent dictator for a long time. Bluesky is still early and looking to grow - when they want people building off their system, giving them engagement, ideas, and designs they can copy. We're around year-5 of Bluesky. A decade from now after Bluesky builds its popularity on the back of "we're open and decentralized" while making decentralization extremely difficult, will that change? If Bluesky gets to a few hundred million users and then a third party starts looking like a potential threat, maybe they'll cut that off before they have genuine competition.
Maybe that won't happen with Bluesky. Maybe their investors won't care about the potential for a pay day. But if they have control (either through centralization like did:plc or by controlling the vast majority of the network), there will always be the potential for them to break interoperability. If they start monetizing Bluesky, why should they keep hosting, processing, and serving all that data for third party clients they can't monetize? Why shouldn't they stop federating with third parties before a third party becomes competition?
If Bluesky wants to be taken seriously they need to invest in decentralization themselves and not leave it as an exercise for the reader.
How many users actually care about decentralization?
None, and it's okay to make a centralised platform but I wish people wouldn't fall for the decentralised marketing hype.
Unfortunately most people couldn't care less. Bluesky has been lying about being decentralized since day 1, and yet they have millions of users.
Bluesky has been asymptotically approaching full decentralisation. A few years ago the gap was everything except a decentralised design, then it was AppViews, now it's "tooling and documentation" for the bit of the PKI that only 50 entities have done.
Meanwhile I lost my Mastodon account history because I moved once, couldn't interact with half the network or apps because I was on a non-Mastodon codebase instance, lost my account again because I stopped paying for access to the instance I was on, all classic signs of centralisation.
No, these are classic signs of decentralization.> all classic signs of centralisation.
Your posts still exist on every server that federated with you, there's just no central authority to coordinate reclaiming them.> I lost my Mastodon account history because I moved once
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.> couldn't interact with half the network or apps because I was on a non-Mastodon codebase instance
That's just how paying for services works. You could host your own instance, and nobody but yourself can revoke your access.> lost my account again because I stopped paying for access to the instance I was onOn 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've realised that social networks are real–time feeds, not archives. Some archival features can be useful but they are not the main focus of the product. Archival needs are very different from real–time needs and combining them in the same product doesn't work out well.
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.
They are at 0.1% decentralisation, how can you extrapolate asymptotic decentralisation from that?
I honestly can't tell if this comment is trolling.
I'll admit it's a bit charged, but I'm frustrated with bad faith takedowns of ATProto/Bluesky, while Mastodon (and it is Mastodon, not ActivityPub) solves almost none of the actual problems. I tried implementing my own ActivityPub server and the spec is so hilariously lacking that it's understandable that everyone just uses the Mastodon API instead.
ActivityPub isn't actually the spec of Mastodon. Treat claims of "Mastodon is ActivityPub" the same as you treat claims of "Bluesky is decentralised."
Just expose the same interface Mastodon does and you'll be fine. Noting that almost nothing cares about the exact URLs you use, except for webfinger, but does care about the domain being the same as the right side of the @ sign.
> Treat claims of "Mastodon is ActivityPub" the same as you treat claims of "Bluesky is decentralised."
Not sure if you meant this in the way I read it, but I believe that Bluesky is pretty much decentralised and tidying up the last bits of that, and I also believe that Mastodon is functionally ActivityPub and probably mopping up the last bits where the open spec meant anything.
The problem with ActivityPub is that it was missing at least half of what would be necessary to do anything with it, maybe more. You certainly can't create clients with it, it doesn't define anything about writing, etc. It's good that it's an open spec, but I see it as closer to Open Graph tags on web pages than it is to a social network foundation. That's fine... but we treat "Mastodon" as open because of ActivityPub, when in reality almost the entire system is defined by a Rails API implementation and its idiosyncrasies. I see it as a problem that you can't participate in the network without implementing an API with one implementation, rather than by implementing to a spec.
> Bluesky is pretty much decentralised
????? what data could possibly lead to this conclusion?
> 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).
I think most Bluesky users were happy with a centralized Twitter as long as the people running it were ideologically aligned.
I think a lot of those users do care but they don't know they've been lying.
This blog has a man page aesthetic. The problem is I immediately dont want to read it, because i dont like to read man pages.
That's fine but we don't need to know about that. Comment on the article, not on the format in which it is presented.
The article that they are having trouble reading due to its format?
I had no problem reading it but what browser these days don't have reader mode?
BlueSky has to be centralized right now because the quality of the federated network is too poor right now.
I am not convinced that is not by design.
It is in a sense by design because the focus was creating a decentralize-able/federate-able protocol and infrastructure that can scale more or less indefinitely first and foremost, community second.
The community is working on actually decentralising the network now that things mostly "just work" (assuming you are using did:plc/generally a happy path user).
- Building out PDS communities that are trusted takes time and nowadays there's a few outside of bluesky PBC (one or two big ones and a bunch of smaller ones). People are eager to move off because a lot of users really really don't like bluesky PBC leadership but it's a matter of waiting for these third party communities to reach critical mass.
- Relay infra is already pretty much decentralised. Lots of people still rely on the main relay but it's trivial to use a third party relay and there's more of them than you can count.
- There are a lot of really high quality third party clients and afaict a lot of users do actually use third party clients but there's basically no metric for tracking these stats.
- Appviews are expensive currently and there's work on making them easier to host but there's already one "full" alternative appview for bluesky.
- There are a lot non-bluesky apps/services that are genuinely high quality experiences and they are gaining their own communities.
The main technical barrier to true decentralisation outside of improving UX is introducing other did:methods and/or spreading trust of did:plc across the community (ex: clustered via raft or paxos across major operators) but there's just not a reason to pursue this over the other fires that need fighting in the ecosystem right now (and keeping did diversity low reduces another source of complexity the space just doesn't need to tackle yet).
--------------
TLDR: it is intentional because the goal is to in order of priorities:
1. get the architecture for eventual decentralisation right.
2. make it exist.
3. make it good.
4. make it easy to use for normal people.
5. build community.
6. focus on decentralisation.
Decentralisation in theory is the first priority but in practice it's the last priority. Being able to decentralise is always the utmost importance but forcing it to happen is not ever the top priority because that's on the community, not on the developers.
The way I see it, Mastodon started with a core decentralisation system and then tacked on bits to make it more Twitter-like, while Blue Sky started with a core Twitter-like system and then tacked on bits to make it more decentralised.
I don't really think that's fair.
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.
Nothing will improve unless they force it to decentralize.