Hi! Thanks for the fruitful discussions on this mail thread and today in IRC. Highly appreciated. For the moment, I'll leave the idea with API keys alone. For those who have privacy concerns, we can redirect them to the following example script now:
https://git.linux-kernel.at/oliver/ivatar/blob/devel/libravatarproxy.py One can deploy this or something similar to their own servers, so the users do not directly hit libravatar and therefore hide the users from us. Since they proxy it in the background, one can also change the script to take as input some user id, that queries some database and so on and so forth... That would ultimately lead to also the possibility to hide the hash. PRs to enhance this, are welcome. Oliver On Tue, Mar 12, 2019 at 6:17 PM Tristan Le Guern <tlegu...@bouledef.eu> wrote: > On 3/12/19 2:23 PM, Oliver Falk wrote: > > Yes, federation wouldn't work - only if we do not encrypt the hash, but > > instead the mail-address (makes sense, since it's anyway encrypted) and > > Libravatar proxies the requests to the federated site. Which means, that > > these sites would only need to trust Libravatar. > > This is problematic as it forces centralization. I don't have a better > proposition for now but this is an interesting and important discussion > to have. > > > BTW. That raises the question in my mind do we know how many sites > > actually run their own Libravatar (compatible) service? I guess > > no!? @Francois Marier <mailto:franc...@fmarier.org> do you know > anything? > > I guess it is impossible to find. You can count mine and tastytea's for > sure. Debian, Mozilla and git.kernel.org use their own or do they use > libravatar.org? > >
_______________________________________________ Mailing list: https://launchpad.net/~libravatar-fans Post to : libravatar-fans@lists.launchpad.net Unsubscribe : https://launchpad.net/~libravatar-fans More help : https://help.launchpad.net/ListHelp