Every single time a post about atproto hits Hacker News, somebody asks in the comments: “But where are all the Bluesky instances?”. The problem is, there are no instances in atproto! The question is a category error. Instances are a Mastodon-brained concept, and I wanted something I can link to that explains this clearly.
So this is that post.
I know RSS is still being used somewhere (podcasts?!) but its heyday is arguably behind. Which is a shame. For a few years, which some of us might fondly remember as the golden age of the web, it felt like blogging was a cool thing.
Now look at this picture because it’s going to be important:
alice'sblogcat'sblogbob'sbloggooglereaderfeedly
As a reminder, you publish stuff on your own blog, which you can either self-host or host on a popular blogging platform. But then everyone’s stuff gets aggregated into apps like Google Reader and Feedly, or collective blogs like Monologue (RIP).
Note that hosting and aggregation are two separate things. Your posts don’t “live” in an app like Google Reader. Apps are mere projections of the Blogosphere.
Seriously, make sure this thought sears into your brain; it’s going to be essential.
Here’s what you could call an evolution of this concept.
We put a box around the whole thing so that everyone is enclosed in the same space so we can show ads and stuff. Also, let’s leave only one app (we can let alternative apps live for a while, but not for long). That’s traditional social media.
alice'spostscat'spostsbob'spostsfacebookthe facebook newsfeed
Oh no, now we have centralization!
Oh no, runaway network effects!
Oh no, bla bla bla.
What do we do?
We need to decentralize this somehow.
I say “Mastodon” here because if I say “ActivityPub” instead, a crowd of people will show up and say that actually what I’m describing is how Mastodon chose to implement ActivityPub. Whereas ActivityPub by itself does not really specify how to actually use it in practice. I’m sure this is all very interesting—but I digress.
How do we decentralize a social network?
Let’s build a version of what we saw earlier, but make it self-hostable. Then every community can have their own “little Facebook” or “little Twitter”. We’ll call them instances. They’re kind of like countries—because you live “inside” one of them:
alice'spostsalex'spostsann'spostscat'spostscrow'spostscali'spostsbob'spostsbree'spostsboba'spostsmastodon instance #1mastodon instance #2mastodon instance #3the newsfeedthe newsfeedthe newsfeed
But wait, this opens a bunch of questions.
How do you choose which instance to join? Maybe you’re a member of a few overlapping communities. Well, I guess you’re just gonna have to pick which community’s admins you trust the most with handling your identity and data.
Okay, now another problem—what if my friend’s on a different instance? How will they see my posts? Since each instance is basically its own little Facebook, they have no shared source of truth. So they have to send messages to each other:
alice'spostsalex'spostsann'spostscat'spostscrow'spostscali'spostsbob'spostsbree'spostsboba'spostsmastodon instance #1mastodon instance #2mastodon instance #3the newsfeedthe newsfeedthe newsfeed
This network topology might remind you of warrying fiefdoms in Ancient China.
If Alice-from-instance-#1 follows Bree-from-instance-#2, the two instances make an agreement: Bree’s posts will be forwarded to instance #1 so that Alice can see them. That’s called “federation”. You post on your instance, and then it gets forwarded to other instances whose users wanted to hear from you.
This picture has a few interesting implications:
[email protected]. “Where you’re from” is an immutable part of your identity. (Somehow, this manages to be even more restrictive than countries and nationalities.)Oh, and the arrows between instances scale as O(n²). This might not matter much now, but it could matter if this approach to social networking becomes popular.
Now forget all of that—full reset.
The mistake was when we drew this box:
alice'spostscat'spostsbob'spostsfacebookthe facebook newsfeed
Erase the box.
Go back to this:
alice'sblogcat'sblogbob'sbloggooglereaderfeedly
We have hosting where things actually “live”, and apps aggregate from them. This worked for blogs just fine, so why wouldn’t it work for literally everything else?
alice'sstuffcat'sstuffbob'sstuffapp #1app #2
Like RSS, but for all kinds of stuff.
That’s atproto.
Now you know! There are no instances in atproto.
Instances are these Mastodon-brained things:
alice'spostsalex'spostsann'spostscat'spostscrow'spostscali'spostsbob'spostsbree'spostsboba'spostsmastodon instance #1mastodon instance #2mastodon instance #3the newsfeedthe newsfeedthe newsfeed
They’re those isolated bundled hosting+app fiefdoms that send stuff to each other.
Compare this picture to atproto.
In atproto, we cut hosting apart from the aggregation at the network level:
alice'sstuffalex'sstuffcrow'sstuffcali'sstuffboba'sstuffatprotoapp #1atprotoapp #2atprotoapp #3bree'sstuffann'sstuffbob'sstuffcat'sstuffatproto hosting #1atproto hosting #2atproto hosting #3
There are no instances at all! There’s hosting you can swap, and there are apps that aggregate from everyone’s hosting. It’s very much like RSS and Google Reader.
The decentralization of atproto is richer in structure than “many copies of one app”:
If you want to swap your hosting, you can. I literally did this today. Aside from three or four UX snags, it was all automatic. My atproto stuff is at Eurosky now. If I were more adventurous, I could host all my data myself too for free on Cloudflare.
If you want to try new apps or make new apps, you can do that too! Check out Tangled and Semble, which have nothing to do with Bluesky. I’ve made my own app recently (and it’s open source). I recommend you to try your hand at it too.
You care about decentralization? You have full agency here. Decentralize away.
Now you see why every decentralized social media discussion is derailed by this.
Mastodon users measure decentralization by the number of instances because that’s the only thing you can do in Mastodon. If there’s only one type of “box”, and each box is “an app coupled with hosting”, the only thing you can do is to host more of these boxes and get them to talk to each other. They’re isolated by default.
In atproto, every app is a projection of the whole Atmosphere, just like Feedly and Google Reader are projections of the entire Blogosphere. You mostly “decentralize” by swapping your hosting, and/or by making and trying new apps. Running many full copies of the Bluesky database server is possible, but it’s not any more useful than running many copies of Google Reader. People do set them up (cue Blacksky), but they arise to meet someone’s specific needs (like a different moderation philosophy). There are other approaches too: this Bluesky client has no dedicated database at all, and it just hits a free community-run cache of everyone’s hosting. Shared network infrastructure like Relays has been cheap to run for a year now.
This is why “counting Bluesky instances” is so misleading. What matters is:
Separating hosting and apps fixes broken incentives in closed and in federated social. Coupling hosting and apps was the original sin, and the fix is simple.
Keep our stuff outside the apps; let the apps aggregate over it.
alice'sstuffcat'sstuffbob'sstuffapp #1app #2
Like RSS and Google Reader.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。