Chris puts forth the argument that gravatars should humanize the web. I agree with his premise, but not his conclusion. Gravatars should help personalize the web, and not necessarily humanize it.

Self Expression

Blogs are all about self-expression. Everything about a blog -- from the blog engine, to the layout, to the links, to the main content -- tells us a little about the owner. Likewise the comments left by others reveal to us who else reads the site, from which we can infer even more information about the blog owner. If you read a lot of blogs, chances are that you'll see any particular blog owner leaving comments elsewhere, too, which provides still more information about the person behind the blog. None of this has anything to do with what the blog owner looks like.

We don't get to know people off-line just by their appearance. We get to know them based on their style, their idiosyncracies, and their mannerisms: things they do and not just things they are. So in a sense, a gravatar is just a kind of internet tee shirt to complement the mannerisms presented on a blog or comment. A gravatar, just like a catchy handle or a unique blog layout, tells a lot more about the person than what they look like can ever reveal.

Identity

Chris closes with I am a person and I have something to say, and I should not be afraid to say it... as me.. Clearly Chris wants to synchronize his online identity with his offline identity. I'm generally striving for the same confluence, but that's not what everyone wants. Some seek pure escapism; others seek a refinement or exaltation of their everyday self. Still others want pure anonymity.

The internet allows people to put forth the identity they want others to see. If someone wants to present an anime character as their gravatar, then I know something about that person that I would never know just from looking at their photograph. Moreover, our identities are rarely immutable. Instead they grow and change subtly over time as we experience and learn new things. Should our gravatars be flat, static pictures?

A gravatar, as a type of avatar, is something more than just a representation of a person's physical characteristics or some thing(s) in which they're interested. It's an archetype, an "ideal example", of something. A photograph of ourselves seems to fall short.

Community

Chris talks about people, but he doesn't mention community. The internet presents tremendous opportunities for communities to develop and flourish. As social creatures, our identities, or at the very least how we express those identities, shift slightly based on the contexts in which we present them. The self we present on a joke-sharing blog may be very different from the self we present on a tech-support blog. The "face" I apply to comments on my own blog might be very different from the one I use when I comment on someone else's blog.

In some contexts, we want to show our affilitations, which have nothing to do with how we look. A close-knit group, like game clans for example, could coordinate gravatars among their members, using their in-game identities on a discussion. A veterans group might want to display an insignia. A group project -- something fantastical like Ghyll or something serious like Wikipedia -- might merit a different presentation of our identity than our personal blog.

An Identity Infrastructure

Since gravatars are keyed off of email addresses, one could (conceivably) register several different gravatars against several different email accounts: one for a personal account, one for a GMail account, etc. Thus when posting a comment the commenter could choose -- based on comment content, or some other factor -- which visual representation of their identity should be applied to their comment by selecting the appropriate email address. Over time, though, this becomes tedious; and it forces us to adapt to the tool instead of the other way around.

And gravatars aren't just for blog comments. Gravatars are tool-agnostic, and can be leveraged in almost any online community context. I can envision a Mozilla Thunderbird extension that displays gravatars on email messages (akin to X-Face from days of old). Some instant messaging clients already support "buddy icons", which should easily be extended to support gravatars.

If gravatars represent an infrastructure for expanded self-expression and identity, does it really make sense that each person must use multiple email accounts to represent all of their gravatars? Certainly the single-gravatar-per-email encourages people to think a little more about what they use for a gravatar, but it imposes an artificial restriction.

A Solution

I like the idea of gravatars, but I don't like being required to use one gravatar for every site. I'm sure others don't either. So I've modified the original WordPress gravatar plugin. Here's what my version does:

• caches gravatars locally for a user-specified period of time (seven days by default)
• presents a web-based interface for configuring default gravatar settings
• allows blog admins to enable or disable local gravatars
• allows registered users to define local gravatars that override their gravatar.com default
• allows blog admins to see a list of local and cached gravatars
• allows blog authors to use gravatars in the body of their posts

In a sense, this plugin strays pretty far from the original idea of a globally recognized avatar. But in another sense, it greatly expands it. Not only does this pluign make the gravatar infrastructure more resilient by distributing where gravatars are stored, it makes gravatars more flexible by allowing site-specific gravatars. It is my belief that this aspect will encourage more people to register for blogs, something which currently doesn't offer much benefit. It is my hope that registered users will grow into contributing authors, making blogging even more interesting than it is now. And finally this plugin makes gravatars something much more than just comment eye candy, by making them available inside the body of a post.

Gravatars may help make the web more human; but I'll be happy with them making the web more personal.

Download the plugin at my Gravatars plugin page
This plugin only works with WordPress 1.5 and above.
Thanks to Vidar for testing this plugin!

Announcing subscribe2!

This plugin provides a comprehensive subscription management system for WordPress blogs. Visitors can subscribe and unsubscribe through a convenient web-based form. All requests require confirmation by email.
Administators can configure the email template used for new post notifications, as well the messages used for (un)subscription requests. Admins can also subscribe or unsubscribe users, as well as send out an email to all confirmed subscribers.

Download subscribe2-2.1.4.tar.gz
Download subscribe2-2.1.4.zip

This version integrates with the new WordPress 1.5 admin bar, while preserving backward-compatibility with WordPress 1.2.
This plugin now requires WordPress 1.5 or above. You will also want to make sure you resolve bug 902!

Notable changes:

• A README!
• Automatic installation!
• More customizable!
• Theme support!
• Web-based administration for almost everything!

Once you extract the files and activate the plugin, you'll need to create a link somewhere pointing toward subscribe.php. You can manually edit your index.php (or sidebar.php or footer.php), or you could use the WordPress Links manager.

All user requests require a reponse to a confirmation email, to thwart hooligans trying to (un)subscribe people against their wishes. Those darned hooligans...

Thanks to aalex and BigJibby from #wordpress on irc.freenode.net for their troubleshooting assistance. Thanks also to everyone who's contributed to the development of WordPress.

UPDATE: I realized I had forgotten to update the permalink in the plugin's description field to point to this entry. While fixing that, I realized that I had also made a rather serious mistake in how I handle 1.2 users. I've fixed that as well, and am releasing version 1.5.1 to correct it. If you downloaded 1.5, please re-download 1.5.1!

UPDATE: Thanks to some great feedback, I've released version 1.5.2. The new features include: admin notification upon successful (un)subscribe confirmation, support for a comma-seperated list of categories that should not trigger an email announcement, and some general clean-up. The download links were moved up to the top of this post, and all updates will be appended down here at the bottom. Thanks for the feedback, and please keep it coming!

UPDATE: Version 1.5.3 fixes a minor oversight with the application of the CSS in the admin section. Prior versions applied the CSS to all admin pages, when they should have only included it on the Subscribers management page. subscribe.php is now theme-aware, too, for WordPress 1.5 users. It should pick up your header and footer, allowing you to better integrate the subscription page with your site.

UPDATE: Version 1.5.4 fixes a stupid mistake in 1.5.3 which would break WordPress 1.2 blogs. Sorry about that.

UPDATE: Thanks to Morgan for spotting a problem with the name and address used to send notification emails. Fixed. Also fixed is proper handling of blank or invalid data being submitted to subscribe.php.

Update Version 2.0.3: This is the long-awaited update! All messages are now controllable through the plugin's Manage screen. I've also tidied up options storage in the database, along with a few minor tweaks. Finally, this version includes a subscribe2.po file if you want to translate the administration screens to your native language.

If you're upgrading, you will probably want to RESET your options to the defaults, and then re-define them according to your tastes.

Update Version 2.0.4: Thanks to MarcoB for spotting a typo which broke sending excerpt-only messages. Fixed!

Update Version 2.0.5: Added strip_tags to plaintext email delivery, to remove HTML from post content included in the mail. Also added a check against the post's date to suppress notification of future-dated posts.

UPDATE Version 2.0.6: added Content-Type text/plain for plaintext mail delivery -- thanks Toto. Added manual override for batch delivery on Dreamhost (or other hosting providers). See the README for additional details about the new batching functionality. Many thanks to Wade Emmert and Joe Mezzanini for their patience and their assistance in testing this new functionality.

