Designing a commenting system with data ethics in mind

Sebastian Greger

A year ago, I launched an exploratory attempt to integrate comments and webmentions with Kirby CMS. Far from being a stable product, it was about time for a major update based on the collected insight and feedback.

tl;drCommentions, my com­ments and webmen­tions plugin for Kirby 3, receiv­ed a major overhaul and redesign.Commentions on GithubCommentions 0.x was never intended to be a universally applicable Kirby plugin. Quite the opposite, it was the testbed for a range of ideas and approaches, with the purpose of collecting feedback.

“Research through design”, as Christopher Frayling’s classic essay would frame it: exploring a field of design by hands-on working with the material. Others may call it “tinkering” or “prototyping”, but no matter the label this has been a worthwhile exploration indeed.

Quote from Frayling's text
To me, reflection on and sharing of the design process is equally important as this projects’s outcome in code. By engaging with a technology, the design researcher learns more about a topic than by purely theoretical analysis. [Quote from Frayling’s text.]

How the first beta came to be

The starting point of the inital draft was an identified need: with comments not part of the Kirby core, building a custom solution leads right into an uphill battle with fast-growing complexity. Even more so when this includes a webmention endpoint, allowing others to post comments by replying on their own blog, and is driven by ambitious goals in terms of “privacy-first” design (admittedly a paradox of sorts, while hosting other people’s content).

Capture of the spec chapter on
Working with the Webmention specification comes with numerous “shoulds” and “musts” — this puts a lot of moral responsibility on the designer as this is all about handling personal data.

As feedback on the experiment — with some brave hearts using it on their websites — started to trickle in, two things became apparent:

  1. While the target audience widely appreciated its opinionated defaults, there was an understandable demand for adaptation. Yet, certain conceptual limitations of the initial design rendered it difficult to adapt beyond its default use case.
  2. Some underlying assumptions rendered the prototype hard to extend incrementally. While the feedback provided ample ideas for building a stronger base (special thanks to Holger for a particularly fruitful discussion on value-driven design in practice!), this would require a major rewrite.

Reframing the plugin

Since the initial version had been neither intended nor presented as “ready for production”, the lack of universal applicability was nothing to worry about, and essentially to be expected. What I did not quite expect was the preparedness of the Kirby community to provide feedback. Over long email exchanges and even Skype calls, the concept for a more mature design began to evolve.

Two of many lessons learned:

Ethical software without restricting its use?

Even when generally agreeing with the underlying values of an opinionated design artifact, such tool is more useful when designed in a way that is open to being hacked (technically, not just by license).

An example: one key assumption for the prototype was that comments would always be reviewed and manually approved to maintain control over including third persons’ content on a website. Yet, there might be use cases where that is not necessary. Storing feedback in the same file with the page content, the design could not adapt as automatically updating content files may lead to conflicts and data loss if simultaneously being edited in the admin panel.

Every CMS has its own culture

Back in spring 2019, the Kirby ecosystem was a rather new environment to me. It took this exercise to fully embrace the spirit of this alternative CMS: Kirby developers often prefer plugins that provide enabling infrastructure rather than ready-to-use complete solutions. This is an aspect that takes a while to internalize, especially after working in the realm of Wordpress (where plug-and-play appears to be much more the default).

So, while the aim remained to provide something that a first-time IndieWebCamp attendee could have up and running in a matter of minutes and with reasonable defaults, the final Commentions concept would have to rest on a solid “kirbyish” framework.

Stepping out into new waters

Hence, as I set out to create the long-envisioned “Version 1.0”, the focus had shifted

  • …from providing a rather narrowly specified single-purpose plugin to creating an enabler framework with built-in defaults for convenience. Instead of providing only one way of using it, the plugin should focus on data storage, webmention handling, and comment management; the pre-configured frontend templates are merely an easy entry point.
  • from “limitation by design” to “encou­rage­ment by design” in terms of privacy and data ethics: rather than rendering certain practices outright impossible, provide all the tools and (opinionated, no less) defaults that promote and enable responsible conduct. In other words: allowing people to intentionally weaken the defaults, instead of have them turn to less privacy-considerate solutions entirely.

