Watch topic using email address without requiring registration

OK I get it.

Perhaps I’m coming from the technology angle on this.

The reality is it though, it would be foolish to write this without making them some form of User (technically at least), because so much existing logic could be used if you did that.

e.g. the “Watching” logic that kicks off when an update happens on a Topic is going to check for all Users that are watching that topic. You’d be mad not to leverage that, not least because anything you write will have to be supported going forward and if you use the core logic, it’s maintained for you!

Perhaps this IS a presentational thing where you modify the front end (and back end where necessary) to take an email and register it as if they hadn’t been made an official user of the site.

In reality, and technically, in the back-end this is registered as a new User, but you use some way of setting them apart - I wonder if not activating them might do it? There are various changes you’d need to make to make that work but it might be doable.

If you are really interested in building this and have budget, I’d post in #marketplace.

It’s potentially quite a complex plugin, but an interesting one! We’d definitely consider it

I don’t know how complex it is technically with Discourse but is has been ages in WordPress-world. And it works. Basically it is just another mailing list.

is has been ages in WordPress-world

Indeed. Anywhere people are thinking about conversion rate optimization, they’re going to want this feature.

Perhaps I’m coming from the technology angle on this.

My thinking comes from looking at the user journey. One of the things you do is look for friction points that might cause users to drop off.

You’d be mad not to leverage that
Perhaps this IS a presentational thing where you modify the front end (and back end where necessary)

100% agree. In the simplest case all you would need is to create an ‘uncredentialled user’. Basically a normal user but with no username and password. Depending on Discourse internals, that could be easy or impossible.

but you use some way of setting them apart

Would you really need to treat them differently? Assuming not having a password didn’t cause an exception, they would simply not be able to log in.

One new thing you would need though is a way of ‘upgrading’ them to a fully (i.e. credentialled) user at some point in the future.

Yes.

There’s probably a long list.

If you modify the core logic via a plugin, you will have to make sure this new set of ‘special’ users are treated appropriately wherever the User model is accessed for whatever reason.

Absolutely. Something else the plugin would have to take care of.

Anyway, this is all theory atm, if someone wants to fund this we can take a look at it: #marketplace

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