Posting this on behalf of @Fla
diaspora* doesn’t need an e-mail to be used. The e-mail is useful only to get back its password and to receive notifications. We don’t even send a verification e-mail to check if the address is valid and the user owns it.
I propose to make the e-mail field optional in the registration form with an indication like “Enter an e-mail address if you want to be able to recover your password and you interested to receive notifications by e-mail”.
Note: This discussion was imported from Loomio. Click here to view the original discussion.
I think that should be at the discretion of podmin
Hey @juansantiago why do you think that?
I have never needed to email any of the users on my pod (ever).
A possibility to enter an email after a registration would be essential I think.
Because occasionally is a useful tool to control splog (spam registration)
I also think it’s good, leave all possible freedoms to podmis and collective holding pods.
@macieklozinski Yes, this would remain in the users profile section so they can add an email address at a later date if they wish.
@juansantiago No, asking for an email address is of no use for controlling spam registrations as we do not require account activation so the spammer can just enter a fake email address. The CAPTCHA image is used to control spam registration.
My experience is more effective mail account activation than CAPTCHA , is not it a good idea to leave this possibility open for the podmins to decide?
It seems right that by default no email is requested.
Email validation does not currently exist. I can enter firstname.lastname@example.org and still create a new pod account.
This Loomio thread is purely around making the e-mail field optional in the registration form.
@rich1 OK, you convinced me
Absolutely, doubt anyone would block this. It should however be in pod settings, whether to require the field. I hope some day optional email validation becomes a possible pod setting too.
If we do this we should do it right and properly handle disabled mailer at the same time. So if either email input is disabled or the mailer is disabled:
- Do not show password reset links
- Do not show invite by email links
- Do not show email notification settings
- Go through all texts and check they don’t refer to sent emails.
- Do not require email confirmation when changing the email address and the mailer is disabled.
- Go through all mailers and handle graceful handling when the user has no email set.
- Probably a ton of stuff I missed.
Good catch mate!
But if the mail functions are enabled on the pod, but a user has signed up without an email address (optional) then if the user has no email address on their profile then do all that stuff in you list, but other users who do have an email address on their profile will still have those functions, right?
(Unless email is globally disabled on that pod)
Those kind questions is exactly why this “feature” is nothing you “just do”, you create all kinds of open ends. I’m personally not motivated to do all that work and if you want me to review a submission that implements this, you should start by working out specific action points and things that need to be changed, else the reviewer has to duplicate all the work of considering all edge cases that the implementer did already.