Email response notifications tooltip for users without active subscription

[axllent]

I apologise if I have missed something obvious, but I have a query about the email notifications, specifically to message responses.

If user A logs in (email login) and writes a message, and user B (email login) replies to that message, shouldn't user A get an automated email about that response without having to subscribe separately? Then if user A responds to user B's response, then user B should get an email notification etc?

I know email is working (NOTIFY_EMAIL_ADMIN=true receives a notification of every post), however remark42 is not sending out any non-admin response emails.

I know there is the "Subscribe by email", however I believe that is something completely different (ie: a user wants notifications for all messages regardless who posted to what thread) and isn't even shown in the SIMPLE_VIEW layout.

I have the following relevant settings (including the SMTP settings of course):

AUTH_EMAIL_ENABLE=true
AUTH_EMAIL_FROM=<removed>
NOTIFY_EMAIL_FROM=<removed>
NOTIFY_TYPE=email
NOTIFY_EMAIL_ADMIN=true

When a response is posted I see in the debug logs Admin:false Blocked:false Verified:false EmailSubscription:false. I'm not sure what the Verified:false is as the email was verified with the code in order to post in the first place, and I'm not sure if the EmailSubscription:false relevant or not either.

Maybe I got this all wrong, and if one expects an email notification to responses to their own post then one must first manually subscribe, however that does not seem logical at all?

I'm running the latest (v1.6.0) from the official docker image.

Any help/pointers/explanation would be greatly appreciated, thank you!

[umputun]

The way how users logged in (email, twitter, google, or anything else) doesn't affect the logic of email notifications. Any user, regardless of auth method, can subscribe to all replies, see #496 (comment)

[umputun]

to clarify why logged in (via email) user doesn't get "automated email about that response without having to subscribe separately" - this is because we don't want to do it by default. The first reason - not every user needs such notifications and the second - we don't want to keep the user's email around (this is needed for email notifications) unless directly requested.

[paskal]

I know there is the "Subscribe by email", however I believe that is something completely different (ie: a user wants notifications for all messages regardless who posted to what thread)

When a user subscribe to email notifications, they will receive all direct answers to their comments, not subscribe to particular page or someone else’s comment.

[umputun]

@paskal - this conversation made me think about the ability to have an option "subscribe" as a part of email login flow. Some checkbox (off by default) at the time user performs email login. Not sure if I like this idea or not, but technically should be not too hard to do.

[paskal]

I’m worried about inconsistency between different login methods it introduce, after implementation we will be asked “why not allow users from GitHub subscribe in one click as well?” and I’ll have no good answer.
If we want to do that properly, it make sense to enable this for everyone from the start. And then we’ll need to change login/signup flow for all account types I think.
What do you think?

[umputun]

I don't like the idea of extended auth scope, and this is required to retrieve emails from auth providers. Theoretically, it is possible to update the token and suppress email, but still meh. In addition, it will also need a way to allow email mapping on auth level. Most likely it means custom providers defined on remark42 level or adding general support of email in go-pkgz/auth, I have always resited to do.

[axllent]

Thanks for the replies and insights. If you don't mind, I would just like make a few observations & comments for your consideration.

Whilst it makes sense what you are trying to achieve here, I don't think it makes any sense from a user perspective. On almost any forum and/or comment system, a user expects to be notified of replies (by default) if they have to log in. Expecting a user to subscribe separately to receive these is like expecting a user to read terms and conditions, except in this case we don't even present them with the option - it is "hidden" away as a link in the top level post (ie: not shown when just clicking "Reply"), and also not displayed at all with the SIMPLE_VIEW option.