UPDATE Version 2.0.7: I incorrectly entered a comment in the 2.0.6 source (/ instead of //) which broke version 2.0.6 -- version 2.0.7 fixes this. Sorry about that.

UPDATE Version 2.0.8: Version 2.0.7 had two major mistakes. First, batch mode was incorrectly set to be the default mode of operation. Second, if less than one batch (30 subscribers) of recipients was present, nothing happened. Version 2.0.8 correctly sets the default mode of operation to non-batched mode; and it also correctly handles batching mode with less than 30 subscribers.

UPDATE Version 2.0.9: I've added the ability to supply a subject line for emails delivered to all subscribers through the Manage interface. If you don't care about this feature, there's no need to upgrade.

UPDATE Version 2.1.1: I finally figured out localization, and have modified both subscribe2.php and subscribe.php to support gettext translations. If you translate this plugin, please send me the .po and .mo files for your locale, and I'll make them available in the Subversion repository for others to download!

UPDATE Version 2.1.2: very minor tweak, to allow for translatable text on the HTML form buttons. You only need to download this if you plan on making a translation file.

UPDATE Version 2.1.4: This version (finally) gets right the use of the author's or admin's display name when sending update notifications. Also included are additional translation tweaks. German and Spanish translations are available! Thank you Michael and maira, respectively.

UPDATE Version 2.1.5: I am closing comments on this post. Please see the subscribe2 2.1.5 announcement for details. From now on, new releases will get new posts -- 260 comments is too many! ;)

I've been using Mike's subscribe plugin on a site I host for some time now. It works well enough, but it always kind of irked me that it uses a text file to store the list of subscribers, instead of the database. It also irks me that there's no real verification to the subscription or unsubscription process.

So I reworked it! Here is subscribe2, released as 1.0 beta.

To use this, you need to create a link somewhere on your blog to the subscribe.php file. Here users can elect to sign up for updates when you post new entries. Each (un)subscription request sends a confirmation email verifying the legitimacy of the request.

The subscribe2.php plugin file contains an administrative interface to install the database table, and manage your subscription list. You can add subscribers in bulk, as well as individually enable, disable, and delete subscribers. Plus you can send an email to all your subscribers at once.

With WordPress 1.5 just around the corner, the obvious next step for this plugin is to make it integrate into the WordPress admin panel.

There are probably some rough edges here. Please let me know if you find any bugs, but I accept no responsibility if this plugin kills your dog or eats your archives.

NOTICE: I have permanently disabled the test implementation of this plugin. (2004-12-16)

Current Version: 1.6
Download tgz: commentauth.tgz
Download zip: commentauth.zip

I've made my first plugin for WordPress. When activated, this plugin will send an email to people who comment (and supply a valid email address) with a unique link. Clicking on the link will approve the comment for immediate posting, without waiting for an administrator's approval.

The basic idea is that if the user supplies a valid email address, and they check that email account, then the commenter is most likely not a spammer. It's not foolproof, but it's a step in the right direction.

The unique URL is calculated using an md5 sum of the comment text plus a "seed". The formula could be brute-forced by someone who really wants to bypass your authorization process; but the burden of effort is on them. Edit the $seed variable in both files to use something unique for your site. Make sure the seed is identitical in both sites, or people will never be able to authorize their own posts!

There are two files included in this plugin:

• commentauth.php
• moderate.php

Install moderate.php into your WordPress root directory, and commentauth.php in your wp-content/plugins/ directory. Ensure that comment moderation is activated, and then activate this plugin. That's all there is to it.

Download this plugin!

UPDATE: the original version of this plug-in was incompatible with the WordPress 1.2 Release Candidate. I've fixed that. Please download this package again, or edit moderation.php to remove the following line:
require_once('./wp-includes/functions.php');

UPDATE #2: I'm not currently using this plugin on this site, so please don't comment just to see it in action. You can do that over on my test installation!

UPDATE #3: Thanks to David, I've added a few extra headers to the generated mail so it should play nice with anti-spam systems. The download link has been updated to the newest version.

UPDATE #4 (2004-09-23): Thanks to Mark for suggesting a fix to help people who have their blog homepage in a different directory than the one in which they installed WordPress.