I would like to use Bluesky.
-
What about all the workers who trusted you, whose family finances will be critically imperilled if you don't compromise, just a *little*. What about the "ecosystem" partners who've bet on your service, building plug-ins, add-ons and services that make your product better? What about *their* employees and *their* employees' families?
5/
-
Maybe you tell yourself, "If I do this, I'll live to fight another day. I can only make the service better for its users if the service still exists." Of course you tell yourself that.
I have watched virtually *every* service I relied on, gave my time and attention to, and trusted, go through this process. It happened with services run by people I knew well and thought highly of.
6/
-
Enshittification can be thought of as the result of a lack of consequences. Whether you are tempted by greed or pressured by people who have lower ethics than you, the more it costs to compromise, the fewer compromises you'll make.
In other words, to resist enshittification, you have to impose switching costs *on yourself*.
7/
-
That's where federation comes in. On Mastodon (and other services based on Activitypub), you can easily leave one server and go to another, and everyone you follow and everyone who follows you will move over to the new server. If the person who runs your server turns out to be imperfect in a way that you can't endure, you can find another server, spend five minutes moving your account over, and you're back up and running on the new server:
8/
-
Any system where users can leave without pain is a system whose *owners* have high switching costs and whose users have *none*. An owner who makes a bad call - like removing the block function say, or opting every user into AI training - will lose a *lot* of users. Not just those users who price these downgrades highly enough that they outweigh the costs of leaving the service.
9/
-
If leaving the service is *free*, then tormenting your users in this way will visit in swift and devastating pain upon you.
That not only helps you steer clear of rationalizing your way into a bad compromise: it also stops your investors and other people with leverage over you from pressuring you into taking actions that harm your users.
10/
-
These devils only sit on your shoulder, whispering temptations and threats, because they think that you can make things worse without spoiling their investment. They're not cruel, they're greedy. They will only insist on enshittification that they believe they can profit from. If they understand that forcing you to enshittify the service will send all your users packing and leave them with *nothing*, they will very likely not force you to wreck your service.
11/
-
And of course, if they *are* so greedy that they force your hand anyway, then your users will be able to escape. Your service will be wrecked and you'll be broke, which sucks for you, but you're just one person and your pain is vastly outweighed by the relief for the millions of people who escape your service when it goes sour.
There's a name for this dynamic, from the world of behavioral economics. It's called a "Ulysses Pact."
12/
-
Ulysses Pacts are named for the ancient hacker Ulysses, who ignored the normal protocol for sailing through the sirens' sea. While normie sailors resisted the sirens' song by filling their ears with wax, Ulysses instead had himself lashed to the mast, so that he could hear the sirens' song, but could not be tempted into leaping into the sea, to be drowned by the sirens.
13/
-
Whenever you take a measure during a moment of strength that guards against your own future self's weakness, you enter into a Ulysses Pact - think throwing away the Oreos when you start your diet.
There is no such thing as a person who is immune to rationalization or pressure. I'm certainly not.
14/
-
Anyone who believes that they will never be tempted is a danger to themselves and the people who rely on them. A belief you can never be tempted or coerced is like a belief that you can never be conned - it makes you *more* of a mark, not less.
Bluesky has many federated features that I find technically admirable. I only know the CEO there slightly, but I have nothing but good opinions of her.
15/
-
At least one of the board members there, @mmasnick, is one of my oldest friends and comrades in the fights for user rights. We don't agree on everything, but I trust him implicitly and would happily give him the keys to my house if he needed a place to stay or even the password for my computer before I had major surgery.
16/
-
But even the best boards can make bad calls. It was just a couple years ago that we had to picket to stop the board of the @internetsociety - where I had several dear old friends and comrades - from selling control of every .ORG domain to a shadowy hedge-fund run by mustache-twirling evil billionaires:
How We Saved .ORG: 2020 in Review
If you come at the nonprofit sector, you’d best not miss.Nonprofits and NGOs around the world were stunned last November when the Internet Society (ISOC) announced that it had agreed to sell the Public Interest Registry—the organization that manages the .ORG top-level domain (TLD)—to private equity...
Electronic Frontier Foundation (www.eff.org)
17/
-
Bluesky lacks the *one* federated feature that is *absolutely* necessary for me to trust it: the ability to leave Bluesky and go to another host and continue to talk to the people I've entered into community with there. While there are many independently maintained servers that provide services to Bluesky and its users, there is only *one* Bluesky server.
18/
-
A federation of multiple servers, each a peer to the other, has been on Bluesky's roadmap for as long as I've been following it, but they haven't (yet) delivered it.
That was worrying when Bluesky was a scrappy, bootstrapped startup with a few million users. Now it has grown to over 13 million users, and it has taken on a large tranche of outside capital:
On Bluesky and enshittification
Bluesky has announced a $15M series A raise by a crypto venture capital fund, leading many people to talk about 'enshittification'. But is enshittification the right way to look at things?
fediversereport.com (fediversereport.com)
19/
-
Plenty of people have commented that now that a VC is holding Bluesky's purse-strings, enshittification will surely follow (doubly so because the VC is called "Blockchain Capital," which, at this point, might as well be "Grifty Scam Caveat Emptor Capital"). But I don't agree with this *at all*. It's not outside capital that leads to enshittification, it's *leverage* that enshittifies a service.
20/
-
A VC that understands that they can force you to wreck your users' lives is always in danger of doing so. A VC who understands that doing this will make your service into an empty - and thus worthless - server is far less likely to do so (and if they do, at least your users can escape).
My publishing process is a *lot* of work and adding another service to it represents a *huge* amount of future labor:
21/
-
But I would *leap* into Bluesky and gladly taken on all that extra work, every day - if I knew that I couldn't get trapped there.
I don't know why Bluesky hasn't added the federation systems that would enable freedom of exit to its service. Perhaps there are excellent technical reasons to prioritize rolling out the other systems they've created so far. Frankly, it doesn't matter. So long as Bluesky *can* be a trap, I won't let myself be tempted.
22/
-
bryan newboldreplied to Cory Doctorow last edited by [email protected]
@pluralistic it is confusing to read this because we have done basically everything you propose in the AT Protocol, and it has been live in the network for a long time now. ensuring that service migration is easy and seamless is literally one of the reasons we did *not* use ActivityPub.
You can read how easy the process is here:
https://whtwnd.com/bnewbold.net/entries/Migrating%20PDS%20Account%20with%20%60goat%60On, I would mention, and independently run blogging service built on atproto! which bsky can't exclude/control
-
@pluralistic you say that we haven't "added the federation systems that would enable freedom of exit to its service". we have done that. what I think you *really* want is a peer running actual competitive alternatives for each component. That is similar, but different!
If it is possibly, why isn't anybody doing it? That is a great question! we have theories, and have done a lot already to encourage it (open code, open protocol, docs, etc)
