The making of email notifications
Continuing from last article about notification model in my blog - which unfortunately could not be demonstrated publicly. I will be implementing the email notification for guest comments.

Email ethic

There are several concerns on sending email to someone.
 - only do what is told
 - always assume NO
 - The word "unsubscribe" should always be visible
 - no fancy html style
 - be humble

How I hate about getting forced to subscribe before actually getting what I want. Even they checked "YES, I WANT TO RECEIVE NEWS LETTER!". Don't
believe it. From my experience, people only want to know WHEN they want to know. Sending emails to them on every newly published article will only get you marked as spam. Because  99% of the time what you did is shit. Admit it!

What I want to do this time is adding this little checkbox:

The checkbox was easy. But the inner working behind it was not.

~ a week later ~


Welp, didn't expect it was this hard to implement. Here I'll briefly explain what I did and why did I struggle to do so.

Cookie-less

Guests are mostly coming from search engine, which they are mostly searching for something. I'd bet most of them wouldn't stay in the same page for more than 10 seconds. And never come back again. Storing useless information on their PC might not hurt, but if every site are doing the same thing and creating junks are just like factories dumping CO2s into the environment.

So I'll have to avoid using cookies for just this information. No cookies means no sessions, which also means no authentication was involved, which in turns making it hard to identify them. The sole identity for each commenters is their email. Which is assumed to be unknown to others. Thus their email is the top secret in this blog. I'll need to be extremely careful of what I'm doing when manipulating this info.

( But hey, storing name and email is good enough to trace their internet identity. So this is just a self-deception to be honest. )

First is the subscription flow. A guest makes a comment, checked "notify me". Then replies to this comment will be trigger a notification email be sent on this address. The basic flow looked like this:

There will be two kinds of email to be sent based on the condition of the comment reply.

Verification Email

This type of email will only be sent when the address is not recognized by the system. This is because I don't want my blog spamming on an invalid address and wasting internet resources.

Notification Email

Actually the entire system is meant just for this email. Notification emails will be sent for all verified subscribers.

Subscription management interface

Anything related to user interface is hard. Because people are assumed illogical and will do all the stupid shits, which, the system should handle all these cases.


Requesting token


In case of people forwarding the email to other people. Having a direct *Unsubscribe* link within the email is not practical. So for subscription managing, there must be a discrete just to raise the awareness of people that they are dealing with the information which must be acknowledged by themselves.

Hence the request token flow.

Managing subscriptions

Once a token has been requested. A management email will looked like this:
Dear Sir / Madam,

You'd probably just requested a management token to manage subscription for this email address from my blog.

Click this link to manage your subscriptions:
https://blog.astropenguin.net/subscription/manage/<random-generated-key>

If this was a mistake, *click this link to ban your email address for all messages from my blog*:
https://blog.astropenguin.net/subscription/ban/<random-generated-key>

Once banned, this address will also be banned for subscribing any messages from my blog. This action cannot be undone.

Regards,
斟酌 鵬兄 ( penguin )
Since guests can only unsubscribe or have their address banned from my blog - suppose this key is not leaked. Users with access to this link will have permission to manage their subscription.

The management interface looked like this:

Guest can unsubscribe / resubscribe with the current subscriptions.

This costs additional 1000 lines of codes in backend just for this impl.
AstroArch: ~/works/blog
$ git diff HEAD^ HEAD --shortstat
 28 files changed, 1042 insertions(+), 48 deletions(-)

For the frontend. I'm reusing exists assets. I think BotanJs is finally making returns!
AstroArch: ~/works/astrojs
$ git diff HEAD^ HEAD --shortstat
 5 files changed, 76 insertions(+), 8 deletions(-)
Profile picture
斟酌 鵬兄
Wed Oct 26 2016 07:21:40 GMT+0000 (Coordinated Universal Time)
Last modified: Sun Apr 10 2022 12:19:13 GMT+0000 (Coordinated Universal Time)
Comments
No comments here.
Do you even comment?
website: 
Not a valid website
Invalid email format
Please enter your email
*Name: 
Please enter a name
Submit
抱歉,Google Recaptcha 服務被牆掉了,所以不能回覆了