Selfhosted

Same I almost got locked out from my Ghost account because of email 2FA. Luckily you could change the config to override it.

Same annoying was with Mastodon, but luckily as admin you can approve accounts to override the email confirmation.

Since a lot of comments are arguing your point OP I just want to comment that I agree. Theres no reason to force email registration for self hosted services, it's very annoying.

If you're self hosting, the email service only needs to be accessible to those services. Set up a postfix container if you don't want these messages going out.

You can read them locally, or configure postfix to forward them to some other host if you desire.

Do you know of any other near-universal messaging system to use instead?

Edit: also, the downsides you mentioned depend really hard on the email service you choose to use, or choose to host yourself.

Ghost needs emails for a couple of reasons.

1. (Required) Ghost does not do user passwords. They use magtic links, which they send out via email when signing in. It's just how they have chosen to do it. You can ask them why they don't want to save passwords.

2. (Optional) Ghost has a newsletter function. If you enable it, you need to setup a bulk email service, like Mailgun. Even regular SMTP won't really work there. It can send out a newsletter everytime a blog post is published, so the members will get notified.

I recently had to do this email dance with a Ghost instance setup, where most of the email ports are blocked on the network. I know how you feel. I also wanted to just use passwords, but not currently possible with Ghost.

Other services might do the same as Ghost. I do host many services, that does not require email setup though.

Eh, I agree.

I have root access to the server and can directly interact with the backend DB. Forcing email for a password reset doesn't protect me from me.

You're getting ragged on but I would very much prefer an approach with these things that used some sort of modular system.

I'm imagining the service would have the option for "address for communication bridge" and it'd pass messages to it using JSON or something. The communication bridge would then decide which medium that would go through (email, SMS, smoke signals, whatever the owner configures).

As far as the service is concerned messages come and go (or just go) and how that side of things works isn't its problem. It'd also mean that one could configure fallback messaging mediums and use dummy ones for if one doesn't want anything like that (much like the "emails print to the console" debug tool Django has).

is a pain in the ass

is dependent on 3rd parties

Well, one of the two, at any rate.

Why wouldn't you give users the option to not use it?

Since then you would need to have another way to achive the goals e-mail does. Like password resets, user invitations etc. Thats all software burden for that one user that does not want it.

Setting up email is a pain in the ass, costs money, is dependent on 3rd parties, violates privacy, and is just completely unnecessary.

None of these i would actually say. To work around it you can just simply set up local reachable postfix. Done. You can setup a complete local mail server, with a few clicks.

Choose the software you want to use wisely and dont jump to the first solution you find when you are that licky about your requirements. If you are ao reluctant about e-mail and the service requires it, then maybe the design goals of the software do not fit your goals.