@jdp23 I don't see how partial relays would be possible in atproto. say some catastrophic event happens where people were dead set on splitting off from bsky the corporation. assume it's truly the top priority and nothing else goes until it happens. assume further still this is some unimaginable proportion of the userbase acting in concert - hell, say 25% want to go all at once. best case scenario for making an independent relay.

you create a new relay, migrate data to new PDSes, get that new relay to crawl the PDSes, so far so good. Now what tho? everyone on the new relay is invisible to everyone on the old relay and vice versa. you are back to 0 appviews and 0 feed generators because they all are listening to the main relay. every single appview and feed generator now needs to choose to listen to the new relay. but why would they? you're still responsible as an appview or feed generator for the content you distribute, and you don't know who this new relay is. that's assuming there's no ill will in such a massive split.

so you set up a new basic set of appviews and feed generators. do they also listen to the main relay? do you mirror the old relay in the new relay? do you let the old relay crawl the pdses too? if so, what was the point of the split? now you need to redesign all the existing appviews and feed generators in flight to deduplicate records, which is possible since they're content addressed, but i would doubt they're designed to handle multiple relays because none have existed before now.

what about DIDs? most of the existing infrastructure is designed to just use PLC, which is just a lookup table that bsky also owns. shoot. but we're saved by magic here, because remember there is no acrimony in this enormous network redefining split! So say bsky the corporation is kind enough to keep letting people register DIDs with PLC. we didn't quite make the clean break we were after, but hey it's only the fundamental ability to exist on the network that we were unable to leave behind, and we'll always be reliant on bsky's goodwill for that until someone makes a DID method that works and then we redesign all the appviews and feed generators again.

So now after all that... we're still invisible to most people on the main relay?! oh right because bsky the corporation also provides the default feeds, and despite the high numbers claimed in the press releases, alternate feeds are actually only sparsely used and as a rule very simple hashtag/account feeds because doing anything else is ridiculously expensive. Bluesky the appview is provided by bluesky the corporation, and that's what's actually fetching and hydrating the feeds for us anyway, so even if the feed generators swap over, we'd still be invisible to everyone still on bsky the app. More magic! bsky the appview chooses to crawl and hydrate our posts. We're pretty far from our initial intention of a clean break, but what choice do we have? Now we're partially viewable, some of the time, on some non-default feeds, and there's no way at all to tell within the interface which those are. All it took was totally redesigning most of the network and an enormous amount of goodwill.

What about labels? What about all the automated content moderation bsky the appview does like scanning images and etc? Who moderates? How? Who's paying for all this anyway? The new relay is bound to be extremely expensive - either it's too small and you don't have the critical mass to make any of the above happen, or it's very large and you run into exactly the same problems of scale that necessitate bsky the corporation to need seed funding and eventually make a revenue model on. Where on fedi people pay for servers and donate to their instance because it's a visible part of their experience with moderators they know and like, now all that labor is diffused among a bunch of anonymous service providers - this is by design! It was supposed to depersonalize the network and make it so everyone is just an interchangeable part that you can shop around between. What keeps people donating to the new PDSes, the new relay, the new appviews, the new feed generators? How would they even know how to do that?Meanwhile the network is continuing to tack on features with some combination of bsky corporation fiat, behind the scenes server magic, and so on, so the best we can hope for is partial compatibility and an always-inferior experience.

And that's just to get to 2 relays. what about 3? Remember how much people complained about how hard it was to find an instance? That's absolutely nothing to the combinatoric complexity of PDS * relay * feed generator * app view. How on earth will anyone know how to follow and talk to their friends? To see your friend's post, if they are not on the main relay, you need to get just the right combination of parameters. Even in this perfect scenario with unlimited resources, attention, goodwill, and organization, we couldn't even manage to make a clean break and still have to be reliant on bsky for basically the entire stack, at least partially.

So maybe some small, closed group could make subnetworks, and that is lovely! i'm glad that tech is out there. There's no such thing as privacy on those networks unless they redesign indigo, but hey it's a start! But that looks nothing like the interoperable paradise that's on the label.

In reality we don't get perfect conditions though, and so we'll get stuck at step one: new relay, zero appviews, zero feed generators, zero visibility, and zero people. Again I don't think alternate relays are possible with atproto -- if they were, then there would be no reason to invest $13 million dollars in bluesky.

#atproto #bsky #bluesky #fediverse