Casey

Absolutely! ATProto is like this right now (although a few groups are working to shift it more towards decentralization)

If bsky sticks with their protocol, they don't have much choice in terms of 3rd parties—but nothing is stopping them from changing their PDSes to not federate with 3rd parties.

A screen capture of the Bsky App account deactivation message that does not warn the user that the deactivation impacts ALL @ATProtocol Apps.

A screen capture of the Bsky email sent when requesting an account deletion from the Bsky App. The email fails to reference that the deletion is for the user's @ATProtocol account and thereby impacting access to their other Apps and data in the PDS.

@pfrazee.com @bnewbold.net Just confirmed a concerning behavior when deactivating & deleting a self-hosted account in the Bsky App. It deactivates & deletes the account in the PDS thereby removing access from other @Atproto apps. The Bsky App warning doesn't inform the user of this behavior.

We were able to implement an in-app toggle between the BSky and Zeppelin AppViews in a matter of minutes (but our app hasn't launched yet 😉).

I'm unsure about any clients that do this (aside from Zeppelin using its own, but I'm not sure if that is configurable), but it *is* easy for a client/app to do this, just none *are*. Imo this is because there aren't many AppViews available to use atm, aside from BSky's.

The only thing that needs to be self-hosted is the alt AppView; it can be done through ANY pds, BSky's included. zeppelin.social is doing this with through their app since they also host an AppView. *Interfacing* with AppViews is easy because it's just a header added to requests routed to a PDS.

It's easy for a client to interface with any appview—it just needs to proxy through the user's pds. I believe the biggest issue is the hosting costs associated with appviews (Zeppelin's was costing $200/mo a few months ago: whtwnd.com/futur.blue/3...), but I've seen some efforts to combat this!

Using dedicated ATmosphere/ATProtocol branding across ATProto (BSky included!) would go a LONG way to helping remedy confusion around where accounts can be used! A couple apps/developers seem to be tinkering with this, but most of the bigger ones I've seen fall into the issue of using BSky branding.

It's interesting because the buttons say "Sign in with Bluesky" but really they should say "Sign in with ATmosphere"

Somebody else needs to wordsmith this.

Great milestone. Looking forward to public comment period and hearing about similar milestones for other pieces in the stack, eg. PLC Directory.

Btw, any consideration to decentralize "AppViews"? Each could support a community while complying with/ local regulations. They'd "aggregate" w/ each other for a global view. I think we'd see more selection of "AppViews" under this model. Few have the resources to fund a single world graph view.

Bsky could suspend you on their AppView, but not on yours (or any others independent of them). Currently (mostly) everyone uses bsky's AppView, so they're subject to bsky moderation. That said, PDSes are built to easily support using alt AppViews, apps just need to implement it!

Not about decentralization necessarily, just bsky's dominance of atproto right now. Running your own pds is only part of the process; you still go through bsky's AppView (different than app). Moderation happens at the AppView side, so to 'bypass' bsky moderation you'd need to host your own AppView.

I verified the status of my DID in the old Bluesky PDS and new Nstar.social PDS through /xrpc/com.atproto.sync.getRepoStatus

Also, requested a recrawl to bsky.network/xrpc/com.atproto.sync.requestCrawl

As part of the move, changed my handle from h2oskier.bsky.network to scott.nstar.social.

Migrated PDS from Bluesky to Nstar.social yesterday evening using PDS MOOver. Pretty quick & painless! However, I'm experiencing an issue- Bluesky's AppView recognizes my account, profile & DMs BUT all new posts, replies & likes are missing. They show in Zeppelin. Thoughts? #atproto @pfrazee.com

Bluesky's pds doesn't seem to have any different behavior! Just tested routing to zeppelin.social's AppView through the bsky pds & everything looks to work identical to any other pds.

The atproto-proxy header seems to take precedence if it's set. If social-app sets it to bsky you should be routed the AppView it specifies. This has the side-effect that a single app could support multiple AppViews. We've tested this using our PDS, which has the bsky AppView set in its env config:

Confirmed. Setting a client app's "atproto-proxy" HTTP header to Zepplin's service id "did:web:bsky.zeppelin.social#bsky_appview" for api.bsky* lexicons routes the traffic to the Zepplin AppView.

There does seem to be a lack of hosted AppViews, but there are also very few non-BSky PDSes available right now, too. I've seen lots of promising signs for reducing the complexity and expense of hosting AppViews recently so I hope this is changing!

Of course, this doesn't prevent moderation on you from BSky's AppView, but it's *possible* to bypass this with your own AppView. If Apps start giving users the ability to choose what AppView they want to use, this can start to chisel away at the "99% of people on BSky" issue!

For example, one of the accounts I use for testing PLC operations got suspended a few days ago for unknown reasons (bsky.app/profile/cdev...). It's not viewable on BSky, but zeppelin.social (which uses its own AppView & App) does not show it as suspended: zeppelin.social/profile/cdev...

There are some things in ATProto that can help facilitate this! Looks like BSky's moderation happens at the AppView layer, and you can tell your PDS which one you want to use... however most ATProto Apps (including BSky's) don't support user configuration for this.

There is! Its the 'atproto-proxy' HTTP header: