Forum OpenACS Development: Commenting for casual browsers

How can we make commenting easily available to casual browsers?  This has come up in other places under the label "anonymous posting."  In a recent thread (https://openacs.org/forums/message-view?message_id=160672), a solution was proposed for forums where we simply grant appropriate access to user_id=0 ('Unregistered User').  This is a great solution, lets the permissions system really shine, and works similarly to "Anonymous Coward" systems on other bboard tools.

Weblog comments work a little differently.  It's sort of like registration, but simpler.  Commenters enter their name, email address, (optional) URL and comment.  Then they send everything with a single click.  As an example, here is what the interface for Movable Type (MT), a popular blogging tool, looks like: http://grumet.net/weblog/archives/2004/03/09/000688.html.

IMO this interface is pretty friendly and worth copying.
But in order to enable this, we have to figure out where to store the information.

Option #1 is a helper table.  Subject to enabling by a parameter, we would assign creation_user=0 to comments by unregistered posters and store name/email/url in a table called "general_comments_unreg_post" whose primary key refers to general_comments.comment_id.  This leverages the permission system in the same way as the forums approach described above, but now provides an opportunity to put a name next to every comment.

Option #2 is to provide a low-barrier way to get data into standard system tables.  My first thought was to create a "minimal user" with a null password etc.  It might work but makes my skin crawl a little.  Tracy pointed out that we could create a "person" object instead.

Both options have some implied buildout of general-comments and the packages that consume it.  I've partially implemented Option #1.  It works fine and doesn't break a huge number of assumptions.  Option #2 has the potential to be cleaner, since the person and party tables pretty closely match the data we want to store,  but I haven't investigated it carefully yet.

I'm curious to know if other find this interesting, would support it, object, or have other reactions.

Also be aware that Dave and Jun are both working on general-comments (the partial work is in contrib) ... is there some possibility of enabling "person" comments and improving the UI or possibly providing an optional "comments lite" UI or the like?  General-comments is perceived as needing improvement, which is why Dave started on an improvement project (and why Jun recently joined him), so if at all possible the very best solution would be to fix this general facility.

And comments by unregistered persons such as you describe is an option that other packages might benefit from.  If it's good for blogs (are we sure it is? that's another question, I guess) it should be good for photo-albums and similar packages.

I realized there's a dark side to using a person object, that bears mentioning.  Because we're dealing with unauthenticated users, we want to give them as little power as possible.  Imagine that we implemented the logic as follows: when a comment comes in having email address mailto:joeuser@rcn.com, we look for a person record a matching email address, create a new person if there's no match, and update other info if there is a match.  Say mailto:joeuser@rcn.com's name is "Joe User".  We'll see that name next to all of Joe's comments.  Now suppose a malicious person comes along and sends a comment as mailto:joeuser@rcn.com but with the name set to "Joe LUser".  Joe's name gets changed everywhere.  Oy.  The helper table approach stores one row per comment, so a malicious impersonation would at worst affect one row.

Don, I think it's reasonable to ask whether opening up comments to unregistered users is good for blogs.  It makes commenting a lot easier which can be both good and bad.  What I can say is that this interface is pervasive in the blog world, so people looking at OpenACS' blog capability would expect it.

If you enabled commenting per object you could do some interesting stuff. When a user creates content, they could check a box to enable comments on their content. Then any user/non-user could send a comment which would be 'moderated' by the content creator. In essence, you delegate administration and responsibility to a registered user.

"We've included a throttling measure so that comments from the same IP address can only be posted every N seconds, where N is configurable. We've also added a measure to automatically ban an IP address based on an abnormal number of comments from the same address in a short period of time."

So if you go that route (i.e. not create a person) I'd suggest specializing the general-comment object type as a "unregistered_user_comment" or the like.  Note that you end up with exactly the same select queries to grab data but conceptually it's cleaner.  Or, if it's not, the object type system is useless :)  We should really extend types when that's what we're doing, IMO.

The obvious approach in general-comments, then, would be to create an object of one type or another.  I'm assuming that registered users - those logged in at least - have comments posted as they are today.

The query can return the e-mail and similar info with a UNION subselect in the rowset specifier, pulling it either from the person/user table or extended type table.  The code would have to guarantee that there's a row in persons/users or the "unregistered_user_comments" type-specific table to guarantee the UNION only returned one row.

I think this would be a really easy feature to add to general-comments.

Two further arguments against the "person" approach:

1. opens a system to a nasty DOS-type attack, if spam is bad just adding comment rows it will be two or three times as hard on the system if a new person is added for each one, and cleaning up afterwards will be at least twice as hard.

2. more code would need to be written - code that needs writing anyway if anyone ever uses "person" - because once you start creating "persons" in the db the user registration code needs to be able to transform them into "users" ...

I like Walter's idea of requiring authentication to update the info.  Perhaps it will be a forcing function that gets more party-management code written.  Don's right, though, it makes robot attacks worse.  Janine, yes this would definitely have to be turn-off-able.

Let me try to think further about dealing with attacks.