← Back to team overview

libravatar-fans team mailing list archive

Re: IRC meeting (2018-12-09)

 

Hello,

today we had a another IRC meeting and discussed the following topics:
* Review of the last weeks
* Implementation details of the fallback to gravatar?
* Export/Import
* Theme switching
* Retro avatars
* API documentation
* Robohash
* OpenID

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 30th of December at 19:00 UTC in
#libravatar at freenode.
Due to Christmas this next meeting will be in *three* weeks (instead of two).

Cheers,
Lars
20:03 <sumpfralle> Do you have something to share that happened in the last two weeks?
20:04 <nipos> I did some small design improvements
20:04 <nipos> The last one hasn't been merged yet
20:05 <tleguern> Not a lot on my side.
20:05 --> fmarier (~francois@fsf/member/fmarier) hat den Channel #libravatar betreten
20:05 <sumpfralle> Design never stops :)
20:05 --> clime (~clime@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) hat den Channel #libravatar betreten
20:05 <sumpfralle> tleguern: didn't you start the discussion about differences in the API behaviour?
20:05 <clime> Hey, sry i am late
20:05 <sumpfralle> welcome!
20:06 <clime> thank you!
20:06 <clime> what's up?
20:06 <sumpfralle> We are exchanging the happenings from the last weeks ...
20:06  * fmarier also just realized that the time of the meeting has changed thanks to daylight saving
20:06 <sumpfralle> time is still a tricky thing :)
20:06 <clime> right
20:07 <tleguern> sumpfrall: yes but nothing since then. I was supposed to update my tests to reflect the discusions but I did not finish this work.
20:07 <sumpfralle> ok
20:07 <sumpfralle> But the discussion itself felt very important and healthy to me. A good step forward!
20:07 <tleguern> Yes :)
20:07 <sumpfralle> What else can we discuss?
20:08 <clime> i've imported the existing data to libravatar.fedorainfracloud.org machine
20:08 <tleguern> ofalk wrote quite a lot of points in the agenda
20:08 <sumpfralle> yes, indeed - a good amount.
20:09 <sumpfralle> Should we just go through them from top to bottom?
20:09 <tleguern> I will find some time to test the difference between the two fallack modes
20:10 <clime> me too
20:10 <clime> i would like to test python/ruby/... clients with it
20:11 <clime> but i mean they should probably work given that the api works
20:12 <sumpfralle> Regarding the fallback itself: is it a wise idea to hardcode the name of a single service/company as a query parameter *name* (instead of "value")?
20:13 <nipos> Makes sense in my opinion as there isn't any other big alternative
20:13 <tleguern> I agree it doesn't feel good
20:13 <sumpfralle> I will add a comment to the linked issue.
20:14 <sumpfralle> Anything else, we can comment on for the gravatar fallback?
20:14 <clime> I wouldn't be very strict about this, the whole code would need to be generalized and it's unlikely there will be any other fallback service.
20:15 <sumpfralle> But it should last for centuries!
20:15 <sumpfralle> :)
20:15 <nipos> It can always be changed ;)
20:16 <tleguern> It's better if it doesn't need to be changed later, as it will pollute the API with compatiblity-related names.
20:16 <sumpfralle> ok - I will add a comment to the issue without too much weight anyway :)
20:17 <sumpfralle> next topic?
20:17 <tleguern> Perhaps we could think of short names too ? To match other options.
20:17 <clime> i mean if it's just about gravavatarproxy vs just proxy. then just proxy is probably also ok
20:18 <clime> the same for redirect
20:18 <sumpfralle> allow_fallback=y&fallback_method=redirect&fallback_provider=gravatar,foobar,baz,acme
20:18 <sumpfralle> allow_fallback=y&fallback_method=redirect&fallback_providers=gravatar,foobar,baz,acme
20:18 <sumpfralle> ?
20:19 <sumpfralle> (just throwing in a wild idea)
20:19 <nipos> Maybe a bit too long
20:20 <sumpfralle> We can also just move the discussion to the issue, that ofalk linked (https://git.linux-kernel.at/oliver/ivatar/issues/22)
20:21 <nipos> fallback=redirect&provider=gravatar could do the same.If fallback is set,it's automatically yes and as we don't have other providers,we can leave out the fallback_ in from of it
20:21 <sumpfralle> There will always be more providable things in the future of an API :)
20:21 <tleguern> Good ones nipos
20:22 <sumpfralle> I am not sure, whether ofalk wanted to encourage a discussion about technical details or if he just wanted to report all the beautiful things, that he made happen?
20:22 <clime> maybe both
20:23 <sumpfralle> so we continue :)
20:23 <sumpfralle> He will surely enjoy going through this log and pick the ideas that he likes.
20:23 <sumpfralle> (I really mean it)
20:25 <sumpfralle> Next topic: export -> import?
20:26 <clime> i've tested that part successfully
20:26 <clime> Oliver has made a script to export data from the current libravatar instance into a format importable by ivatar.
20:27 <clime> the resulting exported tarball can even be uploaded through GUI for import into ivatar
20:28 <clime> so you should be able to test your accounts on libravatar.fedorainfracloud.org if you have one on libravatar.org
20:28 <sumpfralle> the image import is currently fixed to JPEG - is that correct?
20:29 <sumpfralle> at least line 54 of the import (https://git.linux-kernel.at/oliver/ivatar/blob/master/import_libravatar.py) looks like that
20:29 <clime> i need to take a look
20:29 <nipos> It found images of me but redirected them to avatar.linux-kernel.at where I have an account,too.How should I know now where the data comes from?
20:30 <sumpfralle> clime: I think, I was wrong. pil seems to be used for format detection.
20:30 <sumpfralle> nipos: what exactly did you try?
20:31 <sumpfralle> The import went into the staging instance, correct?
20:31 <clime> sumpfralle: yes, i have the access to the exported data only from another laptop than i am on now
20:31 <nipos> http://libravatar.fedorainfracloud.org/tools/check/ and entered ni.pos@xxxxxxxxxx
20:31 <nipos> It responded with two images at avatars.linux-kernel.at
20:32 <clime> sumpfralle: i originally did import into staging, but then I remounted staging disc into production instance and made a new volume for staging.
20:32 <clime> so now the data are actually on (future) production and staging is empty :)
20:32 <sumpfralle> ah - good :)
20:33 <tleguern> nipos: the “import from Gravatar” feature is accessible from the account menu, not the check tool.
20:33 <sumpfralle> regarding the source URL pointing at avatars.linux-kernel.at: this is probably not intended. ofalk will probably react, if this needs to be fixed.
20:33 <tleguern> It will show you your avatar on Gravatar and on other Libracatar instances.
20:34 <nipos> Oh,I thought we are talking about all data from the old Libravatar imported to the new one.I should have read more carefully
20:34 <clime> nipos: that should probably be fixed. I will look at it.
20:35 <sumpfralle> regarding the import: there is an attribute "ip_address" for each account.
20:36 <sumpfralle> This sounds a bit like a legacy thing _or_ something that violates the principle of storing only the minimum required amount of personal data.
20:36 <sumpfralle> (for each "photo" - not "account")
20:36 <nipos> Yes,we should remove IP addresses
20:36 <tleguern> Agreed
20:37 <clime> ye, hmm, it is configured in config.py and I think I am not providing an updated config file for the deployment
20:37 <clime> probably +1 for removing ip address
20:38 <sumpfralle> ok - do you have other comments regarding import/export?
20:40 <sumpfralle> So the next one: "theme switching"
20:41 <tleguern> How do we try this one ? I haven't looked at the code.
20:42 <tleguern> and I think it broke https://avatars.linux-kernel.at/
20:42 <nipos> Theme switching is fixed,does already look not that bad on the current avatars.linux-kernel.at and my not yet merged pull request will fix the rest
20:42 <clime> ye I was whining about this feature being there. it's cool Oliver implemented it
20:42 <tleguern> In the browser dev console I now see an error : Bootstrap's JavaScript requires jQuery
20:44 <nipos> avatars.linux-kernel.at does often have outages these days.Needed three trys to open it and I see the jQuery error,too.It's because the server returns errors again when trying to load assets
20:45 <nipos> If you reload it often enough,it may work
20:46 <tleguern> Ah yes it works some times.
20:46 <@fmarier> The ip_address field is indeed a legacy thing. It's only ever filled in with 0.0.0.0.
20:46 <@fmarier> And the database only has that value as well.
20:46 <sumpfralle> yes, the import does this, too. But I am still surprised that this field is there at all in the new data model.
20:47 <@fmarier> Yeah, since the new stack is not schema-compatible with the old one, there's no point in keeping this around.
20:47 <@fmarier> I kept it in the old stack because doing DB migrations is hard :)
20:47 <nipos> It's totally unneccessary if it's not even used so we should really remove it
20:49 <sumpfralle> fmarier: I understand your pain and I am glad, you used the zero-ing approach :)
20:49 <@fmarier> That's also the approach that mod_removeip (Apache module) uses
20:50 <@fmarier> because actually removing the IP address from requests would be extremely hard.
20:51 <sumpfralle> Yes, it is only about storing/logging. All the rest is hard to avoid ...
20:51 <sumpfralle> Next topic: "retro avatars"?
20:52 <nipos> What do you mean by that?
20:52 <sumpfralle> item 4 in https://pad.riseup.net/p/libravatar-future-irc
20:52 <sumpfralle> (I have no idea, too)
20:52 <nipos> Oh,I didn't know that this pad is still in use
20:53 <sumpfralle> ofalk made good use of it :)
20:53 <sumpfralle> (it is always linked in the description for the next meeting)
20:53 <sumpfralle> (but it was mainly empty up to now)
20:54 <tleguern> I was the one putting the retro avatar bits.
20:55 <tleguern> My point is there is no definition of the algorithm made to generate these images.
20:55 <tleguern> Many provider have them, like Gravatar and Github, but the images are differents.
20:55 <clime> it seems to be automatically generated image in ivatar code, right?
20:55 <tleguern> Yes
20:55 <clime> https://git.linux-kernel.at/oliver/ivatar/blob/master/ivatar/views.py#L148 for the record
20:57 <Unit193> Or perhaps something like how https://en.gravatar.com/site/implement/images/ explains them?
20:58 <clime> hmm, those bits are used only if forcedefault is set
20:59 <clime> together with robohash and monsterid
20:59 <tleguern> Unit193: the generation algorithm used by Gravatar is not public as far as I know
20:59 <clime> (that's a pity)
21:00 <tleguern> With the gravatar fallback feature this code might not be used anymore without forcedefault, you are right.
21:01 <clime> ye
21:02 <sumpfralle> tleguern: do you intent to try to create the same (recognizable) image for a given email addresse - as distributed by gravatar or libravatar?
21:03 <sumpfralle> Or is your point just the publically documented nature of the code in order to allow other services to generate the same recognizable images?
21:03 <tleguern> sumpfralle: We can't really do anything about images generated by Gravatar but we can at least have coherance among implementations by describing the algorythm in the doc. The point of Libravatar is to provide unique images after all.
21:04 <tleguern> But it might be a bit much
21:04 <sumpfralle> Documentation can never be too much :)
21:04 <sumpfralle> I appreciate your goal.
21:06 <sumpfralle> I will take a look at the bit of code, try to separate it a bit (to get a named location in the code) and mention it in the wiki documentation.
21:06 <tleguern> Ok :)
21:06 <sumpfralle> Next topic: API documentation?
21:07 <tleguern> I am willing to update it with the result from our mailing list discussion
21:07 <sumpfralle> cool!
21:07 <sumpfralle> We stick with the API documentation in the wiki - correct?
21:08 <sumpfralle> (I have no objections)
21:08 <tleguern> As of your last email clime: yes by ignore I meant “replace it with the default value/behaviour”.
21:08 <clime> cool
21:08 <tleguern> For now everything is there so yes.
21:08 <clime> thanks
21:08 <sumpfralle> Next topic: Robohash?
21:09 <sumpfralle> the issue (https://git.linux-kernel.at/oliver/ivatar/issues/13) does not include example images - how can we enjoy the beauty?
21:10 <tleguern> It is a public project: https://robohash.org/
21:11 <sumpfralle> ok - that was too easy :)
21:11 <nipos> It's nice and it's already implemented as far as I know.
21:11 <sumpfralle> so we are happy, that ofalk added this nifty feature :)
21:12 <tleguern> Here is mine:
21:12 <tleguern> https://avatars.linux-kernel.at/avatar/4751ed9aae86881d2b45dd0512c3e14a?d=robohash&f=y
21:12 <sumpfralle> a little bit grumpy :)
21:13 <tleguern> They are much, much nicer than wavatar
21:13 <sumpfralle> nice!
21:13 <tleguern> Ahah
21:13 <tleguern> And the suit is pink, not yellow as it is the current fashion in France
21:13 <sumpfralle> :)
21:13 <nipos> Mine looks good,too: https://avatars.linux-kernel.at/avatar/6b0ebb5c14be9d8b7626359b237df45cf196c7ff7b27cb2a39d39b6ccfff3572?s=100&d=robohash&f=y
21:14 <nipos> I really like them :D
21:14 <clime> i have one here for a change http://libravatar-stg.fedorainfracloud.org/avatar/d41d8cd98f00b204e9800998ecf8427e?default=robohash&forcedefault=y
21:14 <sumpfralle> so the primary effect of robohash is to encourage users to exchange their cute robohash'ed images :)
21:15 <clime> mine is like Darth Maul lol
21:16 <sumpfralle> OK - so we all agree, that ofalk picked the priorities right :)
21:16 <nipos> Yes :)
21:16 <sumpfralle> Next topic (we are almost done!): "needsdocs"?
21:17 <sumpfralle> Could someone give an introduction?
21:17 <sumpfralle> https://git.linux-kernel.at/oliver/ivatar/issues?scope=all&utf8=%E2%9C%93&state=all&label_name[]=needsdocs
21:18 <tleguern> wait ofalk allows to choose the robohash set
21:18 <tleguern> http://libravatar-stg.fedorainfracloud.org/avatar/d41d8cd98f00b204e9800998ecf8427e?default=robohash&forcedefault=y&s=400&robohash=set3
21:18 <tleguern> I am not sur this part needs to be documented
21:18 <sumpfralle> why not?
21:18 <sumpfralle> too much individualism?
21:18 <tleguern> Yes
21:19 <nipos> At least robohash with its many features does absolutely need documentation
21:19 <tleguern> And it could be done with d=robohash-set3 for example
21:19 <nipos> Maybe I'll find some time to write some docs
21:19 <sumpfralle> I would not encourage to overload "d" with even more options.
21:20 <sumpfralle> This would break, if a client requests a new set, that is not (yet) supported and will fallback to the native default (no robohash at all).
21:20 <sumpfralle> nipos: writing docs in the wiki would be great
21:21 <sumpfralle> ofalk already admitted that he does not enjoy this - so we better should ...
21:21 <tleguern> sumpfralle: that's why we discussed a bit about playing with the OPTION http verb ;)
21:22 <clime> i can't find official api docs for robohash but if there are one we could perhaps just link them
21:22 <sumpfralle> I did not follow that one - ok ...
21:23 <sumpfralle> Next/last topic?
21:23 <nipos> It's documented on http://robohash.org
21:23 <sumpfralle> so our behaviour should follow it closely and avoid documentation duplication ...
21:24 <clime> ye ok but we giving just a subste of the options https://github.com/e1ven/Robohash/blob/master/robohash/robohash.py#L109
21:24 <clime> so ye would be nice to have somewhere mentioned what options we support, i think
21:24 <sumpfralle> yes
21:25 <sumpfralle> The last topic would be something about OpenID. It sounds like a quick note about progress of ivatar. Who can describe it?
21:25 <tleguern> I don't use OpenID so can't really talk about it.
21:26 <nipos> Same for me
21:26 <sumpfralle> hm: *who* added this point to the notes? Probably ofalk?
21:27 <sumpfralle> In this case maybe he will enlighten us with a separate mail, if it is worth the trouble :)
21:27 <tleguern> It is in the same colour as his other edits, so most probably
21:27 <sumpfralle> I am feeling, we should get close to the end of the meeting. Or do you have other topics?
21:27 <tleguern> Good for me.
21:29 <clime> i am good too, I will probably try to make sure everything is ready for potential switch of libravatar.org to the fedora cloud machines.
21:29 <sumpfralle> great!
21:29 <sumpfralle> The next meeting would be the 23rd of December. Should we stick to it or pick the 30th instead?
21:29 <sumpfralle> for me it does not matter
21:30 <tleguern> Won't be possible for me on the 23
21:30 <nipos> I vote for the 23rd.Would be nice to switch to the new software with the new year but that can't be done within one day.
21:31 <sumpfralle> clime: I think, your voice will be the decisive one :)
21:31 <clime> i agree it would nice but we will need to coordinate with fmarier on that
21:32 <clime> i am ok with 30
21:32 <sumpfralle> Regarding the switch: I firmly believe in January :)
21:33 <clime> ye me too
21:33 <sumpfralle> So let us pick the 30th. I hope, you have time on that date, too, nipos.
21:33 <nipos> Sure,I always have time on sunday evenings
21:33 <sumpfralle> great - so be it!
21:34 <sumpfralle> Have a great Sunday evening!
21:34 <clime> you too!
21:34 <@fmarier> I'll try to make it on the 30th, but I'm not sure yet I'll be able to be there.
21:34 <@fmarier> In terms of doing the switch over, let's aim (at the earliest) for mid-January.
21:34 <sumpfralle> yes, sounds reasonable
21:35 <tleguern> Sounds good :)
21:35 <tleguern> See you next time, good evening everyonw.
21:38 <@fmarier> bye everyone

References