Sendmentions notifies other websites of published articles: Webmentions, Pingbacks, and archive.org requestsSendmentions on GithubAmong the things that had proven themselves “keepers” were the complete self-reliance with no remote dependencies, the separation from outgoing webmentions (covered by the companion plugin Sendmentions; also recently refreshed), the data-minimalist approach in general, and the belief that opinionated defaults encourage reflection on data practices some may not even question otherwise.

All design insight and technical learnings aside: the main takeaway from working with the prototype were fruitful discussions about considerate handling of user data in the context of website feedback; maybe being overly restrictive in the first concept actually led to precisely the conversations I was hoping to have? After all, my field of work is not software development, but researching and advocating privacy-by-design and design ethics.

Presenting Commentions 1.0

Fabian’s perspective on the project can be read on his blog.Working on the redesign on and off over the past year, I finally made some time to wrap it up over recent months. After exchanging Commentions-related emails since last summer, Fabian Michael eventually provided the final push by joining the effort as a sparring partner in design questions and by contributing invaluable technical expertise — most importantly, though, because working as a team is always more inspiring. This (entirely remote) collaboration has been a great experience, and it made the product so much better!

Screenshot of the comment form.
One thing that has barely changed at all is the default comment form shipped with the plugin.

Versatility in concept and architecture

A handful of things have changed significantly from the previous version:

  • All plugin data is now stored in a separate file structure within each page’s folder, decoupling content from interactions. This opens new doors to automation and further integrations, but most importantly extends the plugin’s functionality to virtual pages, a powerful Kirby feature.

  • The plugin now enables developers to process stored data in custom ways:

    • Instead of the prototype’s rather clunky array, stored “commentions” can be accessed as a Kirby structure object, unlocking a wide range of methods to process the data; custom frontend templates are just one of many solutions $page->commentions() facilitates.
    • Various hooks allow to intercept the handling of incoming entries, or to trigger additional actions as they are processed; for example enabling to build an email notification system with a few lines of code using the commentions.add:after hook.
    • API endpoints allow building custom panel plugins or remote integrations; if desired, the plugin could literally be used as no more than a storage and processing infrastructure for comments.
    • The advanced processing of HTML content (from webmentions) and comment text (now enhanced by supporting Markdown) gives the admin more control over formatting and security aspects of third-party content on their site.
  • It turned out that the integrated handling of webmentions was one of the plugin’s most valued features; hence effort was put into making this even more robust. Most significantly, the plugin now processes updates to existing webmentions and, as an important privacy-enhancing feature, deleting webmentions by the author is supported as well — putting authors in permanent control over their content (once they update or delete their post and send another webmention, the Commentions data storage reflects that, as specified).

More control, with improved interfaces

In addition, the plugin received a complete overhaul of the Panel interfaces and some internal processes:

Screenshot of the panel section
The completely rewritten panel interface provides an easy overview and full control over a page’s comments and webmentions.
  • We designed and created custom panel sections to provide better control over the data; numerous ideas had to remain on the roadmap for now, but the newly designed interfaces make it a lot more pleasant to review, approve and edit comments and webmentions.
  • Even more configuration options empower the site owner to fine-tune how submissions are treated; comments and/or webmentions can be enabled and disabled by template, auto-approval can be tailored to certain content types only, etc. Some of these can even be adjusted on a per-page basis, for example to close comments for certain entries or only accept but not display them publicly.
  • Last but not least, significant effort was put into thorough documentation, to enable developers to work with the plugin as it fits their needs.
Screenshot
A new edit dialog allows for easy adjustments to the data of incoming comments and webmentions.

Questions of data ethics remain at the core

Yet, with all the newness and shiny surfaces, the foundation remained unchanged. Respectful treatment of other people’s data is a core value, with rather restrictive defaults and a growing number of means to support data minimalism and keep commenters in control. For instance, the already minimal number of default fields can be reduced further.

