There Are No Instances in atproto
32 points by viktorstrate
32 points by viktorstrate
When people ask about instances, they are asking about independent operators. If Bluesky the company disappeared, would there still be a network?
There could be. And I think that's the answer Bluesky was originally going for. But there's always another bit of conceptual-Mastodon-ness that pops up in these discussions, and I think it makes people miss the real goal behind Bluesky's approach.
Currently, mastodon.social is the largest Mastodon instance and is effectively the "default" people are steered toward if they decide they want to have a Mastodon account. And if, somehow, it got permanently taken over by bad actors, the likely outcome would be that a lot of accounts on it would just give up on Mastodon entirely, rather than try to go through the process of finding another, friendlier instance and migrating onto it (which is still kind of a rough, partially-manual process even when the admins of your old instance aren't actively hostile to you, and presumes the rest of the Mastodon-iverse could even absorb a mass migration off mastodon.social, which is questionable). There would still be Mastodon, and "the Fediverse", but it would be a lot less lively than it currently is.
As I understand it, Bluesky was built with the implicit acknowledgment that no matter how hard you try to push technological decentralization/federation in the style preferred by Mastodon/ActivityPub people, it's still highly likely that social dynamics will cause one "instance" to end up as the biggest one and the effective default, and will represent the same sort of threat if it goes bad. And that's always the thing that makes a new social network difficult: starting from scratch, with no existing user base and social graph, makes your new thing look like a ghost town, and it's why a lot of supposed mass migrations of users off big existing social networks and onto new things don't really succeed. You have to already look popular to become popular (this is why, it's alleged, reddit in its early days used fake accounts to create the impression of more popularity and activity than it actually had).
So Bluesky, at least to begin with, seems to have aimed for something completely different than Mastodon. Rather than just try to make it possible to move individual accounts or small groups of accounts onto new "instances", Bluesky tried to make it possible to pick up and move the entire network. So if it went bad on a Tuesday, then theoretically on Wednesday someone with sufficient resources could spin up bluesky2 on a new domain, but with a full copy of all the original posts and the original social graph, and invite everyone to just come on over and keep going like nothing had happened. No fiddling around with settings on individual accounts or import/export of follower lists or "check a box to tell your friends you moved" or whatever. No need to get people to build up a social graph and posting activity from scratch.
And that, to me, is a very interesting idea, and I think it's a unique approach to the problem. And a lot of what they've been doing since launch seems to be iterating to build a layer of things-Mastodon-people-might-accept-as-"decentralized" under the hood, in ways that don't force ordinary users to be aware of them. Which is why, for example, you still don't see lots of Mastodon-style single-account "instances" popping up, but do see projects like Blacksky and Northsky and others which try to cater to a larger community and provide their own full infrastructure stack from accounts to app view, and a lot of the jeering along the way about "well that just shows it's not really decentralized" is missing the point that when difficulties have come up in launching those projects, Bluesky has typically worked to figure out ways to solve those difficulties, rather than just giving up.
Currently, mastodon.social is the largest Mastodon instance and is effectively the "default" people are steered toward if they decide they want to have a Mastodon account
mastodon.social is the largest ActivityPub instance. It accounts for about ~20% of the Fediverse. Higher than I would like but far from having a 'controlling share'. I'm on mastodon social, most of the people I follow are not on mastodon.social. Several of them are not on instances running Mastodon. I interact with Lemmy communities from my mastodon account (I also have another one on piefed.social as the mastodon UI is not the best for browsing the threadiverse).
Instead of speculating on what would happen in a hypothetical scenario, I'd like to compare what happens when one bluesky is down vs when mastodon.social is down. I have an account on both (although I use bluesky significantly less and find their search even worse than mastodon's and that is saying a lot). When bluesky is down I was effectively locked out of the platform, couldn't view anything. When mastodon.social is down, I'm locked out of their webpage. On mobile I can't update my home feed and search doesn't work. but I can still see cached toots. Because most of the toots are not from users on mastodon.social I can still go to their profile and browse their feeds. So even though I have a degraded experience, even when my account is on the server that is down I can still see other people's post.
nstead of speculating on what would happen in a hypothetical scenario, I'd like to compare what happens when one bluesky is down vs when mastodon.social is down.
You are free to believe that this is the single most important problem to solve and that the entire system should be built around solving it. Other people are free to believe other problems are important, and to try to solve those problems instead. The mere fact that a system does not solve the problem you think is important does not mean that system fails to solve any problems, or is worthless.
But if Bluesky-the-entity disappeared, everyone with a foo.bsky.social identity would be out of luck because they wouldn't be able to migrate their account, right? So you'd have a good chunk of the same problem you're pointing out that AP would have. Sure, I'd be able to load my follower data... and a lot of my followers would also be tied to identities that are no longer usable.
If I was my_user_name.bsky.social, then the replacement could migrate me over as my_user_name.bluesky2.whatever, so although the domain part of my handle would change, the actual user-chosen portion -- which is what people tend to care about -- would not change. And anyone who already used their own domain would of course be easy to migrate over as well.
All of the mapping from bsky.social to bluesky2.whatever could be done automatically, so end users would not need to worry about it.
How do I claim ownership of myusername.bluesky2.whatever? What stops someone else from claiming it? If you use your own domain I can see it working easily, but if you're just using bsky.social then all the auth information dies with Bluesky LLC.
I believe account recovery is a thing that's possible to design. If you don't, we'll have to agree to disagree.
Meanwhile, I've laid out for you what I understand the original idea behind Bluesky -- build a social network that could be restarted elsewhere with the social graph and posting history intact in the event of a hostile takeover -- was, and you're free to dislike that, but I don't owe you a detailed implementation of how it would work.
DID is still Bluesky Social PBC also.
This will apparently change in the fabulous future, but many things might happen in the fabulous future.
You would just migrate that .bsky.social identity somewhere else. Worst case the new pds doesn’t has your name available anymore and you have to choose either another name or another pds. Or your own domain. But all your content, followers etc could move with you.
spin up bluesky2 on a new domain, but with a full copy of all the original posts and the original social graph
Where does that data come from if the bsky.social PDS (+relays whatever) is completely down / actively hostile to migration?
Yes. There are independent operators of every portion of the stack. There's some weirdness with the PLC directory service specifically that would make that particular service trickier to switch over than the others, but even that one still has independent operators for it.
A synonym to "yes except for this one central service that's hard to switch out", is "no"
They said that one is tricker to switch. Not that there's no other operator or that switching is not possible.
Also using that part at all is completely optional
We're talking about one central service operated by Bsky which there is only one of, which everyone is using regardless of which app server they use or which host their account is on, right? That's not decentralized. How tricky it would be to switch the entire community from one directory server to another is entirely irrelevant.
FYI plc directory is being handed off to an independent Swiss Association so it will be out of the hands of Bluesky PBC
Anyone can mirror it (and people do, see plc.wtf) and the design does not require a central server. However somehow I doubt people would appreciate them moving the timestamping to a blockchain.
What's the point of mirroring the authoritative one? You don't want a mirror, you want a separate equally authoritative server. That's what it means for something to not be decentralized.
If the bsky-hosted one goes down yours can keep working and even accept operations. Operations are cryptographically signed, the only thing that requires centralization (or like, a blockchain) is the 72hr rollback window
It's not decentralized if there's one authoritative one which everyone has to agree to trust.
Yeah it isn't decentralized but their powers are very deliberately limited so that doesn't matter as much
could you link an open-registration independent appview + relay?
blacksky.community
I do not count Blacksky as “open-registration” since you need to be Black to register, so registration is restricted. it is also unclear how independent are they, given that they were affected during the last outage; guess we’ll need to wait for the next outage to find out.
There's also Eurosky, though it is unclear how much infrastructure beyond a PDS they actually run.
I think Eurosky is just a PDS:
Eurosky does not have a dedicated app as of yet. With Eurosky accounts people can use any AT Protocol-compatible client, such as Bluesky. We are currently experimenting with prototypes of new types of social media apps.
There will be something left, but 99.99+% of the userbase are on Bluesky Social PBC infrastructure.
If someone answers with multiple paragraphs talking about mastodon.social as the anchor of the Fediverse at 20% of the userbase but doesn't mention that the at proto number is 99.99%, and at proto users not on Bluesky infra are a mere remnant, they're leaving out the key part of the story.
at proto is Bluesky, in all systemic ways.
also, note when you ask a question about the present and get an answer that talks about the future, often couched in hypothetical ("can", "could") terms.
"It's just like RSS, except with a handful of enormous expensive servers in the middle that I'm not going to bother drawing in my little diagrams" feels... disingenuous. There is no ATProto app that talks directly to PDSes like a desktop RSS reader or podcatcher. If it worked like RSS you could just use RSS.
You don't need appviews. None of my atproto apps rely on an appview (ex. https://atpkgs.easrng.net, https://pen.wisp.place) appviews aren't needed for simple publishing, you can pull directly from the pds. If you need social features/backlinking though you do need to consume the whole network or rely on someone who has (like https://constellation.microcosm.blue) which is quite unfortunate and would be quite easy to fix imo, PDSes could just send and collect backlink notifications themselves...
I do get the impression that ATproto is potentially a good architecture for all sorts of things, but not actually for Bluesky, which seems a little awkward.
Yeah, this was the impression I got. E.g. atproto doesn't really have a good story (yet?) for private data, so Bluesky DMs are currently handled off-protocol. On the other hand, blogging-based approaches would probably be able to get away fine with just using cookie-based or HTTP basic auth (like what RSS does I think).
PDSes could just send and collect backlink notifications themselves...
Isn’t this exactly what ActivityPub does?
(Sorry if this was tongue-in-cheek and it just flew over my head!)
No, activitypub requires bespoke implementations per data model, atproto PDSes are generic and backlink notifications would not change that.
The diagrams are (perhaps intentionally) misleading with the endpoints labeled "app". You might think that means an app running on your desktop or your phone, which is what the analogy with RSS suggests. In fact, the "app" in the diagram is an ATProto "appview", which in the RSS analogy would be "Google Reader", except mandatory.
Since Sync 1.1, which is multiple years old at this point, relay servers aren’t enormous and expensive anymore, far from it. They can be run on a Raspberry Pi nowadays: https://whtwnd.com/futur.blue/3lkubavdilf2m
I implemented ActivityPub on my blog. People can follow me from Mastodon, and I can like or reply to their posts and it shows up correctly in their timeline. They can see all my posts in their instance when they click my profile, and many people would never know I don't have a real Mastodon account when they interact with my profile.
In order to do this, I had to implement WebFinger, a few endpoints, and a periodic job.
As far as I know, I can't do that with AT. Is there a way for people to follow my blog from BlueSky by implementing the right endpoints in my site?
the virgin birth in network terms: a decentralised network of a single server.
Tells you true believers.
Cryptocurrency pioneered this approach a decade ago. I remember the tedious arguments about whether this or that project was decentralized. It took embarrassingly long before I realized I was using my distributed systems knowledge to do the equivalent of being an archeologist arguing against the accuracy of the Egyptian theme on a slot machine. It’s just there to add a bit of flavor; people don’t really care whether a given project is decentralized in truth.
this would be true if there was an app 2. for now the picture is indistinguishable from the facebook picture, as all the blogs feed into bsky.app, and you can’t really avoid* using bluesky-the-company’s infra. (“all the blogs” is also a stretch, as >94% of them are hosted on bsky’s PDS anyway).
notably, tangled, named as another example, is also not decentralized, you have to use tangled.org to view repos.
*if you’re Black, you can try Blacksky which I think is now actually independent? that’s a huge step, and I hope Northsky will follow at some point
hi, tangled maintainer here: you can view repos on alternate appviews, i do so when im developing tangled.
we have not yet written much about spinning up tangled appviews, because it's a work in progress! but our new rust based appview can be spun up and backfilled in about 15 minutes. you can already try it out here: api.tangled.org (and spin up your own using these instructions: https://tangled.org/tangled.org/core/blob/master/docs/DOCS.md#bobbin)
clients to view repos (entirely independent of tangled.org) also exist: untangled.wisp.place.
hi, excited to hear this! I will try running a tangled appview + frontend then. I asked you about this a while ago, and you said to watch your blog, but you have not written about this in your blog yet :)
Even Blacksky feels like it had a few rounds of "we're totally independent now, promise!" => "oops, except for that part" at this point.
For the curious:
So, identity is separated from hosting and from reader. They could be packaged together, but that’s not a requirement. Right?
Are fully federated instances possible at this point? Does blacksky tick all of the boxes? I think there were some complications initially
If I read this correctly : there are no instances, but there are "hosting" that host your data. You can have a different "projection" (e.g. some app) that interacts with your data (or anyone's data) that is elsewhere.
But if the question is : where is your data ? It's on the hosting side. So, there are no instances, but there are servers that hosts your data and they decided not to put a frontend on them. Unlike on mastodon, that does both, but that seems not mandatory for activity pub, as it covers both server protocol and client protocel, no ?
The hosting side is simple, even: There are pretty minimal implementations of the "PDS", the Personal Data Server.
Problem is, they interact with Relays (that merge all that data in a single stream) that the self-hosting docs note require lots of bandwidth, and with AppViews (basically: the actual application), for which the docs point out that they need to replicate the entire data set they're working with: "the first thing you would need to do here is replicate all of the data in the network for the Lexicons that your application handles"
So, a distributed data store alright, but a lot of expensive machinery required to get at it.