Discuss: PyWeblog needs a comment system, but how?

[horazont]

Currently, readers are forced to write an email to the author of a blog post, if they want to get in contact. This has multiple drawbacks:

1. Readers are used to leaving comments on a website – they assume comments are impossible or don't even come to the idea of leaving comments if there is no form or whatsoever.
2. There is a larger psychological threshold for writing an email to an author directly compared to writing some text in a comment form.
3. Discussion about a blogpost isn't open.

Fixing this won't be totally easy. We're quite proud that everything works without authentication or authorization right now. We can write blogposts using only git and a text editor, which is really what we aimed for when starting PyXWF.

For commentary, it needs at least some instance which moderates the comments, which, in turn, needs authentication and authorization of that instance. I'd like to keep that out of the blog framework for now. So I wonder what ways we have to manage, moderate and submit comments?

Submission. There have been some ideas around about that.

1. XMPP-MUC, whose log is visible live on the website.

   Drawbacks: Frequent cache invalidation; requires a XMPP client and account for submission; no means to retrospectively manage spam.

   Advantages: Live discussion possible; it's super nerdy.

2. Procmail filter, which catches mails and assigns them to posts based on a +-Suffix.

   Drawbacks: Not-so-frequent invalidation; People need to open their mail-client; No possibilities to easily attach metadata to comments (website, email, …)

   Advantages: Proper moderation queue possible; Completely asynchronous from PyXWF, but synchronous at submission

3. Web form

   Drawbacks: Requires more logic in PyWeblog; Pretty old-school and feels a bit 1990

   Advantages: Easy-to-use and common

Moderation.

1. XMPP bot with some text command interface.

   Disadvantages: Not really usable; Requires XMPP client; Fiddly use

   Advantages: Well, it's XMPP; Multi-User moderation possible; authentication outsourced

2. Simple mailer system. People get an email upon submission of a comment and reply with OK if allowed, otherwise just discard

   Disadvantages: Problematic multi-user interface; Possibly spams your inbox

   Advantages: Simple to set up; authentication outsourced

3. Web-based moderation

   Disadvantages: Complicated to set up; requires authentication and authorization in PyXWF (User Management!)

   Advantages: Easy-to-use; Accessible from everywhere

4. More advanced mailer system. People get an email upon submission of a comment and click on a link to allow

   Disadvantages: Problematic multi-user interface; Possibly spams your inbox

   Advantages: Easier to use than (2); more-or-less simple to set up; authentication outsourced; authorization without authentication (using the (hopefully unique) link in the mail)

5. Git-based management

   Disadvantages: Dependency on external tool; PyXWF must be able to deal with conflicts

   Advantages: Each comment a commit (easy to manage); Fits with the rest of the current usage scheme of PyWeblog; Super-easy multi-user editing

[horazont]

Forgot drawback no. 3: Discussion about a blogpost isn't open.

[horazont]

4th possibility for Submission: No submission at all. Link to relevant XMPP-MUCs for the project being talked about, if any.

Drawbacks: What to do if not bound to a project?; XMPP client required; No directly visible discussion on the website; authors have to watch multiple MUCs

Advantages: Nothing to do in PyWeblog at all

[rku]

Although I like your ambitions to keep comments away from the PyXWF core, the 4th possibility for submission (link to XMPP MUC) is not what users would expect and requires external services/tools along with an XMPP-account (or a web based xmpp client, which is probably worse since it would require client side scripting).

Technically, moderation options 1 and 5 are very nice in my opinion. However, PyXWF is absolutely more than a niche project; If we are looking for a general solution of a comment system, that will be acceptable by a wide range of users, they are probably not applicable. You already wrote down the relevant disadvantages. I am still thinking about how to solve them in a nice way, though.

Moderation-option 2 would require users to open their MUA and write an email. That is acceptable for me but its probably not for the majority of the general crowd. It could prevent rash words, though. ;)

I would go with a combination of submission option 3 and moderation option 4 for a simple reason: Forms are the standard for submitting content to web pages and they are what users expect. They can be styled to look less 1990. After submission, option 4 comes into play. People will receive an email with a hyperlink to activate their posting. Until this link has been clicked, the posting resides in an activation queue outside of PyXWF and will be discarded if not activated within a configured amount of time. This is nothing new and we all know it from other websites. Upon activation, the comment is written to an XML that PyXWF can use as a database for rendering comments. Even though I think this is the best combination of the proposed solutions above, there are indeed some disadvantages that are worth to be discussed. There have to be some mechanics that prevent clients from sending a lot of mails to the outside world (e.g. a host based limit of comments/time) and spamming garbage (not trivial).

If we go for it, PyXWF could provide some general basics to create simple forms and attach a handler for post/get events to them. A comment implementation (plugin?) would then be able to concentrate on the comment-specific stuff.

Despite this suggestion, I have to admit to not being completely happy with this solution. Since we are lacking a better idea and comments would greatly improve our weblog and maybe other projects, I would go for it. The workload to implement it should rather be low.