Pavatar explained: how the Personal Avatar protocol worked

Everything on this page is my own explanation of a protocol I had no part in. The specification was written by Jeena Paradies in 2006. Short quotations are marked as quotes and credited; the complete texts are in the Wayback Machine (links at the bottom).

The idea in one paragraph

In 2006 many blogs showed commenter pictures from one central service, Gravatar. Pavatar moved the picture to the commenter's own website. The specification put the idea in one sentence:

The Personal Avatar (short Pavatar) system is a way to use small personalized images to standardize a providers profile picture through various websites when leaving comments and other content.

The picture lives on your own website, so no company sits in the middle. The blog that shows it is the consumer; you, the owner of the picture, are the provider. The only thing the two share is the website address you already type into a comment form.

How a blog found the picture

The consumer checked three places, in a fixed order, and stopped at the first one that answered. The diagram replays one lookup where the first two places are empty and the file is found at the site root.

FIG. 01 · live

How a blog found your Pavatar

spec 0.3.0 · section 4.a

Complete · replay anytime

Website URL · the address the commenter typed into the comment form
X-Pavatar · the HTTP header of that page, the highest precedence: an absolute URL or the keyword none
<link> element · the first <link rel="pavatar" href="…"> in the HTML, read only when there is no header
pavatar.png · a HEAD request in the page's directory, then at the site root, the lowest precedence
Avatar · an 80×80 GIF, PNG or JPEG of at most 409,600 bits with the right Content-Type, cached by the blog

The X-Pavatar HTTP header of the page at your address. It carries an absolute URL of the image or the keyword none, and a response may contain only one such header. It has the highest precedence.
A link element in the page's HTML: <link rel="pavatar" href="…">. The consumer reads the first match, and only when there is no header.
A file named pavatar.png — the specification calls it “the favicon.ico way”. The consumer sends a HEAD request for it in the directory of your page first, then at the root of your site.

Every consumer had to accept all three ways. Providers were advised to use the header or the link, because those let you put the image anywhere and give it any name.

You can run the same three checks against any site today with curl: the steps are on the Pavatar check page, in the same order as the diagram.

Saying no: the keyword none

If the header or the link contains none instead of a URL, the lookup stops and there is no avatar at all — even if a pavatar.png file exists. Only the method that decides counts: a none in the link does not matter when a header with a URL is present. A provider could also answer requests for the image with HTTP 403.

The image rules

A valid Pavatar was an 80×80 pixel image in GIF, PNG or JPEG, publicly reachable over HTTP and served with the correct Content-Type. Version 0.3.0 capped it at 409,600 bits (51,200 bytes): eight times the size of an uncompressed 80×80 image with 8-bit color. Version 0.2.0 allowed only a quarter of that, 102,400 bits.

Consumers were expected to keep their own copy instead of loading the picture from your site on every page view, to refresh it with conditional requests, and to check weekly when your site sent no cache headers. They could resize the image, but not change what it shows.

Versions

Version	Date	Status	Explained
0.1.0–0.1.2	before May 2006	first drafts on jeenaparadies.net	—
0.2.0	announced 11 May 2006	“early and unstable” draft, first on pavatar.com	0.2.0 explained
0.3.0	18 December 2006	Candidate Recommendation, “believed to be stable”	0.3.0 explained

The short version of the difference: 0.2.0 talked about commentators and publishers and was not meant to be implemented yet; 0.3.0 renamed the roles to provider and consumer, quadrupled the size limit, dropped the provider's option to forbid caching and asked consumers to respect the provider's picture when resizing it. The version pages go through each change.

Implementations

By 2008 the project home page listed implementations in several languages: a “Check your Pavatar!” script in Ruby, the Block weblog software, a WordPress plugin, a DotClear module and a “universal plugin” in Ruby. Two of them are still easy to find:

Net::Pavatar on MetaCPAN — a Perl module whose documentation still links to the 0.3.0 text on this domain.
sunchaser/pavatar on Packagist — a PHP library for embedding Pavatars. Its README credits Keith Bowes for the initial php-pavatar and Jeena Paradies for the specification; the package is marked as abandoned.

The rest of the 2008 list is preserved in the Wayback Machine copy of the home page.

How it was received

The proposal was discussed where people argued about web identity at the time. A December 2006 message on the microformats-discuss list pointed to the specification, and a post in a Textpattern forum thread linked to it as “a very solid and standardized system”.

Not everyone agreed. In “Raising the standard for avatars” Chris Messina called Pavatar an “overly complicated spec”. The post suggested reusing the photo property of the hCard microformat, putting an avatar.jpg at the end of an OpenID address and moving from 80 to 512 pixels square. That last idea aged better than the 80×80 limit.