Libravatar was designed so that domain owners can choose to host themselves the profile pictures for their domain. For example, an organisation may want to have control over the pictures use for their employees.

Server implementations

There currently exist the following Libravatar image server implementations:

Name	Description	Administration	Programming language	Support for	Default modes
libravatar	The software that runs libravatar.org	web-based	Python	Email, OpenID	404, mm, identicon, monsterid, wavatar, retro
Surrogator	very simple avatar server	command line only	PHP	Email, OpenID	404, mm
Simple Libravatar service	Quick hack to serve static files	command line only	Shell script	Email	none (always returns a static image)

libravatar.org

The following instructions are about the official libravatar.org software.

System requirements

You can find the latest system requirements in the installation instructions that come with the software, but Libravatar has been confirmed to work on Debian 7 (wheezy).

Getting the code

We are not currently doing regular releases of the code, but you can easily get the latest copy from our git repository:

git clone https://git.nzoss.org.nz/libravatar/libravatar.git

Installation

Once you've got a copy of the code, follow the instructions in the INSTALL file.

Configuration

A number of options can be customised in the libravatar/settings.py file. If there's anything that's unclear in there, please file a bug against the project so that we know how to improve the documentation.

DNS setup

Once your instance is running on a publicly-accessible server (avatars.example.com in this example), add the following records to your DNS zone file:

_avatars._tcp.example.com.     IN SRV 0 0 80  avatars.example.com
_avatars-sec._tcp.example.com. IN SRV 0 0 443 avatars.example.com

The first entry (_avatars._tcp) should point to an HTTP server whereas the second one (_avatars-sec._tcp) is for an HTTPS server (if you have one).

Note that these servers do not have to be running Libravatar themselves, but they do have to implement the same protocol/API.

TTL

The time-to-live (cache expiry) should be set to at least 1 day (86400 seconds).

If you choose a TTL smaller than 1 day, Libravatar clients are allowed (and encouraged) to ignore it and cache your entry for a day.

Subdomains

If you use full hostnames or subdomains in your email addresses, for example bob@foo.example.com and bob@bar.example.com, then you need to have a set of SRV records for each of them:

_avatars._tcp.foo.example.com.     IN SRV 0 0 80  avatars.example.com
_avatars-sec._tcp.foo.example.com. IN SRV 0 0 443 avatars.example.com
_avatars._tcp.bar.example.com.     IN SRV 0 0 80  avatars.example.com
_avatars-sec._tcp.bar.example.com. IN SRV 0 0 443 avatars.example.com

SRV weights and priorities (optional)

All SRV entries should have the same priority. Lower priority ones will be ignored by Libravatar clients.

You may however use weights to spread the load across more than one avatar server.

Testing

Once you have these records, have a look at the domain check tool to make sure everything is working.