Watch topic using email address without requiring registration

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.

4 Likes

Isn’t the idea though that the act of leaving the address is proactively saying they are happy?

Agree on issue of lack of address validation. That could mean that many addresses provided are rubbish or someone else’s.

1 Like

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.

1 Like

those only providing an email address should still have to confirm, via a link in a confirmation email

By this stage, they would have had as many touchpoints as if they were to make a user account. A quick-register button is probably all you need.

1 Like

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.

I’m responding to @pfaffman and his Post.

1 Like

It’s too bad that it’s no longer popular, since this kind of anonymous topic-watching is already supported in Discourse using RSS, e.g.:

2 Likes

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.

1 Like

It’s too bad that it’s no longer popular

Couldn’t agree more.

1 Like

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.

Time to go search the plugins…

Then why not use Social logins?

1 Like

Then why not use Social logins?

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.

2 Likes

And yet all emaillists work that way.

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.

Replying to my own response.

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 /users.json
Request:
  {
    "name": "string",
    "email": "string",
    "password": "string",
    "username": "string",
    "active": true,
    "approved": true,
    "user_fields[1]": true
  }


POST /t/{id}/notifications.json
Request:
  {
    "notification_level": "0"
  }

into:

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.

3 Likes

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.

See

Maybe building on this would help?

3 Likes

Thanks for the pointer. That actually looks perfect.

I’ll dig into the code and see if I can directly call the code that creates the staged user upon email receipt.

1 Like

Yep that was my original thought process but Active may not be the most useful property.

A full User is staged = false, active = true, so these are different attributes (note to self!)

Promising suggestion @mattdm … might well cut down the work involved significantly!

3 Likes

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
2 Likes