Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I could see "Bluesky AppView" has similar semantic as Mastodon instance: network, moderation...

The difference is on ATProto, when I get banned, people must switch to another "AppView instance" (could be reusing the same Bluesky AppView stack) to interact with me. I summary, my data is not lock in, but my audience could be.

On the other aspect, Bluesky AppView is only a small part (a microblogging network) of the bigger Atmosphere where we can create different AppViews for different use cases, e.g. publishing (leaflet.pub), code repository (tangled.org). Users can use the same handle and PDS for these AppViews.



Yeah I wanted to say that. From a user's point of view, it sounds like the AppView is the instance. If you disagree with the moderation, you can move to a different AppView (that may use different relays) but keep your PDS.

Whereas with Mastodon your PDS is your AppView, so if you leave the AppView you lose your PDS (and have to somehow export it).

Is that correct?


Yeah, I have the same understanding. On Mastodon, an instance is an all on one package. On Bluesky, each component can be deployed separately. The nuance is Bluesky PBC own the Bluesky (iOS, Android, Web) apps, the AppView and the default PDS hosting, I could say it's centralized by default and decentralized at will.


> I could say it's centralized by default

I'm not sure that's totally right, though, because I (using the entirely default bsky stack) can and do regularly interact with people who are using different PDS and AppView's (like, I can interact with Eurosky and blacksky accounts).

I think the thing that is centralized by default is the bsky moderation layer.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: