In case of Bluesky, there will also only ever be a single instance of the App View. As far as I am aware though in practice there's really only the official relay or indexing services either.
You can, it just won't be the Bluesky App View, so it's not really Bluesky. It's not like the fediverse where the instances own the URLs of the posts: they go through app views and there's a canonical URL to a Bluesky post and that's through the official app view.
Different AppViews would obviously be branded differently, but the whole point of ATProto is that there is a shared "picture" of the world. People are running alternative AppViews that consume Bluesky posts (and serve Bluesky threads).
Here's the same thread on three different AppViews:
These are three independent webapps indexing the same information and serving it independently. They're not different frontends for one API; these are all independent backends.
one important correction is that blacksky is not hosting their own appview, they host their own PDS for users to join and a soft-fork of the official client
So, it's the same underlying data structures (e.g. posts, threads, etc.), and the way they're exposed depends on the implementation? So there's one BlueSky, but BlueSky is just one interface (UI + API). Am I getting this right?
I just want to know if I can run my own node in my own hardware.
Each user has a "website" with JSON of their own content (e.g. all my posts, all my likes, all my follows, actually live in a sqlite database hosted somewhere). It's not really a website but more like a git repo — one per user.
And then, there's a protocol for how to aggregate information from all such "websites" in the network into a stream of changes. Apps subscribe to that stream of changes and update their local databases (which act as app-specific caches) in response to those events.
When I make a Bluesky post, I'm really writing JSON into my sqlite file. This change gets broadcasted to all interested apps which update their own databases (which may or may not care about specific content type like "Bluesky post"). Obviously forks of Bluesky backend do index Bluesky posts (and then return them in the same UI), but you could imagine other backends that only care about other content types, or that record Bluesky posts but in a different database structure, and ofc can present a different UI for it.
Yes, you can run your own node — multiple types of nodes. You run your own PDS (https://github.com/bluesky-social/pds) to store own data (that's the "website" in my analogy), or you could run a Relay (https://whtwnd.com/bnewbold.net/3lo7a2a4qxg2l) that collects all PDS changes into a stream, or you could run an AppView (any backend that listens to Relay or PDS, basically your own app).
OK, to be honest, I'm surprised anyone runs a third-party Bluesky AppView even just as a curiosity. I genuinely can't understand why anyone would run one of these except as a raw curiosity.
If 99% of the people are using the default AppView, the default relay, the default indexers, the default PDSes, etc, etc... that just means that everything that almost the entire userbase sees is completely controlled by one entity. 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. Running an alternate PDS or even AppView seems like mostly a symbolic gesture since whether anyone can actually see your posts is still up to the whims of one entity, just like Twitter, and that's partly because there's no way to really "own" the URLs of your posts or profile. The canonical URLs are one domain owned by one company. The others are just alternatives.
But:
> the whole point of ATProto is that there is a shared "picture" of the world
I think everyone does understand that ATProto "solves" some of the problems with decentralization that you can observe from the Fediverse, but when you look at the practical reality of ATProto, it's hard to figure out exactly what aspect of decentralization users are supposed to be able to still benefit from. The whole thing could be re-centralized and literally 99% of all users wouldn't notice anything different. If you get censored by the entity running the primary AppView, or even deeper, you could theoretically run all of your own components... but then you'd just be talking to pretty much yourself. Even if you did succeed and somehow wrestled away a substantial portion of users, (which would be extremely expensive and impractical), 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.
P.S.: I know that mentioning censorship is automatically polarizing, but with Bluesky I really feel like I have good reason. I tried Bluesky briefly a long while back just out of raw curiosity, and I actually managed to get my account taken down with zero posts. I literally was just following some artists, mostly Japanese, and I assume one of them got banned for something NSFW. I'm not even sure I liked any posts that were NSFW. Needless to say once I got unbanned I just deleted my account and gave up on it. I wasn't really planning on using it for anything, so it's not like I am horribly offended by this, but it definitely gave me an idea of how Bluesky Social PBC moderates. No thanks.
Having multiple implementations available is an important step towards decentralization, even if most people don’t use them yet. It shows that it’s technically feasible and will help shake out any bugs.
Getting people to actually switch will be harder, and presumably it would involve both promoting the alternatives and adding features that some users will find attractive.
> [...] 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!