neko-moe

or keeping your own plc rotation key and a backup of your user repo, then you can migrate even after bluesky issues a takedown on your user.

Because if you want to relay every single public event for every single user on the entire atproto network in real-time to many consuming apps and services… that's gonna cost something. Not that it costs a lot, but to expect what a relay does to be infinitely cheap is to not understand what it's doing or why it's doing it.

They're funding Fig to create and run a "full network backup" solution. What Bluesky really needs to do is figure out a way to get users to own their own backup recover key, whether personally or through some third-party service.

Not really, considering there aren't that many app servers. Each PDS sends out its events, those events are picked up by whoever wants them, mostly relays but some apps might directly subscribe. The more apps in play, the more connections, but it is not the case that for every new PDS, every other PDS now has to open an additional connection. It scales with the amounts of apps, not PDSs.

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]

[1] https://docs.bsky.app/blog/plc-directory-org

> I can't stress this enough: I don't find it acceptable to ban people if they like posts or follow someone who gets banned.

To the best of my knowledge, that kind of banning has only happened once[1] (I was one of the handful caught up in it lol). They reversed that ban when I complained. Unless you were banned at that exact time, what likely happened to you is that some kind of anti-spam filter thought you were a suspicious new account, agnostic of the content of the posts/accounts.

> I hate that everybody is just going to let this happen, and I hate that Bluesky proponents jump in and try their hardest to make it seem like there's hope for things to not be controlled by one entity. There isn't. It's a complete load of shit.

There already are other apps working independently from all of Bluesky's infrastructure (save for plc.directory). I think the big thing holding the protocol back is that they have not implemented private data yet (and it's probably a couple years off). Lots of apps need that, so many apps would not want to use the protocol yet.

I'm hopeful about the future of the protocol, because it does provide the aspect of decentralization I value most: your account is a signed repo and a private key (or several), and the network is necessarily fully open for any app to make use of however they want. Even client-side single-page web apps are feasible with generic backlink services (Constellation), which I find super cool. All that is needed now is time and app development.

[1] https://bsky.app/profile/safety.bsky.app/post/3lbsqm7kfns23

Relays aren't really user-facing, so most relay operators would probably only censor a user on the relay if there is some legal or network reason to do so, say content illegal in their jurisdiction or excessive spam.

If an app is concerned that a relay is censoring some user that they care about, the easiest solution is just to host their own relay. It's probably cheaper to operate than their app is. But if they really wanted to, they could listen to multiple relays to "cover the gap" or just manually listen to the event stream from specific users' PDSs directly whenever they notice censorship (effectively operating a partial relay in addition to listening to a full but censored one). But, again, in reality they'd just host their own relay and not bother complicating things.

The hardest problem of relays censoring content is to notice it happening, but once you notice you can easily verify it and switch to a different relay.

> [...] It's technically possible for people to use alternative services, but the community would have to wrestle the majority control of the network away from Bluesky Social PBC for it to really matter. [...]

> [...] now you just have the same split world that exists in the Fediverse, but with AppViews/moderation services. It kinda seems like the "shared picture of the world" concept is actually somewhat incompatible with having an actual decentralized network where users meaningfully have control.

I think an illustrative example of how a "community split" can happen is Blacksky[1]. It used to only be a custom feed but now have their own client app, their own moderation services, their own relay for their internal services, their own PDS for hosting their accounts, and to the best of my knowledge they want to set up their own Bluesky AppView at some point. With their own AppView, whenever a user is logged in to their client app they'd be using Blacksky's AppView, and anytime they're logged in to bsky.app they're using Bluesky's AppView. A user doesn't need to configure anything, they just download an app and log in with their existing account, and they can be logged into both apps at the same time. Compared to moving your account, to a new home server for Mastodon or even to a new PDS with atproto, it is very simple for your average user to use another AppView.

The "control" users have here isn't that they can control everything that happens within one app, it's that they're not limited to one app or one backend, and that communities of users can meaningfully run their own services if they're not being properly served by the existing alternatives, all while they still seamlessly get a fully global view of every Bluesky user and post.

And hell, atproto is very modular. People have made clients[2] that connect directly to users' PDSs and some "backlink" service like Constellation[3] (to get all likes, replies, etc.), which is much cheaper to run, skipping a Bluesky-compatible AppView entirely. There's also AppViewLite[4] which is a partial Bluesky AppView that's tailor-made for self-hosting.

Having all users, all posts, all data just be available globally to everyone means that you can create very novel and experimental decentralized services and apps. That is personally what excites me the most about atproto and how I see "user choice" be best served. How about a censorship-resistant client app more reminiscent of nostr that connects to multiple Bluesky Appviews and combines the resulting data? Or how about some ActivityPub-like AppView where small communities run their own homes and ping each other whenever there is new activity, eschewing a relay altogether. Everything is possible with atproto, and all of these services would create data existing globally for every other service and user, that can be interoperably viewed and created by any other atproto app that wants to do so.

> I literally was just following some artists, mostly Japanese, and I assume one of them got banned for something NSFW.

I'm personally one of the largest critics of how Bluesky Social PBC treat Japanese anime-style illustrators, so I share your frustration here. Though it's worth noting that large Mastodon instances do the same kind of moderation. Trying to follow illustrators on misskey.io from mastodon.social is very much a toin coss if they're censored or not.

One of my hopes is that we will eventually get the Bluesky AppView equivalent to Pawoo/Misskey. Ideally that one would create records compatible both with Bluesky and some new Pixiv-style atproto app. Then users could set up *booru sites too which work on the same underlying data as what the artists upload, i.e. the artist would keep control over the data. That kind of interoperability makes for a much more interesting web!

[1] https://blackskyweb.xyz/ [2] https://reddwarf.whey.party/ [3] https://www.microcosm.blue/ [4] https://github.com/alnkesq/AppViewLite