Hey, thanks for the pointer to libravatar. I'd like to support it to encourage people to use libre federated web services, but we would need to also continue to support Gravatar, since most people use that.

Would you be interested in adding an abstract avatar service to Geary, so we can support both? I would be happy to help out with the architecture/design. This would also help out implementing Bug 713347 in the future.

(In reply to Michael Gratton from comment #1)
> Hey, thanks for the pointer to libravatar. I'd like to support it to
> encourage people to use libre federated web services, but we would need to
> also continue to support Gravatar, since most people use that.
> 
> Would you be interested in adding an abstract avatar service to Geary, so we
> can support both? I would be happy to help out with the architecture/design.
> This would also help out implementing Bug 713347 in the future.

I think the best will be to create a class, call it avatar. Then in this class a 3 steps. First it will check for avatars in libfolks/eds. If this is null he will select Gravatar or libRAvatar.
For this selection should be an options in the settings menu, where the use can select which service he will use.
So one class for all.

Hmm, we definitely don't want to add a preference for this - it should be enabled by default, or not implemented at all.

Note also that you might wish to consider filing a bug against libfolks itself for libRAvatar since, since there is already a bug for Gravatar support (Bug 655116) and I think this is ideally where this should be implemented, not in Geary itself. That would let the user choose which services they want to use by installing the appropriate folks backend.

In any case, I'd be happy with your suggestion of using a class, but I wouldn't worry about folks support for it for the moment - that is covered by Bug 713347. How about something like this:

Add a AvatarSource class with an "public async InputStream load_avatar(Geary.RFC822.MailboxAddress from, int pixel_size)" method, that makes a Soup request for an avatar from Gravatar first (since that's the more common service at the moment), and if not found makes a request via libRAvatar? This can then be called by the existing ConversationMessage::load_avatar() method. I guess the AvatarSource should be an app-wide singleton, that gets passed through to ConversationMessage via Geary.ContactStore?

> Add a AvatarSource class with an "public async InputStream
> load_avatar(Geary.RFC822.MailboxAddress from, int pixel_size)" method, that
> makes a Soup request for an avatar from Gravatar first (since that's the
> more common service at the moment), and if not found makes a request via
> libRAvatar? This can then be called by the existing
> ConversationMessage::load_avatar() method. I guess the AvatarSource should
> be an app-wide singleton, that gets passed through to ConversationMessage
> via Geary.ContactStore?

I think that's the best way.
So we must change the Gravatar class call it Avatar an then change the method inside of it.

The method public enum Default {} could be exists, because libravatar uses the same.
then only add a second method for libravatar like this

public string get_image_uri_gravatar(Geary.RFC822.MailboxAddress addr, Default def, int size = DEFAULT_SIZE) {
    // Gravatar spec for preparing address and hashing:
    // http://en.gravatar.com/site/implement/hash/
    string md5 = Checksum.compute_for_string(ChecksumType.MD5, addr.address.strip().down());

    return "https://secure.gravatar.com/avatar/%s?d=%s&s=%d".printf(md5, def.to_param(), size);
}

public string get_image_uri_libravatar(Geary.RFC822.MailboxAddress addr, Default def, int size = DEFAULT_SIZE) {
    // LibRAvatar spec for preparing address and hashing:
    // https://wiki.libravatar.org/api/
    string md5 = Checksum.compute_for_string(ChecksumType.MD5, addr.address.strip().down());

    return "https://seccdn.libravatar.org/avatar/%s?d=%s&s=%d".printf(md5, def.to_param(), size);
}

I think it is not possible to support OpenId, because then we must have the login and password from the sender.

(In reply to Michael Gratton from comment #3)
> Hmm, we definitely don't want to add a preference for this - it should be
> enabled by default, or not implemented at all.

Then Gravatar support should be removed if you don't want to add a preference. The business model of Gravatar is user tracking. So they're currently tracking who Geary users are exchanging email with. Admittedly it must be on an IP-based level, but still, creepy much? This is a huge problem. (Is there currently no way to disable the Gravatar integration?)

Libravatar avoids this problem and is already widely-used in the free software community, e.g. by Fedora infrastructure.

(In reply to Michael Catanzaro from comment #6)
> (In reply to Michael Gratton from comment #3)
> > Hmm, we definitely don't want to add a preference for this - it should be
> > enabled by default, or not implemented at all.
> 
> Then Gravatar support should be removed if you don't want to add a
> preference. The business model of Gravatar is user tracking. So they're
> currently tracking who Geary users are exchanging email with. Admittedly it
> must be on an IP-based level, but still, creepy much? This is a huge
> problem. (Is there currently no way to disable the Gravatar integration?)
> 
> Libravatar avoids this problem and is already widely-used in the free
> software community, e.g. by Fedora infrastructure.

This is why I'm keen to push the problem down the stack (e.g. Bug 655116): It would mean we can remove our custom implementation for Gravatar altogether and let distros/users make the choice of service. I'd consider removing it when support for loading avatars from folks lands (Bug 713347) but would rather have some alternative in place already for people who don't use desktop contacts.

I'll accept a patch for the pref to disable it, but it's not a high priority for me to work on myself.

Oh, but is libravatar's HTTP API compatible with Gravatar's? If so, I'd very much consider making the HTTP endpoint used user-modifiable via GSettings.

(In reply to Michael Gratton from comment #8)
> Oh, but is libravatar's HTTP API compatible with Gravatar's? If so, I'd very
> much consider making the HTTP endpoint used user-modifiable via GSettings.

I found https://wiki.libravatar.org/api/. Answer: yes, it's just https://secure.gravatar.com/avatar => https://seccdn.libravatar.org/avatar

Ok cool, I'll the GSettings hack that into master as soon as Bug 778720 lands and will put something on the wiki to make the "feature" more discoverable.

maltekiefer1987@gmail.com: If you'd like to look into putting a patch together to implement this GSettings change, I'd be more than happy to mentor and/or review.

I'd still like to pull the Gravatar code out altogether, but doing so will require Bug 713347 and/or Bug 655116 getting fixed, so I've filed Bug 791187 to cover that in the future.

This was recently reported on Gitlab again, so after thinking about it some more, I am still in favour of pulling out support for gravatar/libravatar altogether (especially since libravatar's future seems to be unclear). However, that will need to wait until 0.14, when support for loading avatars from libfolks lands.

For the interim, I've just pushed https://gitlab.gnome.org/GNOME/geary/merge_requests/52, which will make the base URL used for avatary loading configurable for 0.13, so people/distros can choose to use libravatar instead or disable it completely.

As such I'll mark this as closed.