My wife regularly has other people sign up for things using her email address (Her last name is more common than “pfaffman”). This includes schools and doctors. Sending mail to an address that has not been validated is irresponsible and should be illegal. Sending email to someone who isn’t willing to register for an account is a Really Bad Idea.
Maybe there could be a way for them to send an email to request the behavior (they probably don’t have their mailer configured to send from the wrong address) or otherwise validate the email address.
Sending mail to an address that has not been validated is irresponsible and should be illegal
It is potentially illegal here in Europe. I wouldn’t suggest not validating email addresses. I didn’t explicitly state it, but those only providing an email address should still have to confirm, via a link in a confirmation email, that they do in fact want the updates and that it is their email address. FWIW this is typically referred to as “double opt in”.
Sending email to someone who isn’t willing to register for an account is a Really Bad Idea .
Sending topic-constrained emails to someone that opted in with only their email address is just a mailing list. I just checked and TheHustle has over 1.5M members on their mailing list. I don’t think you can really call it a bad idea.
Isn’t the idea though that the act of leaving the address is proactively saying they are happy?
I’m not understanding the question. Do you mean that they should be happy enough to create a user account if they were happy enough to enter an email? If so, the answer is empirically ‘no’. The eCommerce folks have studied this to death and there is a pronounced difference.
Agree on issue of lack of address validation.
I’m not sure how this entered the discussion. Sorry for the confusion as I would never have suggested that.
Number of touchpoints is only one of the problems. Users really dislike creating and managing passwords. The more accounts they already have, the more reluctant they are to make a new one.
People are also reluctant to sign up for sites that have low or no reputation in their eyes. No one wants to join a club they know nothing about. If you give them a lower-commitment way of staying in touch with your community, you have the opportunity to build up trust.
It’s occurred to me that what I’m talking shares a lot in common with magic link/passwordless authentication. It looks like Discourse supports passwordless authentication as of 2.0.0beta3. To accomplish my goal, you would additionally need to have the option to allow a user to register using only their email (and probably a captcha to deter bots), auto-generating both a username and password. The form where you collect the email could additionally have a ‘watch this topic’ checkbox.
The user could afterwards authenticate via magic link sent to their email (after verifying the email of course). If the user wan’ts to stop lurking and post, they could then be presented with the option to set their own username and password.
True, that covers a lot of people. But there are a growing number of people like me that don’t use social login out of lack of trust for the login providers. The main providers are some of the least trusted companies on the planet.
And social login doesn’t address the issue of people simply not wanting to become a member of a community that they do not yet know anything about. Going back to my original example, I came to this community via Google looking for very specific information. I do not yet have any interest in being part of the community that generated the information. Keeping in touch via the most low-effort method available gives the community the chance to show value and bring that person into the fold.
Social login is a solution to the technical barrier, not the psychological barrier.
If the email the user enters is the same as the email from the social login, and considering that the permission requested when authenticating via social login, other than public data (that is already public), is the email address, than I don’t see a problem with the social login.
For example, I normally authenticate with google or github, and when the permission is asked I only make sure that only the email is requested. In this case I consider it much more convenient than entering the email address, because I don’t have to write it (and with email login I will possibly also have to validate the email). With social login it’s only 1 or 2 clicks.
Actually, it’s much more likely that I will subscribe to a newsletter (or similar stuff) via a social login than entering the email. Of course, this is my specific case.
I didn’t come up with any passwordless registration options in the plugin directory. I did find this topic where @codinghorror some objections to the idea: Why is password still required at signup? I don’t agree with them, but that seems to have been the end of discussion on this idea.
It looks like it’s time to either dust off my Ruby book or post on #marketplace
I’ve had a look at the existing API endpoints. It looks like in order to acomplish what I’ve laid out above, I’d need a plugin that combines functionality from these two endpoints:
POST /plugin-name/users.json
Request:
{
"email": "string",
"name": "string", // now optional
"password": "string", // now optional
"username": "string", // now optional
"active": true,
"approved": true,
"user_fields[1]": true,
"notifications": [ // new property
{
"topic_id": "some-topic-id",
"notification_level": "0"
}
]
}
This new logic would be added:
if name is null, auto-generate one
if username is null, auto-generate one. Possibly just set to a uuid
if password is null, set to a type 4 uuid or just a random string
if len(notifications) > 0, add a notification entry to the db
Additionally some language about how to set your own username, name, and password should be added to the welcome email. This is easy becase most of it is in https://example.com/u/{username}/preferences/account. This could just be one new paragraph that gets inserted.
Then of course you’d need a UI component that at a minimum has:
an email field
a ‘Watch this topic’ checkbox
a submit button
For GDPR purposes, it would be a good idea to also add a link to a page of documentation on exactly what ‘Watch’ means, what emails they will get, etc.
There is already code there to create “staged” users if you allow topics to be created by mail. These have a random username and are each associated with an email address. You can “claim” the account by logging in and validating that email address.
I’ve spent some quality time digging through the code. I think something like this (warning: very likely not working as I haven’t tried it yet) would work to allow the user to post a reply with just an email. I’d appreciate any comments you have.
I’m especially not sure if this is the best way to create a staged user. I haven’t found any method that specifically creates staged users though.
class SomePluginController < ApplicationController
# Make sure there is a staged user in the db
def ensure_user
# See if staged user exists
user = User.where(staged: true).with_email(params[:email].strip.downcase).first
# Create a staged user manually
if !user
user = User.new
user.staged = true
user.email = params[:email]
user.active = false
user.save!
end
user
end
# Watch topic as a staged user
def staged_watch
user = ensure_user
topic = Topic.find(params[:topic_id].to_i)
TopicUser.change(user, topic.id, notification_level: params[:notification_level].to_i)
end
# Reply to topic as a staged user
def staged_reply
user = ensure_user
manager = NewPostManager.new(user,
raw: params[:body],
topic_id: params[:topic_id])
result = manager.perform
end
end
