Add libravatar support, superseding gravatar

[phikal]

Libravatar is a Gravatar alternative, that supports a certain degree of federation, but at the same time has a Gravatar fallback, if no profile picture was found.

I have tried to use a ruby gem that implements everything that is needed, while at the same time changing as little as possible on the user-end. Since I have never really done any Ruby, it might be that everything is wrong, but if I am given pointers, I'll be glad to fix the issues.

[roryokane]

I am not an official Lobsters developer. Nonetheless, here are my thoughts as a developer with experience in Ruby and Ruby on Rails.

Since you mentioned that you’re not familiar with Ruby, I will say that this is fine, normal Ruby code. I have one style nit: Ruby supports writing symbol-keyed hashes either like :email => self.email (the older way) or email: self.email (the newer way). I personally favor the newer way, and the README for Vishnu suggests using the library with the newer way, but I see instances of both ways in the Lobsters codebase, so it’s up to you. (more info about that syntax)

[pushcx]

I understand why you'd want to reduce our dependence on a random free service from a business with an open alternative, but there are significant downsides to this change. Libravatar doesn't even have an about page and there's nothing to build confidence that they'll still be operating a month, a year, or ten years from now. Gravatar has been running long enough that it'd be very surprising if Wordpress decided to shut it down. On the code side, this replaces a one-line string interpolation with a new gem that's hundreds of lines long; that's a lot of complexity to pick up. Finally, it's going to confuse users: if you visit gravatar.com it explains what the service is about and why you'd want to use it; Libravatar doesn't have such a clear explanation and the subtle 'read more' link goes to a how-to page rather than explain much more.

[phikal]

If you're not interested, there's little I can do. But I'd still like to raise a few questions/conterarguments to what you mention:

Libravatar doesn't even have an about page and there's nothing to build confidence that they'll still be operating a month, a year, or ten years from now

It is a federated service, but even so, according to this blog post, the project claims: "[...] Libravatar.org has run on Fedora Infrastructure Cloud. They are providing this service for free to us without any expiration date and with as much power as we need". Sure, they're not Wordpress, but it's not expected that they'll go under any time soon.

On the code side, this replaces a one-line string interpolation with a new gem that's hundreds of lines long; that's a lot of complexity to pick up.

Sure, but that's the idea. You can't really implement a federated system in one line.

Finally, it's going to confuse users: if you visit gravatar.com it explains what the service is about and why you'd want to use it

That's a social/marketing issue. One could mention it to the project, and it could be clarified.

[toastal]

Since these options use similar architectures and API. I 100% agree with the maintainer that it's pointless to bring in another library when the effective API is

-- pseudocode assumes nilable origin (I don't know Ruby)
avatarURI :: forall r. { avatarOrigin : Maybe String, email : String | r } -> String
avatarURI user = origin <> "/avatar/" <> emailHash
  where
  -- defaults to Gravatar
  origin = fromMaybe "https://www.gravatar.com" user.avatarOrigin
  emailHash = md5Digest (toLower user.email)

I could see a new URL field in the user profile a text label for Libravatar https://seccdn.libravatar.org hint.

<label for="avatar_origin">
  <span>Avatar service origin: (e. g. Libravatar "https://seccdn.libravatar.org", defaults to Gravatar)</span>
  <input 
    type="url" 
    name="avatar_origin" 
    value="<%= user.avatarOrigin %>"
    placeholder="https://gravatar.com">
</label>

The same cache and invalidation of avatars can take place as production.

It might be a stretch too far to completely supplant Gravatar, but it seems equally disappointing for users to feel locked into any service at all -- especially one with privacy concerns (which I believe was the main purpose of the merge request). If an open URL field is opens too many security issues, then <select> with just Libravatar and Gravatar options and an enum could suffice, but wouldn't support the federated part of Libravatar (of course any malicious request could just ban the user at the cost of implementation time).