I just went to enable the ATProto support on Wafrn and quickly realised this is *not* the native ATmosphere integration it's been promoted as.
The 'enable BlueSky' page in Settings says;
"To enable Bluesky, you will log in through the Bluesky flow and authorize your account."
Seems that it's essentially just an internal BS client, so it still requires a BS account, under the dominion of BS management. This is a bit disappointing.
(1/2)
@strypey@mastodon.nzoss.nz
is this not also what Bridgy does, but with more features and control than it has?
Here is your Bluesky/ATproto account as created by bridgy:
https://pdsls.dev/at://did:plc:fgltx44zk7r33d76v3z4g7kj
here's my account on the same viewer, for comparison:
https://pdsls.dev/at://did:plc:xn7uycuwxbg7xot6hdjm4bkk
Notice that it says our PDSes are not a Bluesky PDS. Your Bridgy account lives on Bridgy's PDS. My account lives on my Wafrn instance's PDS. Wafrn gives you full control of the ATproto account and allows you to directly view and interact with Bluesky accounts. While if you use Bridgy, Bridgy manages the account and you can only see bridged Bluesky accounts.
This article is written from a very pro-ATproto perspective, but it describes how Bluesky/ATproto works in comparison to ActivityPub quite well. I don't want to assume you're unfamiliar, but I wanted to link it in case you are: https://overreacted.io/there-are-no-instances-in-atproto/