Feature #9112
closed
Libravatar and Gravatar-compatible servers support
0%
Description
As an alternative to gravatar support, could we have libravatar support as well?
http://libravatar.org/ provides the same sort of service as Gravatar, but instead of forcing you to host your data on a central service, allows federation out to multiple servers -- so you could have automatic support for fallthrough to one set of images for internal company use, another for official external use, or images hosted on libravatar.org itself, with additional fallback onto gravatar as well ...
Files
Related issues
Updated by Etienne Massip over 13 years ago
- Category set to Third-party libraries
Could be done with a plugin.
Updated by Francois Marier over 13 years ago
The Libravatar Gem might be useful:
https://rubygems.org/gems/libravatar
https://github.com/gugod/libravatar
Updated by n ext over 9 years ago
Is there any progress yet? IMHO it's an much more privacy respecting solution that should be introduced upstream as gravatar is already?
Updated by Sandro Santilli over 7 years ago
Upvoting this, I hate to be forced to have my face served by gravatar.com :/
Updated by Oliver Falk over 5 years ago
Hi!
Libravatar has been recently completely renewed and now shines again.
Changing from Gravatar to Libravatar is only a matter of changing the "base URL". It's completely compatible with Gravatar. The default even is to proxy to Gravatar. With proxy I mean, real proxying; Gravatar doesn't see the client IP and therefore preserving user privacy.
This is really low hanging fruit, as you do not really need to change the module you use, if this is too much work. You just need to replace the URL.
https://secure.gravatar.com/ => https://secure.libravatar.org/Thanks and kind regards,
Oliver
Updated by Go MAEDA over 5 years ago
What do you think about the attached patch?
The patch introduces a new configuration option "avatar_service_url". You can switch to Libravatar by setting the option in the configuration.yml file like this.
avatar_service_url: https://seccdn.libravatar.org
Updated by Oliver Falk over 5 years ago
Hi!
In principle I like this! If I may suggest: Put it the other way round and make Libravatar the default :-)
I doesn't change anything for the user/admin, except they'll have better privacy.
Updated by Go MAEDA over 5 years ago
- Category changed from Third-party libraries to Accounts / authentication
- Target version set to Candidate for next major release
Updated by Jim Cheetham over 5 years ago
Thanks for promoting this again Oliver Cordero :-)
The patch as presented gives the admin the option to easily select their own service, which is excellent.
We still have a hard-coded portion, '/avatar/' + hash, and this should be surfaced in the documentation at least, and probably in the configuration file as well. But to be fair, this is the published API for both Libravatar and Gravatar, and is probably just as static as the formation of the hash itself. It's been correct for many years now ...
The argument of which should be the default is going a step further than I was asking for, and whereas 7 years ago I was happy for this to be just an option these days I think more people are sensitive to privacy concerns. However, technically this patch provides good capability, and I'm happy to see it moving on.
Of course I now wish I'd dug in to the code myself all those years ago and written the patch myself!
Updated by Go MAEDA over 5 years ago
Updated the patch. Now it includes test code.
Jim Cheetham wrote:
We still have a hard-coded portion, '/avatar/' + hash, and this should be surfaced in the documentation at least, and probably in the configuration file as well.
I have described what URLs are generated in configuraition.yml.example. Thank you for reviewing the patch.
But to be fair, this is the published API for both Libravatar and Gravatar, and is probably just as static as the formation of the hash itself. It's been correct for many years now ...
I think hard-coding '/avatar/' is OK because DNS-based server discovery mechanism described on https://wiki.libravatar.org/api/ assumes that the path is always '/avatar/'
Updated by Oliver Falk over 5 years ago
Hi!
Yes, hardcoding /avatar/ should be fine. I'm pretty sure all services are using this path in order to be compatible with Gravatar. If - for some reason - someone has a different path with his service, he needs to rewrite it in the web server configuration accordingly - not really our issue.
Glad you enhanced the code with tests.
I would still love to see Libravatar be the default or some way how we could potentially encourage users to switch to Libravatar if it's not the default - but it is your decision and not mine of course.
Thanks for your work on this - highly appreciated!!
Updated by Go MAEDA over 5 years ago
- Target version changed from Candidate for next major release to 4.1.0
Oliver Falk wrote:
I would still love to see Libravatar be the default or some way how we could potentially encourage users to switch to Libravatar if it's not the default - but it is your decision and not mine of course.
I don't think we should make Libravatar the default because most people probably use Gravatar instead of Libravatar. In addition, I have doubts about the continuity of libravatar.org (see the articles below).
https://blog.libravatar.org/posts/Libravatar.org_is_shutting_down_on_2018-09-01/
https://blog.libravatar.org/posts/Libravatar.org_is_not_going_away/
Anyway, supporting Gravatar-compatible servers including Libravatar is easy, and I think it is valuable because it gives users another choice. I am setting the target version to 4.1.0.
Updated by Oliver Falk over 5 years ago
Hi!
I don't think we should make Libravatar the default because most people probably use Gravatar
instead of Libravatar.
By default Libravatar proxies to Gravatar and therefore it doesn't make any difference to the user, apart from more privacy, since Gravatar only sees the proxy address.
In addition, I have doubts about the continuity of libravatar.org (see the articles below).
https://blog.libravatar.org/posts/Libravatar.org_is_shutting_down_on_2018-09-01/
https://blog.libravatar.org/posts/Libravatar.org_is_not_going_away/
I know those articles. I'm basically the reason behind the 'is not going away'. Software has been rewritten by me and is now hosted on Fedora Infrastructure - so really no doubts if it's staying or not. It IS staying. ;-)
Oliver
Updated by Go MAEDA over 5 years ago
- Related to Patch #31022: Always use HTTPS when accessing gravatar.com added
Updated by Go MAEDA over 5 years ago
Updated the patch. I have changed the config name from avatar_service_url to avatar_server_url because users may use their own avatar server instead of services such as Gravatar and Libravatar.
You can see the list of opensource Gravatar-compatible servers: https://wiki.libravatar.org/running_your_own/
Updated by Go MAEDA over 5 years ago
- File text_avatar_server_config_html@2x.png text_avatar_server_config_html@2x.png added
- File avatar_service_url_configuration-v4.patch avatar_service_url_configuration-v4.patch added
Added a message about the avatar server configuration on the settings page. Users will have a chance to know by this message that the avatar server is configurable.
Updated by
Updated by Go MAEDA over 5 years ago
- Status changed from New to Closed
- Assignee set to Go MAEDA
- Resolution set to Fixed
Committed the patch. Thank you all for suggesting this feature.
Updated by Oliver Falk over 5 years ago
Go MAEDA wrote:
Committed the patch. Thank you all for suggesting this feature.
Awesome! Thanks a lot for your work!
Oliver
Updated by Go MAEDA over 5 years ago
- Blocked by Defect #31428: Gravatar can't be displayed when copy configration.yml.example to configration.yml added
Updated by Go MAEDA over 5 years ago
- Subject changed from Libravatar support to Libravatar and Gravatar-compatible servers support