libravatar-fans team mailing list archive

[Lars Kruse <lists@xxxxxxxxxxxxx>]

Hello,

today we had a another IRC meeting and discussed the following topics:
* Review of the last weeks
* Fallback to gravatar?
* (sec)?cnd.libravatar.org
* wiki styling
* support for robohash

Take a look at the wiki for the summary:
https://wiki.libravatar.org/shutdown-coordination/?updated#index2h2

Attached you find the full log.

The next IRC meeting will happen on the 9th of December at 19:00 UTC in
#libravatar at freenode.

Cheers,
Lars

20:00 <sumpfralle> OK - let us start with the meeting!
20:00 <sumpfralle> Who is around?
20:00 <sumpfralle> AslakR, ihabunek, ij_, imcdona, kambiz, nipos, opal, techknowlogick[m, toml[m], Unit193?
20:01 <opal> dont mass highlight me or i mistake you as a spammer and you risk me telling you to fuck off
20:01 <opal> because i was just about to rudely tell you to fuck off
20:03 <sumpfralle> ofalk: so we seem to have a small meeting of two :)
20:03 <ofalk> mass-highlight opal? i think sumpfralle just wrote one single line with your nickname.
20:03 <ofalk> sumpfralle, seems so. :-{
20:03 <opal> mentioning everyone in the room is mass highlighting
20:04 <ofalk> lemme open the agenda ...
20:04 <opal> try doing that in literally any other channel
20:04 <opal> you'll be banned
20:04 <opal> it's rude
20:04 <ofalk> i see opal. i see. sorry for that. we just wanted to know who is going to attend the meeting now.
20:04 <opal> i get that but like i said it's easy to misinterpret that intention
20:05 <opal> maybe i should detach from this channel
20:06 <sumpfralle> ofalk: do you have something to share about your progress during the last two weeks?
20:06 <ofalk> as you like opal. it's your decision. but we're happy if you stick around and share your opinion(s) if any.
20:06 --> clime (~clime@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) hat den Channel #libravatar betreten
20:06 <clime> hi
20:06 <sumpfralle> welcome!
20:07 <ofalk> sumpfralle, yes. i got my hands on the data (db + imgs). and was able to write the export script that can be run on the old instance.
20:07 <ofalk> hi clime !
20:07 <sumpfralle> The export creates a tar containing the images and a database dump?
20:07 --> clime1 (~clime@xxxxxxxxxxxxxxxxxxxxxxxxxx) hat den Channel #libravatar betreten
20:07 <-- clime (~clime@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) hat den IRC verlassen (Read error: Connection reset by peer)
20:07 <clime1> sry, disconnected
20:07 <ofalk> clime1, don't worry.
20:08 <ofalk> sumpfralle, it creates a directory with .xml.gz - one for each user.
20:08 <ofalk> ~ 7.5k files.
20:08 <clime1> ye, ofalk got the data to libravatar-stg. I am going to import them in the following days
20:09 <sumpfralle> In a simple "clean and import" approach, correct?
20:09 <sumpfralle> (no synchronization ...)
20:10 <clime1> just one-shot import for now
20:10 <ofalk> one shot. export all. copy over to the new instance, run import.
20:10 <sumpfralle> good
20:10 <sumpfralle> I do not think, we need more.
20:11 <ofalk> export takes less than a minute on my _laptop_.
20:11 <sumpfralle> :)
20:11 <sumpfralle> We are here to grow! :)
20:11 <ofalk> as stated ~ 7.5k files. about 355 mb.
20:11 <ofalk> not as large as i have imagined.
20:12 <sumpfralle> Not collecting user data saves space ...
20:12 <sumpfralle> Anything else?
20:12 <sumpfralle> other topics?
20:13 <clime1> i noticed libravatar.org provides cdn.libravatar.org
20:13 <sumpfralle> It was probably meant for the mirror setup?
20:13 <clime1> which is probably functionally same as libravatar.org/avatars
20:13 <ofalk> maybe to note this again: no passwords are exported.
20:14 <ofalk> cdn and seccdn should all provide libravatar.org/avatars i believe.
20:14 <sumpfralle> ofalk: I forgot again, thanks for the reminder!
20:14 <clime1> sry, i meant same as http://libravatar-stg.fedorainfracloud.org/avatar/
20:14 <clime1> alright
20:16 <clime1> so i guess will just create an alias for cdn.libravatar and seccdn.libravatar.org just provide libravatar.org/avatar/
20:16 <ofalk> yes clime, i think we should do that!
20:16 <clime1> ofalk: ok, thank you
20:16 <ofalk> sumpfralle, yes, regarding gravatar fallback.
20:17 <sumpfralle> good one!
20:17 <sumpfralle> Maybe you want to present your (an maybe fmarier's) position for this topic?
20:18 <ofalk> i'll code this functionality, but provide an additional parameter to disable the functionality. default will be on. i'm just not sure if our ivatar instance should fetch the data from gravatar (more privacy for the user - in my opinion) or if we just want to redirect. maybe provide both options, also switchable with parameter.
20:19 <ofalk> btw. just tried (again on my laptop). the import of the data (but "only" sqlite db in the background) takes ~ 5.5 minutes.
20:20 <ofalk> so far, so clear?
20:20 <ofalk> what is your opinion on that sumpfralle and clime?
20:20 <sumpfralle> Do you have an idea, what fmarier's opinion was on this topic?
20:20 <sumpfralle> It seemed to differ from yours?
20:20 <sumpfralle> Just for the clarity of the possible options :)
20:22 <ofalk> sumpfralle, i'm pretty sure fmarier also wants to keep this functionality. i think the problem with different opinions here is that I didn't code it yet.
20:22 <ofalk> because of the above options, i wasn't sure which route to go - therefore it wasn't implemented yet :-)
20:23 <sumpfralle> What is the state of the old libravatar implementation in this regard?
20:25 <ofalk> libravatar redirects to gravatar automatically
20:25 <clime1> i think some implementation of it would be fine
20:25 <ofalk> eg. https://seccdn.libravatar.org/avatar/40f8d096a3777232204cb3f796c577b7
20:26 <ofalk> redirs to https://i2.wp.com/seccdn.libravatar.org/nobody/80.png?ssl=1
20:26 <sumpfralle> For the implementation we probably want to decide, whether the *user* or the *client* decides about this feature.
20:26 <sumpfralle> ofalk: your description leaves this to the client, or?
20:26 <sumpfralle> I could imagine, that we should let the *user* decide this.
20:26 <sumpfralle> hm
20:26 <sumpfralle> but I am not sure
20:27 <sumpfralle> no, probably the client
20:28 <ofalk> there are several things involved. a) the user in front of the browser who surfs the web. he cannot decided anything here... we have the maintainer of the website - so to say the one who sets the parameters that his (web surfing) clients will have to use in the end. and we have the ivatar instance that can decided what the defaults are.
20:28 <ofalk> b => website maintainer. c => ivatar developer (aka /me).
20:29 <clime1> so i would be happy if the option is there
20:29 <clime1> but if it isn't it will probably also work
20:29 <sumpfralle> I guess, the website maintainer should be responsible for deciding this. Thus your approach of a configurable query argument sounds good to me.
20:31 <ofalk> well..... for a) eventually we could let the web surfing user also decide, if he is a user of ivatar, he could set a preference and if his web browser hits the ivatar instance, because his browser wants to fetch an avatar, we could check the cookies... how likely is this? .... sorry, braindump. maybe at a later point in time.
20:32 <ofalk> sumpfralle, yes, the website maintainer should have all possible options available and we should make clear in the documentation what the defaults are.
20:32 <sumpfralle> That sounds like a bit of complication for the client implementations. But it sounds good in theory :)
20:32 <ofalk> sumpfralle, not really, it would all happen on the server side.
20:32 <ofalk> ... again. let's move that idea to some later stage. not now in short time.
20:33 <ofalk> ...
20:33 <sumpfralle> Ah - indeed - cookies or other things relating to libravatar would be part of the request - indeed!
20:33 <ofalk> exactly sumpfralle
20:33 <sumpfralle> yes, postponed
20:33 <sumpfralle> Regarding the proxy vs. redirect question: I also slightly tend towards "proxy", but I dislike the complication.
20:33 <sumpfralle> But if it is easily possible, then I would prefer it.
20:34 <sumpfralle> This also trivially solves the issue of websites exposing their users to gravatar tracking.
20:35 <ofalk> sumpfralle, indeed.
20:35 <ofalk> first thing i'll implement is some "proxy" url libravatar.org/gravatar/ will "proxy" to gravatar.org
20:36 <ofalk> so the users privacy is kept.
20:36 <nipos> Hello,sorry for being late
20:36 <sumpfralle> If we expose this URL publically, then we can also handle this via the webserver.
20:36 <ofalk> hey nipos!
20:36 <sumpfralle> welcome, nipos!
20:37 <sumpfralle> (webserver: nginx, apache2, ...)
20:37 <clime1> another option that just came to my mind is to do one-shot import of gravatar images to libravatar's db
20:37 <sumpfralle> do we have permissions to copy that database?
20:37 <clime1> so that avatars that are now hosted on gravatar will keep working.
20:38 <clime1> but i don't know if it is technically possible
20:38 <ofalk> sumpfralle, yes, everyone should be free to use it and we can do this without any code in libravatar. we just need to proxy it in apache/nginx and make sure we don't give the user ip to gravatar.
20:38 <clime1> nipos: hey
20:39 <ofalk> clime, i wouldn't import the gravatar images. we have no idea what hashes we have to check.
20:39 <ofalk> and users might be confused if they change their gravatar image and still the old pic will show up when using ivatar.
20:40  * ofalk has connection issues!?
20:40 <ofalk>  /gravatar/ proxying to gravatar.org is probably the best.
20:40 <nipos> I think proxying Gravatar images is a nice idea but caching (if done at all) should be only for a short period of time
20:40  * ofalk has no connection issues. 
20:41 <ofalk> right nipos. does gravatar currently set an expiry?
20:41 <clime1> ofalk: right, ok
20:41 <nipos> I don't know.
20:41 <sumpfralle> So we can probably do it all via nginx or apache2.
20:43 <nipos> Gravatar sets 5 minutes as expirity
20:43 <ofalk> they do but only for a very short time:
20:43 <ofalk> Expires: Sun, 25 Nov 2018 19:47:44 GMT
20:43 <ofalk> Cache-Control: max-age=300
20:44 <ofalk> sumpfralle, for the proxying yes, we can do this on the webserver. clime can you take care of this?
20:44 <clime1> sure
20:44 <clime1> will do
20:45 <ofalk> for the redirect, i'll do it in the code. as well as the options to disable gravatar and to _directly_ redirect gravatar.
20:45 <sumpfralle> ofalk: sounds good!
20:46 <ofalk> ack. issue created https://git.linux-kernel.at/oliver/ivatar/issues/22
20:47 <ofalk> comments there are welcome
20:47 <ofalk> next topic?
20:48 <sumpfralle> I do not have one at the moment.
20:48 <ofalk> robohash?
20:48 <ofalk> yes/no/maybe.
20:48 <nipos> I can say a short statement about my plans to redesign the wiki...
20:48 <nipos> I vote yes for robohash
20:49 <ofalk> please give thumb up/down here for robohash: https://git.linux-kernel.at/oliver/ivatar/issues/13
20:49 <ofalk> no more to say about it.
20:49 <sumpfralle> a good trick to lure people into the issue tracker! :)
20:49 <sumpfralle> (very good)
20:49 <ofalk> sumpfralle, you got me. :-)
20:50 <nipos> Upvoted.
20:50 <ofalk> thx nipos!
20:50 <ofalk> your vote will be considered!
20:50 <sumpfralle> nipos: please share your thoughts about the wiki design
20:50 <ofalk> but now I'd be glad to hear from you, nipos, about the wiki
20:50 <nipos> I didn't know robohash is open source,nice :D
20:51 <nipos> Bad news from the wiki.I checked the repo and I can do basically nothing.There's a CSS file where I can add some styles but I can't change the default CSS and I can't change the HTML
20:52 <ofalk> meh++
20:52 <nipos> This way it won't work with a acceptable result :/
20:53 <sumpfralle> Personally I can live with (or without) any design. But this is just me. Thus I can live with the current state without pain.
20:53 <sumpfralle> How is your feeling?
20:54 <nipos> In my opinion it would be nice to have a similar look on all sited which belong to the Libravatar project but I can live with the current one,too
20:55 <clime1> i can live with the current one too
20:55 <clime1> it's a bit old-school but quite easy to find info there
20:55 <nipos> I agree
20:56 <ofalk> If we can change the occurrences of libravatar to libravatar/ivatar and change the logo to the new blue-ish one. :-)
20:56 <ofalk> https://avatars.linux-kernel.at/static/img/nobody/512.png
20:56 <clime1> +1
20:56 <ofalk> else. yes, leave it for the moment. i can live with the current one as well.
20:57 <nipos> The new logo looks nice
20:57 <sumpfralle> ok - so we stick to the plain design and are happy that we can focus on other thigsn :)
20:57 <ofalk> for the moment we should get rid of the run a mirror and distributed service in regards to wiki/docs.
20:57 <ofalk> thx nipos, i just changed the color. nothing else.
20:58 <nipos> Yes but it looks more modern with this light blue
20:59 <sumpfralle> "get rid of" -> commenting, that this will be possible in the future or removing it forever?
20:59 <ofalk> might be possible in future again. :-)
21:00 <nipos> Isn't distributed currently working?As far as I know it doesn't have anything to do with the ivatar software
21:01 <ofalk> Weeeellll. :-) If you run your own libravatar/ivatar software, you can set a server for the domains you have under control. but you _cannot_ distribute the main instance.
21:01 <ofalk> distributed vs. distributed :-)
21:01 <ofalk> (yes, same word)
21:02 <nipos> Sure but that's how it has always been,isn't it?
21:02 <sumpfralle> or "decentral" vs. "distributed"? Maybe "federated" was the goal?
21:03 <ofalk> nipos, in the past it was possible that you mirror (after talking to the owner, aka fmarier) the data of the main CDN instance, since these were only plain pictures that you could rsync to another location.
21:03 <nipos> Yes,I know.So you're only talking about the "mirrors" wiki page?
21:03 <ofalk> yes nipos.
21:04 <nipos> I thought you want to remove the federated thing,too.That was the misunderstanding
21:04 <ofalk> ack nipos
21:05 <ofalk> no, that's anyway client side and i'm not going to kill it.
21:05 <nipos> Ok,good
21:06 <sumpfralle> ofalk: in order to distribute the documentation work, maybe you want to send an overview of "what was there", "what will be there in the short term" and "what could be there in the long-term" to the mailing list and ask people to turn this into wiki documentation?
21:06 <sumpfralle> I would offer to be the fallback, if no one else takes over that task.
21:06 <ofalk> which brings me to the other point. what if a client requests an image and since it doesn't implement DNS checking, asks the main ivatar instance?
21:06 <ofalk> ack sumpfralle i can do that!
21:07 <ofalk> forget my last question => agenda for the next meeting
21:07 <sumpfralle> ok - I will forcefully forget it :)
21:07 <ofalk> since we're over the time already. is there anything else that is important so we should talk about it _now_?
21:07 <nipos> It would be best in my opinion to check the server and redirect to it but simply returning a default image would be acceptable,too as the clients are responsible for this question normally
21:08 <nipos> I was already typing when you told me to forget it so I wanted to finish it but I can repeat it next time
21:08 <sumpfralle> :)
21:09 <sumpfralle> Yeah, so let us finish this meeting!