How does lemmy implement Auth?

Currently you need to trust the app and your instance. Most instances are implementing off-the-shelf lemmy but there is no way to confirm that.

Yes that is what I wanted to know. My question was more directed towards other fedi software where you might want to secure/recover your account instead of using completely disposable accounts. So providing an e-mail address to an instance manager is what I was worried about, in case the instance manager decides to doxx their user. It's just a possibility that needs to be taken into account when signing up on the fediverse, which is not what most people are used to.

Honestly didn't think about relay addresses which is a handy tip. But I asked because I wanted to use the alexandrite front end on my desktop browser and was wondering how safe it is to hand over my login credentials to lemmy skins. Since those are hosted on closed source servers, you can't really verify what's happening on the server side and how safe it is to hand over your login credentials to them if you're not using a disposable account and a unique password.

There's a whole multitude of resons that could be argued for both approaches. I prefer this option because:

• Most people don't follow cyber security best practices and reuse the same password on multiple platforms. Currently, you have to trust the instance managers are competent enough to secure their databases properly from unauthorized access.
• Again, your average netizen does not have relay addresses for every service they sign up to. If my instance manager does not like what I say, they can publish my sign up information and dox me. I don't want instance managers to have this power.
• If I want to use somebody else's front end to browse on a browser, I have to pass my credentials to them to validate authentication details. Again a huge security risk if the hosting service for the front end is malicious. Why leave this vulnerability when there is a better alternative.
• Your average netizen does not want to familiarize themselves with the nuances of the implementation of each fedi software. They want a seamless experience with the same trust framework of legacy social networks, where they trust their data is safe. Not everybody is going to know that their sign-up information and login credentials are managed by each instance, with anybody having the ability to spin up an instance.

Why would you not want to trust the developers of each fedi software to hold this information, instead of trusting every instance manager to hold this instead? IMO that is a more vulnerable design choice instead of having a central authority managing user authentication, unless I am missing something?

I suppose this discussion is more suited on each software's github instead of a place to discuss this instance in particular, I didn't know how each software implements user authentication so I posted here.

E: I can now see why you are alarmed by my question. That is actually a good point. I am not sure if user authentication being handled by a central authority would violate principles of decentralization, which emphasize on interoperability and freedom of movement between different software and instances, instead of implementation of one component. I'm not sure if the management of authentication needs to be decentralized in the fediverse, as decentralization of freedom of movement itself is sufficient to prevent undesirable software implementations. I'd argue that managing authentication by instance managers is still a concentration of authority, albeit it is less centralized than a single source of truth. But I would love to hear arguments for why managing authentication by a single source is dangerous.