As a matter of fact, if there is one thing I still hope to gain from this project in the future, it is the further exploration of how comments and webmentions fit into a data protection and privacy mindset — a topic that does not come with easy answers. Self-hosting these functionalities is a big first step on that journey, but ultimately this tool has to prove itself in use. Or, as the Readme states:

Data ethics or “GDPR compliance” are never created by software, but by the way it is used. While this plugin aims to provide means for its responsible and legally compliant use, responsibility for ethical conduct and compliance with applicable laws ultimately rests with the operator of the website (aka. “the data controller”).

Outlook: Beyond comments

In the long run, I believe that the true design challenge that is “web comments” is not primarily one of technology. This is easily overlooked in the attempt to create software that processes feedback and presents it in a way that supports a publisher’s goals — be it substantial debate or sometimes just vanity.

The real question is how to enable genuine, valuable, and safe interactions between authors and readers; keeping individuals in full control over their interactions and content while facilitating discussions as they unfold is a tricky task. The ideal solution might well be something completely different than we imagine today — likely far beyond the “facepiles”, “likes” and “reposts” the social media industry has established to maximize their stock value. And, while perceived as an imposition by many, I believe that strict privacy regulation can be a key driver in reimagining these solutions.

Designing for social interaction is an exciting field (I once used to refer to it as SxD, or “Social Interaction Design”). Communities like the Indieweb, the Fediverse, and others, are constantly experimenting with the future of open interactions (read: outside of surveillance-captialist, ad-financed networking silos) on the web; one such contribution I recently enjoyed is “Towards a Commenting System” by Matt Baer:

One assumption this design operates on: the idea that no one has the right to publish whatever they want on your blog [in the form of a comment]. So for example, when replies are eventually published to your blog, they’re in minimal form.

[…] the off-the-shelf “blog” should be a place of peace and quiet. It should facilitate human connection, yes, but without succumbing to chaos and spam.

…maybe there are already some ideas for Commen­tions 2.0 hatching in Matt’s work? Similarly, a current “gardens vs. streams” debate (critically reviewing some aspects of chronological posting) has brought forth fresh perspectives about the role of comments in the future web. Neil Mather summarized some interesting thoughts on that:

Webmentions would work for this too – as just a simple ‘mention’, not necessarily a comment. Salman would be notified automatically that your note references his note. Salman could choose to display it as a backlink, if he liked.

The utility is in how much it can facilitate networked thought.

Curious? Give the Commentions 1.0 Release Candidate a try — and don’t hesitate to write a reply on your own site and send a webmention this way, especially if you have thoughts on comments on the web of tomorrow…

Footnotes

  1. At the time of writing, two plugin alternatives to Commentions exist for Kirby 3: Komments and KirbyComments, each with their own distinct approach.
  2. This is why it took a year to reach the next stage.
  3. For instance, if non-textual replies such as “likes” are presented in a privacy-preserving way; e.g. by just showing a “like counter”
  4. Redesigning and future-proofing the data storage was the biggest single obstacle in developing the intial version further.
  5. A migration tool assists with the migration for any users of the old 0.x version.
  6. As there is no canonical guideline for storing plugin content in Kirby, finding this solution was the result of discussions within the community, in this exchange on Github and beyond.
  7. Enabling DIY, these hooks also take pressure off this plugin to provide an ever-growing amount of features: win-win!
  8. Not storing anything beyond the absolutely necessary also makes GDPR compliance a lot easier to achieve
  9. Ethical (and even legal) concerns around the re-publication of other’s content and interactions have repeatedly been a topic at IndieWebCamps as well, e.g. Nuremberg 2017 and Berlin 2018; while a variety of opinions exists, this question currently remains for every site owner to be solved individually.
  10. If there is one single term that highlights dehumanisation of language in SNS design (no surprise this appears to have emerged from Facebook), it probably is “facepiles”.