Recently I was locked out of my own Ghost blog platform because they decided they were going to add Email 2FA. I also cannot add any other authors because that requires email verification.
Today I was looking at installing Bonfire and came across this:
Bonfire requires working email for user signups, password resets, and notifications. Most installations will need email configuration before the instance is usable.
Setting up email is a pain in the ass, costs money, is dependent on 3rd parties, violates privacy, and is just completely unnecessary. Why wouldn’t you give users the option to not use it? It’s infuriating!
You must log in or register to comment.
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.
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.
Thank you.
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.
Web push for notifications. Sure, there’s privacy implications, but it’s already near universal. There’s other options like ntfy.sh if you’re not limited to existing infrastructure. UnifiedPush also works well as a protocol for push notifications.
Everything else can be handled in-app. Password reset will have to be done by an admin, though it’s completely doable for a small selfhosted service.
Some of the downsides OP listed may or may not always apply, but there are always downsides. Either you have to set up your own email server (with extra maintenance burden), or your “selfhosted” app suddenly relies on third party infrastructure, like your email provider (or those of other users on your instance).
XMPP? Matrix?
Why do I need a messaging system in the first place?
XMPP and Matrix are not near universal.
Most people have no idea about that the hell the first one is, and are even more confused as to why you start talking about a movie when you just complained about email.
How are they not universal?
Most people have no idea they exist.
That is my point.
If you write software, and need a way for it communicate with the user outside of the app, implementing email is simple, just about everyone with internet access has an email address and it is free.
XMPP/Matrix is a lot of added work that will only benefit those who:
- Knows what they are and
- Has or are willing to set up an account and
- Care enough about it to do that rather than just using email.
I think you will find that the groups of persons who all three critera fits is vanishingly small.
So, please tell me why a developer should focus their time doing that rather than building the core features of the app.
EDIT:
I write this as someone who has used Jabber/XMPP and Matrix in the past, they are great services and I wish they had a longer reach. This is not a hill for you to die on.
So, please tell me why a developer should focus their time doing that rather than building the core features of the app.
It’s a whole lot less work than configuring email.
How much work do you think it is to add a toggle that makes email optional?
It’s a whole lot less work than configuring email.
It’s a crapload more work to support XMPP/Matrix/whatever messaging on any platform than just using a robust, reliable, resilient, widely supported good old SMTP. For you it might be easier to input your account (which at least on XMPP resemble quite a bit of email address) but for the developer it’s totally different thing. Also practically everyone accessing a website has an email address and if they’d decide to support some mesaging platform it’d make more sense to use whatsapp than XMPP since it’s vastly more popular.
It’s a crapload more work to support XMPP/Matrix/whatever messaging on any platform than just using a robust, reliable, resilient, widely supported good old SMTP
For the minimal of sending out a message to their accounts, they are just as easy as each other. Heck, there are simple packages to send XMPP messages from the CLI.
It’s a crapload more work to support XMPP/Matrix/whatever messaging on any platform than…SMTP
It’s absolutely not.
it’d make more sense to use whatsapp
It’d make far less sense considering both the fact that it’s a Meta-owned proprietary data collection and advertising product, and also that they simply don’t support such a functionality.
XMPP? Matrix?
That’s cute, but very much a bubble view. Usually not worth the effort unless the devs themselves are users.
Why do I need a messaging system in the first place?
You might not need one, but the majority of users want and/or need one for user management, password reset, notifications etc.
And it is being developed for the majority of users.
the majority of users want and/or need one for user management
Is it too much to ask for self-hosted users/developers to use something slightly more modern, convenient, and easier to implement? Or to simply make it optional? As long as it’s not even an option we’re pretty much doomed to the dinosaur-era of internetting permanently.
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.
I’m starting to wonder if a mailpit instance is a bad idea. Just a page you go to where any email goes, make sure it’s not externally accessible.
Was about to add that very idea, maybe I should write a compos file with postfix setup
I don’t want email to be accessible to those services. I don’t want those services to use email at all.
Then you’re free to patch it out.
Why do you assume everyone you interact with is a software developer?
I don’t think that assumption was inherent in the comment
If you want an unpopular feature that doesn’t exist on an open source platform sometimes your only options are to code it, or ask someone else to. The skillset of the feature requester doesn’t change that
your only options are to code it, or ask someone else to
I wasn’t asking for options, I was asking for an explanation.
To be fair, you are on a Self-hosting community but maybe read up the wiki or file the issue to suggest an option to make it not required on their git repo? 🤷
Otherwise, I’m not sure what else are we suppose to say
I’m not sure what else are we suppose to say
I wasn’t asking for advice, I was asking for an explanation.
You should probably ask the developers then. But the answer is probably to support things like password resets in environments with multiple users. It’s less development effort to implement it this way than to maintain multiple code paths with varying levels of account management.
You should probably ask the developers then
…which ones?
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.
Since then you would need to have another way to achive the goals e-mail does.
None of those things are necessary. Like I don’t even have email configured on my server because I don’t need it at all except when the developer unnecessarily integrates it to the extent that it breaks it.
for that one user that does not want it.
I am not at all the only one. Just look at the other comments and votes in this thread.
maybe the design goals of the software do not fit your goals.
That makes no sense. Nothing about the software goals are related to email integration.
None of those things are necessary. Like I don’t even have email configured on my server because I don’t need it at all except when the developer unnecessarily integrates it to the extent that it breaks it.
Depending on the view, a functioning service something like password reset is necessary. To design the software that it can ship without functioning password can or cannot make sense, depening on the design choices. Depending on what else got send via e-mail designing the software around that can be challenging and burdening for the future of developing.
If the setup required you to setup e-mail, the software and then also the developer can always assume there is a communication path to the individual user.
As i said, it can and cannot make sense, but saying
That makes no sense.
and not even trying to put yourself into other shoes just does not make sense.
functioning service something like password reset is necessary.
It is not necessary if you don’t lose your password, which I don’t ever, because I use a password manager. It’s also not necessary if you have administrative access to the server.
not even trying to put yourself into other shoes
Brother we have the opposite problem. You are not putting yourself in my shoes, or other people like me.
I am not suggesting everyone should get rid of it, I’m asking why it can’t be optional and easily disabled…
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 assn
is dependent on 3rd parties
Well, one of the two, at any rate.
If it’s not one it’s definitely the other.
Even if you self-host, other people’s mailservers still interact with it, unless you only chat with other users you host. And some of the big webmails variously get really pernickity about your DNS, DKIM and more, or they deploy some pretty obnoxious countermeasures against your server with little explanation. So I’d say it’s more often both than not, no matter what you do. If you think it’s not being a pain, there’s probably an unpleasant surprise in your server logs or coming soon!
It’s still often worth self-hosting, but that’s more big webmail really sucks, even ISPs often don’t set their mailservers up well and it’s often an early casualty of ISP managers looking for costs to cut.
Even if you have a proper clean IP, running a mail server is a hassle imo. By far having a single relay to send is fine if you get things set right, but also dealing with incoming spam is just way more work than paying to have it hosted.
I much prefer paying for email hosting and just dealing with outgoing emails if needed.
dealing with incoming spam is just way more work than paying to have it hosted.
The right way to deal with spam is not to use filters in the first place. It’s not like Gmail or Proton or <insert your favorite email provider here>'s spam filters are perfect either, far from it, they still let a ton of shit through. The right way to deal with spam is to use unique aliases for each account that you can shut down if they leak.
That depends who’s hosting it. There’s few good reviews of email hosting out there at the moment.
Depending on 3rd parties is a pain in the ass
