It's a way for blog owners to handle emailing their readers automatically whenever they make a post. I built this because I actually needed it first, but decided to try it out as a product as well.
Technically it's not terribly complicated – it has a widget which collects emails of your subscribers and it listens to your RSS feed and emails those people when you post. The goal is to make it as hands-off and hassle-free as possible to email out your content to your readers.
Built it in Node.js and Postgres, with Bulma providing the CSS defaults. I vowed to move fast in this project and to that end I decided to stay away from frontend frameworks and build the old fashioned way, with <form> tags! It was actually super fun. I've had my hands on React, Vue, Angular and Ember before, and in all of them I actually never really felt as if it felt as natural as this approach.
Anyways, I'd love to hear any feedback you might have :)
Yes, I do! At present they're not exportable though. I think one part of the product that's nice in that way is that as a subscriber, you know you don't need to think about your email getting spammed - communicating with subscribers is only done as a post is published.
You may want to think this one more through. As a publisher, I would definitely be in the market for your product but the mailing list is the most valuable (and expensive) data set I will be working on for years, and to have it not exportable in the case that you might go out of business or if I decide to use another product is a definite showstopper for me.
I spoke to several blog owners of various sizes. The smaller ones tended to not care about this, but indeed the bigger ones took more of an interest in the actual emails they collect. Just wondering if you'd fall into one of these categories.
Firstly, from a philosophical perspective I am at no point exposing emails of subscribers to the blog owners. The communications they send to those subscribers are limited to what's published in the RSS feed (once per new post).
As for in terms of infrastructure and app design, I contemplated the idea of implementing some kind of encryption or email alias system for a while, but ultimately decided against it. Some basic reasons are the ones also shared in the answers to this question on Stackoverflow:
Since there is no direct access to emails via the logged in user's interface nor is there any kind of public or semi-public database access (through for example an API – the app is entirely server-side rendered), I already limit the damage that can be done through spoofed or stolen credentials (everything from a stolen password to a spoofed or stolen auth cookie).
The database does store emails of course, but the db is isolated from the application on a different server. At launch I used a Heroku hosted database but I'm planning to provision a database environment that is only open to private network IP access.
I'm also definitely interested in beefing it up further. Any advice?
Thanks for the info - it sounds like you've got things locked down pretty well already. The key bit as you say is the fact that the emails are stored on a system that is not publicly accessible.
My biggest worry with anything like this is that if there is a breach at Blogsend that affects the readers of my blog, I'm still responsible for it as I'm the one who put the form on my site and encouraged my readers to enter their email address.
The last thing I want to have to do is use Blogsend to send a "Notice of data breach" email! :)
I've run my own similar system before (just for my blog) where readers could enter their email address, verify it and then receive notifications when I post. However, I discontinued this system as I didn't want the burden of storing personal data like that.
One think you could check out is adding security HTTP response headers - your site is pretty clean and simple so it should be relatively easy to get it locked down tightly. See https://securityheaders.com/.
> The last thing I want to have to do is use Blogsend to send a "Notice of data breach" email! :)
No one wants to have to send any of those emails, least of all me/Blogsend ;)
> One think you could check out is adding security HTTP response headers - your site is pretty clean and simple so it should be relatively easy to get it locked down tightly. See https://securityheaders.com/.
Good question! On my roadmap is a feature where you can have more control over what's sent. So for example whitelist or blacklist categories, set specific send times and for example doing a mailing once a week or day or month (user specified time frame) where the posts of that time period end up in a recap/newsletter/aggregate email.
And we'll have a Gmail add-on submitted to Google within the next couple weeks, so hopefully that will be live by the end of the year. (Since I know a lot of HN folks have reservations about OAuth and have been asking for another way to upload content.)
Doesn't WordPress already do this? Not sure this is very helpful for WordPress users. Although, I do see the use for static blogs and those that do not already send emails when posts are published.
You're right, WP does have several plugins that do this, the most popular being from providers like ConstantContact and Mailchimp. I think I'd expect a few WP users but you're right, my target are probably people that are using something like Jekyll.
Nice project! I currently do the same with Mailchimp, I have a mailing list and they support creating newsletters from RSS. Does your project have advantages over that?
Yes indeed, MC does this pretty decently. I tried it myself, but I found the product is very much catering to marketers. Which is fine, of course, but for people that only want this functionality, it seems like overkill.
Blogsend is meant as a much simpler, more focused alternative. This is all it does, and the features to be added in the roadmap are almost exclusively to help bloggers, not marketers or a general audience.
Not to detract from the project, but is there much demand for this? Anything that's emailed to me is generally lost in my mailbox or purposely ignored... when I want to read a blog, I'll go to the blog.... I don't want more emails.
Why don't you clean your inbox and setup some filters? I'd say 99% of the emails I get is relevant. Blog posts from blogs I actually signed up for is great to get. And if you start to dislike it it's 1 click to unsubscribe.
Have you considered the recruitment use case? Many staffing agencies advertise jobs on their website but don’t have the job alert functionality a job board would offer. If you turn this into a “alert me”, the next time they post a job matching the criteria you’ll email candidates for them. Same technology, just a different niche - one that I think will be more profitable.
Looking at the spec, it appears to differ from RSS/Atom in very small ways (besides being in a different data format). It would be pretty trivial to build in support for this.
It's difficult to find usage stats since searching for "json feed" unfortunately gives a whole lot of unrelated things!
I think if I can find a paying client that wants it, I will build this in. Wanna be the first? ;)
33 comments
[ 3.1 ms ] story [ 142 ms ] threadIt's a way for blog owners to handle emailing their readers automatically whenever they make a post. I built this because I actually needed it first, but decided to try it out as a product as well.
Technically it's not terribly complicated – it has a widget which collects emails of your subscribers and it listens to your RSS feed and emails those people when you post. The goal is to make it as hands-off and hassle-free as possible to email out your content to your readers.
Built it in Node.js and Postgres, with Bulma providing the CSS defaults. I vowed to move fast in this project and to that end I decided to stay away from frontend frameworks and build the old fashioned way, with <form> tags! It was actually super fun. I've had my hands on React, Vue, Angular and Ember before, and in all of them I actually never really felt as if it felt as natural as this approach.
Anyways, I'd love to hear any feedback you might have :)
You may want to think this one more through. As a publisher, I would definitely be in the market for your product but the mailing list is the most valuable (and expensive) data set I will be working on for years, and to have it not exportable in the case that you might go out of business or if I decide to use another product is a definite showstopper for me.
Just out of curiosity, what size is your blog?
I spoke to several blog owners of various sizes. The smaller ones tended to not care about this, but indeed the bigger ones took more of an interest in the actual emails they collect. Just wondering if you'd fall into one of these categories.
My main concern with anything these days is security. Do you have any further info on how you secure the email list that you store, etc?
Firstly, from a philosophical perspective I am at no point exposing emails of subscribers to the blog owners. The communications they send to those subscribers are limited to what's published in the RSS feed (once per new post).
As for in terms of infrastructure and app design, I contemplated the idea of implementing some kind of encryption or email alias system for a while, but ultimately decided against it. Some basic reasons are the ones also shared in the answers to this question on Stackoverflow:
https://stackoverflow.com/questions/767276/what-is-the-best-...
Since there is no direct access to emails via the logged in user's interface nor is there any kind of public or semi-public database access (through for example an API – the app is entirely server-side rendered), I already limit the damage that can be done through spoofed or stolen credentials (everything from a stolen password to a spoofed or stolen auth cookie).
The database does store emails of course, but the db is isolated from the application on a different server. At launch I used a Heroku hosted database but I'm planning to provision a database environment that is only open to private network IP access.
I'm also definitely interested in beefing it up further. Any advice?
My biggest worry with anything like this is that if there is a breach at Blogsend that affects the readers of my blog, I'm still responsible for it as I'm the one who put the form on my site and encouraged my readers to enter their email address.
The last thing I want to have to do is use Blogsend to send a "Notice of data breach" email! :)
I've run my own similar system before (just for my blog) where readers could enter their email address, verify it and then receive notifications when I post. However, I discontinued this system as I didn't want the burden of storing personal data like that.
One think you could check out is adding security HTTP response headers - your site is pretty clean and simple so it should be relatively easy to get it locked down tightly. See https://securityheaders.com/.
No one wants to have to send any of those emails, least of all me/Blogsend ;)
> One think you could check out is adding security HTTP response headers - your site is pretty clean and simple so it should be relatively easy to get it locked down tightly. See https://securityheaders.com/.
Thanks for the tip! I've added this to my todos!
https://cl.ly/709c92e9ca7b/Image%202018-11-20%20at%2011.12.4...
Get this:
https://cl.ly/eac5828099c5/Image%202018-11-20%20at%2011.13.2...
In addition to sharing on social, it also supports embedding email threads directly within Reddit threads, Medium posts, etc., e.g.:
https://medium.com/to-the-best-of-our-knowledge/were-not-ok-...
Here are some video tutorials showing more functionality:
https://www.youtube.com/playlist?list=PLJAEYmnEjIu4--bpq5LSK...
And we'll have a Gmail add-on submitted to Google within the next couple weeks, so hopefully that will be live by the end of the year. (Since I know a lot of HN folks have reservations about OAuth and have been asking for another way to upload content.)
Blogsend is meant as a much simpler, more focused alternative. This is all it does, and the features to be added in the roadmap are almost exclusively to help bloggers, not marketers or a general audience.
plus we take privacy very seriously, which is an added bonus.
edit: here is a link to our FAQ: https://www.gibbonwire.com/about/faq/
and our privacy policy: https://www.gibbonwire.com/about/privacy/
Considering you've already done the hard work of parsing RSS, do you plan to support JSON feeds at some point?
Looking at the spec, it appears to differ from RSS/Atom in very small ways (besides being in a different data format). It would be pretty trivial to build in support for this.
It's difficult to find usage stats since searching for "json feed" unfortunately gives a whole lot of unrelated things!
I think if I can find a paying client that wants it, I will build this in. Wanna be the first? ;)