I deal with a lot of end users and UX (I'm a professional website developer), and even I did not understand how this was supposed to work (hence my original question). I definitely wouldn't expect any regular end user to understand this either. What you are going to end up with is a situation where people will use the comment system (it's awesome!), but won't be receiving the notifications they expected - hamstringing the whole point of the comment system.

What I think makes much more sense is a tickbox when replying or posting that (for non-anonymous posts) that says "Notify me of replies" (or something like that), and have the default setting for this configurable by the admin (startup flag) as to whether it is ticked or not by default (based on whether SMTP has been set up of course). I don't know the logistics of implementing this of course, and how that integrates with the current authentication etc.

[umputun]

I think we may solve it with additional information shown to the user on the first login. I.e. some sort of popup explaining what things user can do. Here we can mention all not so obvious things, like what different subscription means, how to drag-drop images, and anything else we like. This popup should be available after login as well, as somе "help" icon/link

Regarding "a tickbox when replying or posting" - not sure how this can be done. This is not just a checkbox to select but the whole procedure to enter email and activation code.

[kostimoshenko]

Hi everyone, before putting in my two cents I would like to thank @umputun and the other guys for the awesome commenting system. Although it is not very easy to install for a non-programmer, once it is set up I had zero issues with it, and ever since then I've been enjoying privacy-focused approach and how fast the engine is.
However, as @axllent mentioned above, users indeed tend to expect that an email notification will be received if they ever logged in & commented using any login method (with an exception of 'anonymous' of course). This is probably dictated by how Disqus behaves, which unfortunately became market standard.
Admittedly I have zero knowledge about how difficult it is to implement such a change, but maybe it could be possible for a site admin to choose behavior on the installation step, and choose whether to request user's email when login in using facebook / twitter / etc.
I use Remark42 for my personal blog (konstantin.ist) and from what I learnt over a year of usage is that the users more often than not ask for a more convenient behavior of the commenting system (i.e. they would like to receive automatic notifications without having to subscribe to comments. Again, as @axllent highlighted, most users just can't even find subscription option). And none of the site-visitors ever mentioned to me that it was awesome that their email address wasn't requested.

All in all, thank you again for Remark42. I will be using it regardless of how you're going to deal with this particular issue. I just thought it may be useful if I share my experience

[umputun]

@kostimoshenko thx for suggestions. Enforcing email subscriptions to all users still something which to me sounds like a bad practice promoted by disqus. In addition, the email from the social auth provider may not always be available and even if it is, it can be not the email user would like to use. For example, I have an outlook.com email associated with my Microsoft account, but I don't even check this email.

I think this issue should be resolved as a part of UI change as I've described above. We can even make it less intrusive by automatically offering "subscribe to all replies" at the time user post his first comment, instead of the first login. Actually we can offer this on any posted comment (if the user doesn't have a subscription), but this feels a little bit too annoying and if we decide to offer such repeated notifications I'd suggest making it optional.

what do you think?

[axllent]

Thanks for the feedback @umputun. I don't think anyone is talking about enforcing subscriptions here, but rather making it seamless and far more logical. Personally I would welcome a change in the UI to provide the "subscribe" functionality as part of the login (or posting) process as you explained, as this would make it possible for me to switch to remark42 (from that the dreaded system I hate so much).

One related thing I noted on those subscriptions was the lack of recursive notifications (please correct me if I am wrong). I'm pretty sure that subscribing (currently) only applies to direct replies to your actual comment, and not replies to replies etc. Eg:

User A's post
  - User B's reply
    - User C's reply

Currently if User A subscribes, he only gets a notification from User B's comment, but not from User C's comment. I think this makes no sense and prevents any meaningful "discussion". I think that the subscription should be for an entire thread, probably from the point of comment downwards (in the reply thread). Hopefully what I tried to explain makes sense?

[umputun]

Currently if User A subscribes, he only gets a notification from User B's comment, but not from User C's comment

That is correct. The user gets notifications on direct replies only.

I think this makes no sense and prevents any meaningful "discussion"

Well, it makes some sense, at least to me. I don't like to be bombarded by endless emails because some users have an active discussion in the thread I have started.

Probably such functionality can be added as an option. @paskal - I think we have discussed it back in days but I don't recall what was the issue. Probably extracting all parent comments recursively and passing them to notifier as a slice can do it.

[kostimoshenko]

Hey @umputun, thank you for the response. I would like to first of all apologize for taking so long to reply.

I think that your arguments about automatic email subscription are valid.

We can even make it less intrusive by automatically offering "subscribe to all replies" at the time user post his first comment, instead of the first login.

And I think that if something like this was indeed implemented, it would be just awesome. It wouldn't ruin or even put at risk a privacy-focused approach that Remark42 has been known for while simultaneously offering users something they were looking for. All in all, I think this is a great idea

[paskal]

Probably such functionality can be added as an option. @paskal - I think we have discussed it back in days but I don't recall what was the issue. Probably extracting all parent comments recursively and passing them to notifier as a slice can do it.

This is doable, likely by just creating multiple send requests recursively up to the highest parent. Please let me know if you want to create such an option. I propose then to create a separate issue for tracking its implementation.

[umputun]

This is doable, likely by just creating multiple send requests recursively up to the highest parent. Please let me know if you want to create such an option. I propose then to create a separate issue for tracking its implementation.

yeah, I think having such an option can be useful. As far as I recall notification already async and queued, so this should be doable.

One logical problem I see here - if we go recursively to parents, this functionality naturally will be limited to parents only (on any level) but not siblings. I.e. if some user joined a discussion on some sub-thread he won't get any notifications unless replied to his comment directly on indirectly. I'm not sure if this is an expected/acceptable limitation. On the other hand, enforce notification on any update of the thread (and all sub-threads), up to the highest level may produce a lot of updates and may look like noise to the user. It may be easier to implement (no need for recursive search at al, just a plain list of all sub-comments with dedup) but my vote is to do it for parents only (recursively). @axllent & @kostimoshenko what do you think?

[axllent]

my vote is to do it for parents only (recursively). @axllent & @kostimoshenko what do you think?

I do not see any issue with this, in fact it would be my proposal too. I would only expect to receive responses to my comment (and others "down the tree"), but not necessarily (or likely) to other branches off the original post (ie: stemmed from other branches up the tree).

- 1
  - 2
    - 4
    - 5
       - 6
  - 3

Let's assume each number is a different subscribed user, and that -1 is the original opt-level post.

• 1 would receive a notification from everything (2-6)
• 2 would receive notifications for 4, 5 & 6
• 5 would have received a notification from 6
• 3, 4 & 6 would not have received any notifications

Hope that makes sense and is what you proposed @umputun ?

In addition to above (and far less important), ideally there would be a way for someone to subscribe to an entire thread if they liked (separate to the functionality just discussed) - so that one could subscribe to an entire single thread, or all comments on the entire page.

[umputun]

Hope that makes sense and is what you proposed @umputun ?

Yes, this is what I proposed. However, the case I had in mind as I mentioned "siblings" comment can be a valid one. For example, 5 joined sub-thread 2 and, in addition to 6's notification, expects to see all other notifications from the same level, i.e. replies to 4. Practically, such notifications can have some value because of those messages sort of the talks-on-the-same level. But as I mentioned above - I don't think this is a good idea and we better keep it as simple reply notifications to parents only.

a way for someone to subscribe to an entire thread

This can be useful, but will be much harder to implement, as we will need to associate particular posts with user-level subscription metadata

[paskal]

@axllent @kostimoshenko as recursive email notifications are implemented, could you please revisit this issue and summarise what else you think would be reasonable to do? I'm a bit lost in this discussion state at this moment.

[axllent]

@paskal That's awesome news (recursive email notifications), thank you!

As part of this it was also making it easier for users to subscribe themselves. It's not that it is currently difficult, but that it is illogical. There is currently no indication that they are or aren't subscribed to receive email notifications, or what they are subscribing to (is it all comments ie: the page, or just responses to their threads, just on this page or on the whole site etc). I would even go as far to say that the average user isn't even aware that they aren't automatically subscribed after commenting, given the "norm" of well known commenting systems that automatically notify you.

I was proposing that this:

• Become clearer to the end user
• Potentially be part of either the login section, or commenting itself
• Optionally allow automatic email notification to replies as the default

From memory if I log in via a github auth then Remark42 does not know my email, am I right? How about if one logs in via email then, does the system know my email address? If remark42 is aware of the email, then maybe something like a tickbox (when commenting to subscribe to alerts), or when I am logging in something similar ("email me when someone replies to my posts").

I do not know the architecture of the current system, ie: what Remark42 does and doesn't "know" when I log in or while I'm logged in, so it is difficult for me to judge what can and can't be done, but I do not think the current system is logical at all. I feel that placing a notice above my comments (alerting users that that must subscribe separately) is something that should be avoided if it can be done in a much more logical and elegant manner directly in the commenting system.

I hope that makes sense?

[kostimoshenko]

@paskal I found that we discussed it with @umputun and he offered the following:

We can even make it less intrusive by automatically offering "subscribe to all replies" at the time user post his first comment, instead of the first login. Actually we can offer this on any posted comment (if the user doesn't have a subscription), but this feels a little bit too annoying and if we decide to offer such repeated notifications I'd suggest making it optional.

In general, I think it does make sense to offer a user an option to subscribe to all the replies to their comments when they post first comment.

[paskal]

The remark42 doesn't know your email even if you log in using email because of our position on privacy. Reminding users to subscribe to replies once in a while and pointing them to through the subscription steps would be reasonable.
How to do it is an open question: once per account until turned off with the ability to snooze it for later? Once per session and store a setting in a cookie or somewhere else in a browser to prevent things leaking from frontend to backend? Some other option?

Unfortunate thing is that it's a frontend task (or mostly a frontend task) and I can't implement it myself. I'll add appropriate labels to that issue and we'll hope someone will pick it up eventually.

[BBaoVanC]

Any news on this? This is sort of a must have feature for me. I feel like it would be reasonable to store the email address for users (maybe requiring a CLI parameter to enable the feature) so email notifications can be sent. Maybe during the first sign in it could ask if they want email notifications, and then the user could provide an email address?

[paskal]

We'll figure out notification subscription reminders for users in the coming weeks, I'll post an update when we'll have one.

[paskal]

No update so far. Right now, it's still a frontend task that no one has yet worked on.

[BBaoVanC]

No update so far. Right now, it's still a frontend task that no one has yet worked on.

I really hope that this can get solved at some point, it's really the only problem preventing me from wanting to use Remark right now.

[reorx]

I'd like to implement this idea by @umputun

this conversation made me think about the ability to have an option "subscribe" as a part of email login flow. Some checkbox (off by default) at the time user performs email login. Not sure if I like this idea or not, but technically should be not too hard to do.

I also want to add the ability to define custom tips under the comment box, so that I can tell the user something like:

It is recommended to login via email, otherwise, you need to subscribe to email to receive reply notifications.

This is not the same as what @BBaoVanC wants (to store the email address after user sign in), but can partly solve the problem that the user expected to receive the notification but don't realize he should do the subscription.

[reorx]

Just showing off some updates, which may include my opinionated ideas:

(The color is purple because I changed the custom-properties.css to make the styles fit my site)

The "Subscribe to notification" checkbox and "Website" input are here. "Website" is used for adding a link to the username or profile image, because many bloggers want to share their own site when leaving a comment.

Currently these changes won't break anything, but there are definitely some works for the backend to understand the subscribe parameter. I want to ask for suggestions first before sending the pull requests, here's my questions:

• Do you think the admonition is nice to have?
• Do you think website input is nice to have?
• Do you think it is necessary to show "subscribe by email" for the simple view? I think it's necessary because the simple view is meant to reduce the complexity of the editor, but subscription is such an important feature; Without it, users cannot receive the updates, which is not suitable for our goal of creating a better place for communication.

All code is in the selfuse and feat/subscribe-checkbox branches of my fork.

[BBaoVanC]

This doesn't handle reply notifications for OAuth users, does it? I think it would require some change in the OAuth sign-in process to ask for an reply notifications (email address) at some point during the sign-in (unless we can read it from the login provider, such as GitHub for example).

[akellbl4]

@reorx I think it's a reasonable point about the subscription buttons. Check #1378

• I think website field is very specific to your own case
• I don't think subscription to notifications should be a part of signup view. If we introduce new methods of notifications it wouldn't work out

[reorx]

@akellbl4

I think website field is very specific to your own case

Agreed.

I don't think subscription to notifications should be a part of signup view. If we introduce new methods of notifications it wouldn't work out

It's OK to me, but since sign up and subscribe are separated steps, users often don't realize they won't get the notification unless explicitly subscribe. Do you have any idea how we can solve this problem? I'm also very interested in the "new methods of notifications", are they related to this topic?

[reorx]

This doesn't handle reply notifications for OAuth users, does it? I think it would require some change in the OAuth sign-in process to ask for an reply notifications (email address) at some point during the sign-in (unless we can read it from the login provider, such as GitHub for example).

@BBaoVanC Currently no, you are correct, if we want to let the user to subscribe by email in the sign-up process, all the auth methods must be able to get the email address, which is a big change for the backend functionalites.

[paskal]

We are intentionally not storing any information aside from username and avatar from auth providers, and I don't think it will ever change: we won't store emails for subscription, subscription will always be a separate step you need to do. In #1174 I'll try to add easier subscription for email users, so it won't require separate verification but will be one-click action.

[akellbl4]

Do you have any idea how we can solve this problem? I'm also very interested in the "new methods of notifications", are they related to this topic?

I see it as it is right now. But maybe we could introduce backend setting that enables subscription to replies while auth process.
In other words subscription for replies by default and then user could opt-out.

@umputun @umputun thoughs?

[paskal]

@umputun proposed to add a togglable ability to show users an email subscription reminder window right after login, with options "Add email" (with email pre-set if login method is email), "Not now", and "Don't show me this again".

@reorx I don't like the design above for the purpose I describe, I think having the "Subscribe by email" element expanded with a checkbox "Don't show on login" would be better as it would be the relevant place for the subscription action: