Is that really what people mean by it being easier?
In Bluesky you are asked to choose a “Hosting provider” when you sign up… it;'s just that it’s set by default to Bluesky and actually trying to set something else makes the experience of signing in much harder… so actually I feel Bluesky is the one for which the process is harder, if anything.
I can’t even get a direct url to the sign up page of https://bsky.app/ …but I can link https://lemmy.ml/signup
Nobody is being forced to seek an alternative Lemmy instance to whichever they found first. In the same way that nobody in Bluesky has to use Bluesky as their hosting provider or even choose to self host their PDS.
If the intention of the separation were to prevent any interaction from anyone who isn’t an existing Beehaw user they would have closed the sign ups. But they didn’t do that (https://beehaw.org/signup is open).
The reason of Beehaw’s defederation has more to do with moderation hurdles, and how they don’t trust content coming from other instances, see Beehaws own statement about this: https://docs.beehaw.org/docs/important-questions-decisions-and-reflections/on-defederation/
Like I said: the way the federation works, it’s a moderation nightmare to be fully open. Not because as an instance host you wanna hide the content you have in your instance from the wider public, but because you have to deal with (host, mirror, cache and display along with your own content) content that is coming from a different instance which might not share your same moderation strategy.
Both are reasonable asks. If a community wants to control who is allowed to access, there should be moderation tools that limit interaction to anyone who’s not been approved. However, this is a different thing from straight-up disallowing in your instance access to all users that happen to have registered their account in a particular instance. I don’t see why the identity/account provider cannot be separate from the access management and content moderation.
In fact, I feel that it would make access control EASIER for Beehaw if all new accounts actually were accounts from other instances, because that would let them audit the person applying for access in a more reliable way than they do currently in their signup form (https://beehaw.org/signup ). They would be able to check the post/comment history of the user, how many years has it been an active member, etc. before deciding if the user should be allowed to post content in their instance, and it would be protecting them from malicious actors / bots that might be pretending to be someone else. It would also potentially allow to use tools to check automatically the user for common bad patterns, which could potentially minimize a lot the human work in moderation and make the process much faster and convenient also for the person applying, so I feel this is a Win-Win if anything, not an “X has priority over Y”.
I think granular access control for communities and some other things that are coming will help when it comes to moderation tools. But it still cannot avoid having to deal with all the content from other instances in the federation, since that’s something fundamental in how activitypub works. There would need to be a new separate protocol for decentralizing the user identity between instances that don’t federate their content. Maybe something like OpenID.