[…] but the profitable parts (algorithmic indexer and the app view with advertisements) are very much still in the hands of BlueSky the company.

Yeah, we’ll have to see if/when they fully enable third parties to run their own indexers and app views to see how committed they are to all this, and even then as the thread you linked indicates, there would remain many questionable architectural problems to AuthTransfer.

I came away from reading over the AuthTransfer protocol and its handling of moderation/enabling users with a very major sense of, “We outsource almost everything!”

As L. Rhodes writes:

[…] One effect of ATproto’s structure is to multiply the number of administrative relationships for which each user must decide for themselves—often on little to no information—who deserves their trust. The complexity of its infrastructures seems like it would sometimes make it difficult to assess when that trust has been betrayed, and by whom.

So Bluesky may redistribute some technical power from host admins to users, but it also gives them much more to navigate. It makes their need for power more desperate, and I’m not at all sure that the power trickling down to them through those other layers of infrastructure will be sufficient to the need. No doubt many will compensate by sticking to the parts of the network operated by Bluesky itself—apparent choice, de facto lock-in.

Yes, however without experience with Lemmy’s implementation, it wasn’t clear what the differences were. From what I’ve read of Lemmy’s basic implementation, i.e. submit a reason with your registration/application, this didn’t sound that far from it.

As I read it, Pixelfed’s request for more information form is a good addition (better than the awkward roundabout way you’d have to handle it otherwise, as I think I recall seeing come up with Lemmy), albeit as it’s optional we’ll have to see how well it’s used in practice.

Is there something more to it that’s not highlighted in the linked blog post?