This is a Request For Comment on a workflow solution to allow readers of a static site blog to post comments.
A recent trend for blog owners (especially technical blogs) is to use static site generators. These frameworks allow the blog owner to author blog posts in a convenient format (Markdown) and generate a full HTML website that can be uploaded to a web host or GitHub Pages. The advantage is that the output requires no server side programming and no need for a database.
Although JavaScript is available client side the lack of a server side system to build the HTML dynamically means readers can not post comments to the blog. The most popular solution to this problem is Disqus which uses client side JavaScript to capture a comment and store it on their third party server so that when the JavaScript is executed it can render the dynamic portion of the page with the comments stored in its database.
Essentially this hasn't really changed the nature of a site being rendered dynamically other then it is isolated to a section of the markup and manged by the client side JavaScript instead holistically by the server side rendering that hosts the original source.
Overall the advantage of a static site is that the blog owners servers do not need to worry about server side applications and can focus on serving simple files. While the commenting is handled off site dynamically by a third party.
Disqus is a well known third party commenting system for static web pages. It links it's database of comments based on a key provided by the static HTML source. Placing this key in the markup along with the required client side JavaScript code it contact Disqus servers and receives a list of comments that it then renders into the page by manipulations the DOM. The advantage is that the comments never need to manged by the blog owner.
Some disadvantages with this system is that the comments associated with a blog post are not part of the post source. This means that they are an afterthought and wouldn't be included as part of the blog posts pose nor is it search able by indexers and spiders.
Having the comments with a third party adds an extra step for the blog owner to manage and moderate. They have to go to another management site for just the comments while changing context working on the site's source.
Another disadvantage to having a third party render the comments is that the blog owner no longer has control on how comments are styled, rendered, or interacted with. You are stuck with the themes the third party offers which can make the comment section that is added to the page look distinctly different then the rest of the page. Comments also can not be interlaced into the blog post or customized in appearance.
Third party commenting systems are also tightly couples the blog post's URL to
the comments. If a post changes location the comments do not follow well. An
example might be if the blog owner wanted to move from static files
(http://example.com/2015/10/15/my-spiffy-post.html) to a client side routing
system (http://example.com/#/posts/my-spiffy-post.html) the comments would
break.
Lastly, in the case of Disqus their client side library that manages the comment integration into the rendered page makes some gross assumptions. It must be a static page. It assumes that when the reader views a new post that it is a complete page reload. In the example of a client side routing system (like Ember.js or Angular) this assumption breaks the underlying workings of Diqus. A fair amount of (for lack of a better term) hackery needs to be performed to make the Disqus JavaScript behave correctly and in many cases it just isn't possible to accomplish adequately; often limiting the blog owners' site design to fit with in the requirements posed by the third party commenting system.
Described in the attached diagram the purposed system moves the storage and maintenance of comments into the original static source files. It does this though sending patches to the blog owner to be integrated as part of the blog post itself.
This is the same workflow used for typo fixes. Most static sites I've seen have a request to send changes via GitHub Pull Requests or to send a patch via email. The source is version controlled (typically with Git) and the blog owners would be more then overjoyed when readers could take the time to open a pull request or send a unified diff to them via email. However, comments have always been left out of this workflow.
This purposed system would integrate the ability to write a comment on the page and have it manifest as a pull request or patch to the blog owner. Giving the blog owner an opportunity to moderate, review, and eventually integrate into the blog post itself.
By providing a change request (via a pull request or email patch) the blog owner has control to moderate, censor, or edit the comment.
Commenters do not need to manage a separate account on a third party. Commenters can claim credit for their comment through the already established means of a Git commit message.
Blog owners can easily manage comments and comment removal though already used version control. Allowing accounting and auditing opportunities.
With the comments as part of the page the comments' content is now searchable to indexers offering a broader reach and possibly more participation and reader interest.
The basic workflow is described by the attached diagram.
Email notification management is handled by collecting the list of contributors to the page and filtering that list by who has opted in to receive notifications
To be safe from storing emails on the static markup they are hashed and reference by hash only. The only place the actual emails are store are in the Git log which is okay since that is either private to the blog owner or hosted publicly on repository sharing site like GitHub. Spam bots won't be able to associate a scan of a web page with a commit message hosted on another server. (If so they are already scrapping GitHub irregardless of the bog owner's site). This also means that a commenter could choose how they want to be associated with the comment. Git has the ability to construct git commit messages without verifying the emails used to author a change it (feature?) and so the commenter has full control on how they manage their identity. They choose the display name and email to associate with. This is no different then submitting a GitHub pull request with their GitHub account. Or sending an email from their email client.
One option would be to take the produced patch file as the body of a mailto:
link so the commenter send emails from their own client. Or (more likely) send
emails from the commenting system masquerading as the user who entered the
comment. Perhaps a mailing list could be used to manage this?
The advantage in my mind with regards to classifying comments as nothing more
then a code change (patch) means the tools that both the commenter and the blog
owner already use are exercised in the workflow of adding comments. Additions,
deletions, and edits are just a pull request or patch. It is essentially the
same concept as contributing changes to an open source project only the
interface is designed to be nothing more than a text box on the page instead of
a full featured code editing environment like a git clone or GitHub pull
request would be. The complexity can be automated which lowers the barrier to
commenting significantly while removing the need for yet another system to
manage everything.
A static blog is already static, the content contributed to it should also be static. Mixing the two in anything other then the most simplest context is complexity that I and perhaps many other blog owners would like to avoid.
