libravatar-fans team mailing list archive

[Lars Kruse <lists@xxxxxxxxxxxxx>]

Hello,

we just finished our IRC meeting.
(technical detail discussions being still ongoing)

The next meeting will happen on the 19th of August at 19:00 UTC.

Attached you find the full log of today's meeting.
The wiki contains a summary:
  https://wiki.libravatar.org/shutdown-coordination/?updated#index2h2
(thanks to kumy for taking notes)

We discussed about:
* GDPR / data privacy issues
* hosting details
* nipos' design proposal
* technical requirements for mirrors (TLS, SNI, ...)

Enjoy the details!

Cheers,
Lars

21:02 <sumpfralle> here is an agenda proposal: https://pad.riseup.net/p/libravatar-future-irc
21:02 <sumpfralle> I propose, that we start with a review of the last week?
21:02 <sumpfralle> Who wants to start?
21:03 <sumpfralle> ij_: ?
21:03 <ij_> new VM for old instance is set up and running
21:03 <ij_> francois has account & sudo access
21:04 <sumpfralle> is it already running as the one-and-only server of libravatar.org?
21:04 <sumpfralle> (hurray for the quick progress, btw.)
21:04 <opal> "make sure that the SSL config for the new mirror matches the other ones"
21:04 <ij_> no... apparently he hasn't found time to install something
21:04 <opal> i'll probably be disqualified simply for this
21:05 <opal> i refuse to use non-FS cipher sets
21:05 <sumpfralle> opal: we will continue later with that topic ...
21:05 <opal> god i hate this meeting format
21:06 <sumpfralle> ok - so the transfer of the old VM to the new interim VM is not finished, yet. But it is on the horizon?
21:06 <kumy> may I ask, how many of us / who is present today?
21:06 <opal> not me i guess, since i cant speak out of turn
21:06 <opal> bye
21:06 --> fmarier_ (~francois@fsf/member/fmarier) hat den Channel #libravatar betreten
21:07 <sumpfralle> opal: I am interested in your thoughts (in a private discussion or after the meeting) about improvements
21:07 <sumpfralle> ok - good point
21:07 <sumpfralle> who is here?
21:07 <sumpfralle> Lars
21:07 <nipos> I'm here,too
21:07 <ij_> Ingo
21:07 <nipos> Niklas
21:08 <kumy> ok
21:08 <sumpfralle> ok - let us continue ...
21:08 <@fmarier_> I'm here
21:08 <sumpfralle> cool!
21:09 <sumpfralle> My last question was: so the transfer of the old VM to the new interim VM is not finished, yet. But it is on the horizon?
21:09 <@fmarier_> Status for that is that ij_ has created a new VM and that I will start to set it up today and tomorrow.
21:09 <sumpfralle> great
21:09 <@fmarier_> One thing that did get done this week is that Asako's mirror is now live.
21:10 <sumpfralle> \o/
21:10 <@fmarier_> That was another thing that needed to migrate before the Rackspace shutdown.
21:10 <sumpfralle> Thus we will manage to avoid further hosting costs for now, based on ij_ given VM?
21:10 <sumpfralle> "ij_'s given VM"
21:11 <kumy> does the vm fullfill the requirements? os/ram/disk space?
21:12 <@fmarier_> I don't know the financial arrangements around ij_'s VM, so I can't comment on that, but there won't be another Rackspace bill.
21:12 <@fmarier_> As far as the technical specs, it's the same as the existing VM, except with double the RAM.
21:12 <kumy> I read fmarier_ can connect to the vm, this is a good point
21:12 <kumy> great
21:13 <@fmarier_> Yes, I have ssh access and root on the VM, so it's ready to be setup.
21:13 <ij_> the new VM is on my own colocated server, the VM is just another VM of many
21:13 <ij_> so, no additional costs for me
21:13 <kumy> (thanks ij_ for providing resources :thumbup)
21:14 <sumpfralle> +1
21:14 <sumpfralle> OK - next topic?
21:14 <sumpfralle> (kumy - thanks for typing the protocol in the pad in parallel!)
21:14 <kumy> ;)
21:14 <sumpfralle> should we discuss the GDPR? Or first smaller topics?
21:15 <sumpfralle> (the next one of you raising an oppinion decides about the next topic)
21:15 <kumy> I'm not an expert of GRPR sorry, I don't know implication yet, hope you'll have more ideas on this topic
21:16 <sumpfralle> ok - you mentioned GDPR - so let us start with that one
21:16 <nipos> I don't know that much about the GDPR problem,too
21:16 <sumpfralle> :(
21:16 <sumpfralle> anyway
21:16 <opal> gdpr doesnt apply to personal entities
21:16 <opal> i assume libravatar doesnt qualify as one though
21:16 <kumy> should we threat this point as a lawyer, or as humans?
21:17 <sumpfralle> kumy: what is the difference?
21:17 <opal> libravatar isnt big enough to warrant lawyer consultation on this
21:17 <nipos> And I don't know why changing the software should be a problem with GDPR.
21:17 <opal> just disclose how you use personal information and offer a way to request/delete information on users if you want
21:17 <opal> should be more than enough
21:17 <kumy> as human, I would say, let's just transfer the data as is as our first plan is to migrate 1 for 1
21:17 <kumy> as a lawyer it may be differetn, no idea
21:18 <@fmarier_> Also, I would point out that we've had both data deletion and data export since the first release.
21:18 <opal> lawyers would advise similarly
21:18 <opal> ok then you should be fine
21:18 <sumpfralle> ok - maybe let us start with the questions, I put in the agenda - I think, they offer a path for the thought ...
21:18 <@fmarier_> So it's likely that the only thing missing is a privacy policy.
21:18 <sumpfralle> which data is currently stored?
21:18 <opal> yes, privacy policy would be good
21:18 <@fmarier_> sumpfralle: email address, username, any uploaded photos, linked OpenIDs
21:19 <sumpfralle> ok - assuming, that we git rid of visitor activities (IP addresses and so on in the webserver log)
21:19 <@fmarier_> We used to store IP addresses as well, but that's all gone.
21:19 <opal> you dont even store IP addresses transiently?
21:19 <opal> to identify abuse or issues with the service
21:20 <opal> i mean if you can do away without that somehow, thats fine, but i find it odd from a sysadmin standpoint
21:20 <@fmarier_> On the mirrors, we have mod_removeip running which records all IP addresses as localhost, so there are no IP addresses in any of the logs
21:20 <opal> gotcha
21:21 <@fmarier_> On the master, I believe we might have them stored in Apache access logs, with a log retention period of 7 or 14 days
21:21 <opal> i suppose thats enough if you still have access date and useragent and all that good stuff
21:21 <opal> i have to run a couple popular hidden services on tor so i dont really have ip address info available even if i wanted it
21:22 <@fmarier_> libapache2-mod-removeip is also installed on the master server so we may not have IP addresses anywhere
21:22 <@fmarier_> apache log retention is 10 days
21:23 <kumy> fmarier_, do you mean ip adresses are deleted after 10 days?
21:23 <opal> logs in total
21:24 <@fmarier_> the logs are deleted after 10 days. IP addresses are not stored anywhere else that I know. Let me check if they're even in the Apache logs...
21:24 <sumpfralle> probably we may even want to store less in the future, but this is something that does not really require planning and preparations :)
21:24 <@fmarier_> Yes, there are IP addresses on the master server, not sure why exactly
21:25 <@fmarier_> ah, the removeip module was installed but not enabled :)
21:25 <@fmarier_> Fixed.
21:25 <kumy> :)
21:26 <sumpfralle> Cool! Now that we have an idea about the data we are talking about, I would like to switch to potential requirements.
21:26 <@fmarier_> As of now, we no longer store IP addresses on the master server either
21:26 <@fmarier_> And in 10 days, all of the old ones will be gone.
21:27 <sumpfralle> My understanding of (German) privacy laws is, that we need explicit consent from users for storing their data. Thus if they did not click any kind of checkbox up to now, then we should add this for the future web interface.
21:27 <sumpfralle> Does that match your understanding?
21:28 <sumpfralle> ("checkbox" -> explicitly agreeing to the storage of the given amount of data and their intented usage)
21:28 <kumy> what should we do of users data if they not come back to consent?
21:28 <nipos> That's absolute nonsense
21:28 <opal> tell them that the data is required for service operation and offer to delete their data
21:29 <nipos> They gave consent by filling out the form and clicking on register.
21:29 <tklk> as libravatar only needs hashes to serve avatars the site could be changed to even remove that requirement (and only store the md5/sha) of their email/openid
21:29 <opal> what about data before this point
21:29 <opal> i think thats the whole worry
21:29 <@fmarier_> No, we need the email for password resets.
21:29 <nipos> And no additional data like IPs are stored so there's no problem
21:29 <@fmarier_> I think there's a strong case to be made for the fact that we collect only what is absolutely necessary in order to provide the service.
21:30 <sumpfralle> opal: yes, I think, that is the interesting detail. But before we should probably get a consent about what the actual requirements are, that we want to follow.
21:30 <tklk> fmarier, we don't because when they enter their email for wanting to do a pass reset then it could be hashed and compared to existing hashes
21:30 <sumpfralle> fmarier_: indeed
21:30 <@fmarier_> Also, users choose to register, add their email and upload a photo.
21:31 <opal> tklk: would you require both the email and the username to be entered in that case
21:31 <@fmarier_> There's not really any point in having a libravatar account if you don't want your photo to be stored on the server.
21:31 <opal> well never mind it can work without username
21:31 <@fmarier_> Though, of course, you can totally just pick a username and a password and keep your account empty if you want.
21:31 <sumpfralle> understood - but nevertheless (my understanding), we need explicit consent form the user for doing so
21:31 <opal> that would be a good idea then, to compare with the hash
21:31 <nipos> I know no service in the whole world which deleted all accounts because of GDPR.You registered so the data you entered yourself (no additional stuff) is saved.What's the problem?!
21:32 <opal> i could get into GDPR politics too but the fact is it's here and we need to deal with it
21:32 <tklk> the one downside is that like fmarier said is that users add photos to accounts, and when they manage multiple emails they wouldn't know which avatar they are adding to a specific account.
21:32 <opal> i take the easy route because im an american and i just give a privacy policy of "oh yeah your information is public now"
21:33 <opal> all the information i ever require is totally user-entered data though, so i think its fair
21:33 <opal> tracking is a no-no on my sites
21:33 <@fmarier_> It might be worth reminding people (the first time they do it) that by associating a photo with an email, they are making it public. But that's outside of the requirements of the GDPR.
21:33 <kumy> what about adding a new check box to the site, and send a massing mailing asking user to "validate" GDPR, or archive/remove their account?
21:34 <@fmarier_> kumy: what's the risk of not doing it though?
21:34 <opal> well yeah, other services sent out GDPR notices
21:34 <opal> i think it might even have been a requirement
21:34 <@fmarier_> If someone complains, it's easy enough to point out to them how to delete their data entirely.
21:34 <opal> email everyone so they have the option to complain though
21:34 <nipos> But they didn't automatically delete thousands of accounts...
21:34 <tklk> risk of sending out mass notice at this point is that there is no consent that users gave to send out emails.
21:34 <sumpfralle> I think, we have a bunch of different understandings of the legal requirements here. Thus I have the feeling, that we cannot turn this into any kind of decision or improved understanding at the moment. Thus I would propose to discuss this topic on the mailinglist. This would feel like the proper medium for an in depth discussion of this kind. What do you think?
21:34 <opal> thats fine
21:35 <opal> i think there can still be a bare minimum done for now to comply with gdpr
21:35 <opal> stuff we all agree with
21:35 <nipos> I think we should get rid of this annoying point as soon as ossible
21:35 <nipos> *possible
21:35 <opal> privacy policy? mass email telling everyone about the new privacy policy?
21:35 <opal> seems simple and uncontroversial
21:35 <kumy> Do we store cookies on users computers?
21:35 <opal> no new checkboxes yet
21:36 <@fmarier_> yes, there's a login cookie
21:36 <kumy> cookies are also part of GRPDR if I'm not mistaken
21:36 <@fmarier_> No cookies from the mirrors though (unless Gravatar sets one).
21:36 <nipos> Add a simple cookie consent and everything is fine for session cookies
21:36 <opal> cookies are a part of EU cookie law regardless
21:36 <sumpfralle> opal: given that, we are transitioning to another implementation, we probably do want to avoid interim changes in the current code base
21:37 <opal> gotcha
21:37 <nipos> The user only needs to agree BEFORE setting the cookie if it's for tracking
21:37 <sumpfralle> Proposal: move this discussion to the mailinglist?
21:37 <@fmarier_> I'm not sure a mailing list discussion will be very productive to be honest.
21:37 <@fmarier_> Nobody has a clear understanding of what (if anything) we need to do.
21:38 <sumpfralle> This is bad ground, indeed. Do you have a different idea?
21:38 <@fmarier_> (with respect to keeping the existing data or giving notice and deleting)
21:39 <@fmarier_> I can see two options: 1. we keep up with our lean data practices ignore the problem until it becomes a problem, 2. we reach out to a pro-bono lawyer
21:39 <nipos> +1 for 1
21:39 <tklk> +1 for option one
21:39 <kumy> [this law is good for user's privacy, but a nightmare for sysadmins :)]
21:39 <@fmarier_> If there are any concrete privacy improvements (e.g. hey, you forgot to enable mod_removeip) then sure, let's discuss those and get them done.
21:39 <kumy> +1 for option one
21:39 <nipos> Because I think there is now problem.We don't store more data than the user filled in himself.
21:40 <kumy> we have the download and delete account ready
21:40 <@fmarier_> But throwing a cookie banner or adding annoying checkboxes is not super productive unless we know we really have to do it.
21:40 <nipos> Cookie banner is an requirement even for the session cookie but that's all.
21:40 <kumy> we may miss a TOS/Privacy policy when registering
21:40 <sumpfralle> I also tend to option 1 - incremental progress (if necessary) can be added later
21:41 <opal> for cookies, cant you just put a prominent indicator on the login page and thats it?
21:41 <@fmarier_> It would be nice to have a privacy policy, but I don't know how to write one that would be valid.
21:41 <opal> by clicking "log in" you accept to session cookies
21:41 <opal> i can offer a privacy policy based off what is put in the notepad link
21:41 <nipos> There are free privacy policy generators online
21:41 <tklk> opal's suggestion complies with GDPR
21:42 <opal> im not a lawyer but i can write a decent enough privacy policy
21:42 <opal> i know my english xd
21:42 <kumy> "if you don't agree agree to accept cookies, how will you delete your account?"
21:42 <nipos> Just check some boxes,click on generate and copy it into the website.
21:42 <opal> kumy: email the admin
21:42 <opal> email doesnt require cookies
21:42 <kumy> opal, +1
21:42 <@fmarier_> The cookie stuff is changing in Europe too with the ePrivacy directive. Moving away from the useless cookie banners is one of the reasons for revisiting that law. I think we can probably sit on that one too and wait to see what the new requirements are.
21:42 <opal> thank god
21:42 <opal> i hated that cookie law
21:42 <opal> cookies arent personal information inherently
21:43 <@fmarier_> I expect there will be exceptions for common use cases like a login cookie that's not used for anything else.
21:43 <nipos> The new law sucks even more :/
21:43 <opal> oh :v
21:43 <@fmarier_> But we'll see, it hasn't shipped yet :)
21:43 <opal> i'll draft a privacy policy and publish it for your considerations later
21:43 <sumpfralle> cool!
21:43 <opal> release under PD like all my other work so you can use it as you see fit
21:43 <sumpfralle> kumy, fmarier_, opal, ij_: what is your opinion about fmarier_'s proposal from 19:39:04 (UTC)?
21:43 <nipos> The banners won't go away,there'll be different ones with more options but in general it's still the same annoying shit nobody cares about
21:44 <kumy> what about adding a new message on connection as proposed by opal, and wait a few month to see how it (laws) goes
21:44 <opal> sumpfralle: choice 1
21:44 <opal> this isnt lawyer territory just yet
21:44 <kumy> sumpfralle, +1 for choice 1 "ignore the problem until it becomes a problem"
21:45 --> tleguern (56d74836@gateway/web/freenode/ip.86.215.72.54) hat den Channel #libravatar betreten
21:45 <tleguern> Hello, sorry I am late.
21:46 <opal> hi
21:46 <sumpfralle> welcom!
21:46 <sumpfralle> e
21:46 <nipos> hi
21:46 <kumy> hi
21:46 <ij_> I think for the old software we shouldn't care that much about GDPR anymore, but we should have a good GDPR-compliant new codebase and switch to it when ready
21:46 <sumpfralle> ij_: +
21:46 <@fmarier_> I would also point out that in the past 8 years, exactly 0 people have complained about the lack of a cookie banner or a privacy policy :)
21:46 <sumpfralle> there are just not enough lawyer's visiting libravatar :)
21:46 <@fmarier_> So it could be a while before "it becomes a problem".
21:46 <ij_> the only thing to make public until then is to make a website which data is being used
21:46 <kumy> that's what I mean with "<kumy> as human, I would say, let's just transfer the data as is as our first plan is to migrate 1 for 1"
21:47 <sumpfralle> OK - maybe let us close this topic?
21:48 <kumy> tleguern, do you have the history? would you like a pastebin?
21:48 <nipos> Yes,close it
21:48 <sumpfralle> Summary: we think, we are currently complying with the law and we will take a deeper look, when we switch to the new code base.
21:49 <tleguern> I'm reading what's on Riseup, I guess it is the essential
21:49 <sumpfralle> ok - the next topic _could_ be the evaluation of the new implementation
21:49 <tleguern> But thanks kumy
21:49 <sumpfralle> but oliver is not here, right?
21:49 <tklk> correct
21:49 <nipos> He's in holidays
21:49 <tleguern> On this subject I started some testing and ended up opening two issues on his gitlab
21:50 <sumpfralle> great
21:50 <sumpfralle> do you have a vague feeling for its state?
21:50 <kumy> Oliver send a mail just before the meeting
21:50 <sumpfralle> or we just postpone this
21:50 <kumy> He said "I‘m pretty sure that Michal (clime) should be able to answer most questions"
21:50 <kumy> but no clime too :(
21:51 <nipos> He isn't here,too
21:51 <sumpfralle> the redirect failed :(
21:51 <sumpfralle> ok - so let us get on with the next topic?
21:51 <kumy> ok
21:51 <nipos> Yes
21:52 <sumpfralle> we have the topic "Discuss the hosting options for the new implementation" - but I could imagine, that we have nothing specific to discuss about, right now.
21:52 <tleguern> sumpfralle: what people want is already implemented: you can ask for a picture and its size, that works.
21:52 <sumpfralle> good!
21:52 <tleguern> The missing bits are secondary features like d=retro
21:53 <tklk> too bad clime isn't here because he was working on hosting with fedora infra team
21:53 <sumpfralle> and I think, the data model is not 1:1 compatible
21:53 <sumpfralle> yes, but let us just postpone it. Next time the summer will be almost over :)
21:53 <nipos> Migration won't be a problem they said last week
21:53 <kumy> would be nice to not fallback to gravatar and have "our" fallback system
21:54 <sumpfralle> This sounds like a feature request :)
21:54 <nipos> I agree
21:54 <opal> for default avatar, use the green GIMP pepper
21:54 <opal> :^)
21:54 <sumpfralle> There will be so many interesting details to be discussed for the future :)
21:54 <nipos> Fallback to Gravatar is a nice feature if you want it but it should be able for the website owner (API parameter) to disable that as Gravatar tracks more things than Libravatar does
21:55 <opal> gravatar fallback is nice, can i get more information on that later
21:55 <kumy> nipos, some companies (as I'm faced to) would have a private libravatar hosting, but no access to gravatar
21:56 <@fmarier_> nipos: it's already an API parameter in a way
21:56 <kumy> so having the choice is nice
21:56 <@fmarier_> if you use an MD5 hash, it redirects to gravatar. if you use a SHA256, it doesn't.
21:56 <nipos> Oh ok,I didn't know that
21:56 <kumy> neither I
21:56 <tklk> kumy, you can set a custom fallback already
21:57 <nipos> I thought more about a ?gravatar=false option
21:57 <@fmarier_> the part where we do redirect to gravatar and could avoid it is for the d=retro and friends
21:57 <kumy> even identicons?
21:57 <@fmarier_> for those ones, we don't have an implementation of multiple different icons
21:57 <@fmarier_> so we go to gravatar instead
21:58 <opal> gravatar should be opt-in
21:58 <@fmarier_> https://bugs.launchpad.net/libravatar/+bug/769794
21:58 <opal> ?gravatar=false by default, =true if user-specified
21:58 <sumpfralle> I was just about to ask for a related bug tracker issue :)
21:58 <nipos> I prefer opt-out to prevent breaking existing links
21:58 <@fmarier_> opal: there's no way to redirect to gravatar if you're using SHA256 though
21:59 <@fmarier_> and if you don't want libravatar, then why not use a SHA256 instead of an MD5?
21:59 <@fmarier_> s/libravatar/gravatar/
21:59 <opal> oh i see what you mean
21:59 <opal> i didnt think it through sorry :p
22:00 <@fmarier_> What I'm hearing though is that this should be made more explicit on https://wiki.libravatar.org/api/
22:00 <@fmarier_> patches welcome :D
22:00 <sumpfralle> and the future will probably see the light of a more explicit query argument fulfilling this purpose :)
22:00 <sumpfralle> yes
22:00 <kumy> not sure if tools like Jira/GitLab offer to use SHA256 :/
22:01 <sumpfralle> Who is interested now in the discussion about future hosting details?
22:01 <tleguern> kumy: I think it is just better to implement the various d= options as separate webservices and so owners can point to whatever they want when they configure the service.
22:01 <nipos> Gitea uses SHA256 as far as I know,there it doesn't redirect to Gravatar
22:02 <sumpfralle> I really do not want to stop an interesting technical discussion, but I think, we should _really_ take the time to take a look at nipos design proposal and then maybe just finish the meeting time and continue to discuss interesting details?
22:02 <kumy> sumpfralle, may you remind what were the already proposed options for future hosting?
22:04 <sumpfralle> I think, Fedora offered some cloud-based things (details need to be determined). The obvious alternative is probably something like the VM, that ij_ is giving to us right now (or buy this from a provider for a few euros per month).
22:04 <sumpfralle> Question: should we go deeper into this topic now or postpone it?
22:04 <kumy> let's add the Digital Ocean sponsoring
22:04 <nipos> Didn't we already vote for Fedora?
22:05 <kumy> (can't remember)
22:05 <opal> digital ocean is sponsoring?
22:05 <kumy> opal, I've read it in the wiki page
22:05 <opal> interestin
22:06 <kumy> https://wiki.libravatar.org/shutdown-coordination/ "They offered $200 to host two droplets for one year."
22:06 <tklk> Coming from another project that was sponsored by DO, we have had problems with communications in the past
22:07 <tklk> and the sponsoring ran out without notice
22:07 <kumy> tklk, too bad :(
22:07 <sumpfralle> anyway: at the current usage level we are talking about 5 Euros per month for random generic hosting costs (+1 Euro for the domain). Based on this trivial costs, we should not focus too much on sposoring, I think, but find the best technical approach instead.
22:07 <nipos> That's not an acceptable solution.We could run it for one year but how to continue after that?Fedora would do it forever as far as I know
22:07 <tklk> so we had to suddenly get other sponsorship to keep things online
22:07 <ij_> $200 for two droplets for a year == $100/droplet/year ==> $8.33/droplet/month
22:07 <tklk> I don't blame DO though because we were getting free money but it would've been nice to get a heads up
22:07 <ij_> tklk: and then there is the offer of smurf for hosting
22:08 <ij_> the DO offer is nice - for one year. But what's after that year?
22:08 <opal> im not a fan of DO personally
22:08 <opal> what are you hosting with this infra exactly
22:08 <tklk> things are better now because we went to opencollective and are now funded by users directly
22:08 <kumy> we may use them as a slave in the network.
22:09 <opal> im willing to offer a slave but like i said earlier, i have some concerns with the requirements
22:09 <ij_> I think the point is: whoever controls the spice, controls^W^Wdomain, controls where the hosting is
22:09 <tklk> on a note about language, let's refer to them as mirrors (instead of "slaves")
22:10 <kumy> I will also help in proviing a slave too
22:10 <opal> i can censor ip addresses in logs no problem, i can spare the resources no problem, but i do use nginx instead of apache, i do use strict tls rules, and i do take advantage of SNI for now
22:10 <kumy> ^I will also help in proviing a _mirror_ too
22:10 <ij_> I'm also hosting an Aminet mirror and there mirror gets added to a round-robin if they are up and removed from round-robin when they are down
22:11 <kumy> having mirrors running in a docker image would be a requirement for me
22:11 <ij_> so, maybe the question about hosting is more a question about controlling the domain
22:11 <kumy> and may help having more mirrors?
22:11 <kumy> ^docker image^docker container
22:12 <@fmarier_> If Fedora is able to serve the images too, then there's no point in having mirrors.
22:12 <@fmarier_> That's purely to spread the bandwidth/load.
22:12 <@fmarier_> But it adds a lot of complexity.
22:12 <ij_> fmarier_: which is not really high, as I understoo
22:12 <ij_> d
22:12 <tklk> Per domain hosting I propose it gets moved to fedora rather than an indivual
22:12 <sumpfralle> I have the feeling, that we can postpone this discussion a bit and first get the new implementation ready. Based on ij_ generous offer of a VM for now, we have no time pressure attached. In this case I would see a slow collection of options and pros/cons in the wiki and on the mailing list as a suitable approach.
22:12 <tklk> **individual
22:12 <kumy> I've read in a blog post that not all implementation follow the mirror protocol, right?
22:13 <nipos> No,that's a completely different point
22:13 <@fmarier_> kumy: you're probably thinking of the _federation_ protocol
22:13 <kumy> fmarier_, yes
22:14 <kumy> is it really different?
22:14 <@fmarier_> that's a different problem and one that's not relevant for Libravatar the service, but rather for Libravatar the project.
22:14 <kumy> ok
22:14 <nipos> If you run an email address under an own domain,you can run your own Libravatar service for that address.But most implementations always use libravatar.org
22:14 <@fmarier_> It's up to whoever is writing a client to follow the protocol correctly.
22:15 <kumy> (argh, AFK 5min)
22:16 <@fmarier_> My experience is that most implementations support federation. I've tried to label the exceptions on https://wiki.libravatar.org/libraries/
22:16 <@fmarier_> and often when a new implementation comes out without, it's just a matter of pointing out the missing federation for authors to add it.
22:16 <@fmarier_> But I think gitlab may not have federation, and that's likely a big user of Libravatar.
22:16 <opal> wait, whats the method used for mirroring
22:17 <opal> for some reason i thought it was rsync or something
22:17 <@fmarier_> opal: yes, rsync from the master
22:17 <opal> oh good
22:17 <tklk> Gitea uses the federated-ness of libravatar
22:17 <opal> the how-to doesnt mention it
22:17 <@fmarier_> each mirror ssh'es into the master and rsync's files over
22:17 <opal> in fact i think the how-to is debian-specific
22:18 <@fmarier_> yes, a lot of the sysadminy parts of the service are automated into the various debian maintainer scripts
22:19 <opal> i'll ask later about setting it up manually
22:19 <sumpfralle> Let us switch now to nipos' design proposal?
22:19 <ij_> how would that be handled when the project is on fedora? will the "debian support" continue?
22:20 <kumy> (back)
22:20 <opal> supporting multiple distros is ideal
22:20 <opal> if theres enough manpower to do so obviously
22:20 <nipos> I can help with Arch support if needed but I can't run a mirror,too few money :/
22:20 <tklk> clime is looking into using fedora infra's openshift implementation, and oliver has his implementation up and running with openshift
22:20 <ij_> sumpfralle: I think nipos design is nice... of course you can always argue about smaller things like the tilted line or how many space is betweeen top of the headline and below it
22:20 <kumy> does the fedora hosting will allow ssh for syncing?
22:20 <tklk> so not OS specific
22:22 <sumpfralle> ij_: I fully agree. But I think, we should give nipos feedback. A simple "it is nice", is surely sufficient ...
22:22 <ij_> sumpfralle: I did this already some days ago ;)
22:22 <sumpfralle> "is surely sufficent" -> "would also be sufficient"
22:22 <kumy> ok to jump to the next point
22:22 <nipos> For those who haven't seen it until now,here's the link: https://codepen.io/niklasposlovski/full/RByopx/
22:22 <tklk> kumy, I'm leaning towards probably not, but as fmarier said above it's just to spread bandwith and fedora can handle that. however clime can give a better answer than me as I have no affiliation with fedora
22:23 <tklk> design looks great, but I don't see a license: https://github.com/vtex/tortin
22:23 <sumpfralle> looks good to me, too
22:23 <tklk> oh wait, I didn't scroll down to bottom of readme
22:23 <tklk> it's apache 2 license
22:23 <sumpfralle> nipos: which build/something tools do you use?
22:24 <sumpfralle> (just for being on the safe side of using a slightly well-known toolset)
22:24 <tklk> It's using bootstrap v3 which has been deprecated for some time as 4 is now out
22:24 <@fmarier_> might be time for a better tagline too :)
22:24 <kumy> design is clean and modern, I like it +1
22:24 <tklk> I am concerned about switiching to something that already needs to be upgraded
22:24 <nipos> It uses Less for the CSS,most things don't need to be compiled/builded
22:25 <nipos> Using an outdated CSS Framework isn't an security problem or similar.There's no need for upgrading
22:25 <kumy> bootstrap 4 is not compatible with older browsers too (it remind me the need of "No SNI"…)?
22:26 <sumpfralle> :)
22:26 <@fmarier_> I think it looks really good. We should probably update the default icon at the same time so that the colors match.
22:26 <nipos> I could change the colors of the design with a single variable
22:27 <sumpfralle> nipos: is this feedback sufficient for you? If yes, how will you proceed? (being curious)
22:27 <nipos> I tried it with Libravatars orange but I didn't like it that much.So yes,probably we should really switch to a newer icon
22:27 <kumy> https://getbootstrap.com/docs/4.0/getting-started/browsers-devices/ At least "If you require IE8-9 support, use Bootstrap 3." (even if I don't use those browser, don't know about old FF/Chrome,etc)
22:28 <@fmarier_> also, +1 to kumy's comments. it does look a less fresher and more modern.
22:28 <opal> uh, we're talking about the https://codepen.io/niklasposlovski/full/RByopx/ design?
22:28 <nipos> That feedback is good.I just wanted to know if I can use it or use something completely different
22:28 <tklk> that's reasonable. "objections" have been taken back
22:28 <nipos> Yes
22:28 <kumy> yes
22:28 <opal> what is the slanted lines everywhere on here
22:28 <@fmarier_> it makes the original CSS look like it was made 8 years ago ;-)
22:29 <ij_> nipos: I woould appreciate some alternatives for sure to choose between :)
22:29 <nipos> That's the best I found ;)
22:29 <tklk> note to whoever is doing the notes now I believe I was the only one with a different opinion so that line could be removed
22:29 <opal> i like my sites simple and still viewable without js or css, so i wont complain much if thats the case
22:30 <opal> but if the lines and boxes are slanted everywhere that could be distracting to people
22:30 <opal> oh never mind
22:30 <opal> my browser didnt render properly
22:31 <kumy> "We should probably update the default icon at the same time so that the colors match" did you talked about that icon? https://github.com/libravatar/libravatar/blob/7d3e069e18927df7d5e05bccdca7215210dd8063/static/img/libravatar_logo.svg
22:31 <opal> yeah this is fine as long as it works without js/css
22:31 <nipos> Yes
22:31 <opal> cool
22:32 <@fmarier_> kumy: yes, https://seccdn.libravatar.org/avatar/default.png
22:32 <opal> interesting, elinks doesnt do SNI
22:32 <kumy> Then I agree, icon should be part of the general refreshment
22:33 <nipos> I'm a horrible icon designer.Someone else should do it.
22:33 <tklk> gotta head out. have a good rest of meeting.
22:33 <sumpfralle> tklk: thanks
22:33 <sumpfralle> I think, we are closing anyway?
22:33 <kumy> tklk, see you
22:34 <nipos> One question is left
22:34 <sumpfralle> The question about the jessie mirror or the SNI requirement?
22:34 <nipos> The author of the design I used asks to keep the link back to his Github repository but it's not required...
22:35 <sumpfralle> ah, yes - I think, we can agree with that
22:35 <opal> the only useragent i see that doesnt support SNI is elinks, and elinks hasnt been updated in a while
22:35 <nipos> I kept it in my concept but should I keep it in the finished Libravatar code,too or remove it?
22:35 <opal> so i would say the issue is with elinks and not with SNI
22:35 <sumpfralle> opal: +1
22:36 <opal> the SNI requirement is moot if you all are also requiring non-PFS ciphers
22:36 <sumpfralle> nipos: I would say, he deserves a link, since we use his work
22:36 <opal> for me, anyway
22:36 <@fmarier_> one thing that could be modernized as part of the new implementation as well is to get rid of HTTP
22:36 <opal> yes HTTPS only sounds good
22:36 <@fmarier_> use a single CDN domain and redirects everything to HTTPS
22:36 <nipos> Ok,I'll keep it then
22:36 <sumpfralle> can we close the "organizational" part of the meeting and continue with the technical things?
22:37 <@fmarier_> HTTPS Everywhere already has a rule to upgrade libravatar
22:37 <sumpfralle> (relieving us from doing a procotol and summary)
22:37 <opal> dont get me started with https everywhere
22:37 <opal> do it right, use HSTS and redirect to https
22:37 <opal> this is 2018, https has been around for over a decade, all websites should have adopted by now
22:38 <opal> there is no valid upside to using http
22:38 <kumy> +1 for HSTS
22:38 <opal> unless youre using i2p or a tor hidden service, but that's outside of this scope
22:38 <nipos> Tomorrow I'll fork https://git.linux-kernel.at/oliver/ivatar and start integrating the new design (because someone asked how I'll continue)
22:38 <opal> i2p/onion wouldnt even be in the main cdn pool
22:39 <nipos> Tor hidden services aren't a problem.You can embed HTTPS images from HTTP websites,just the other way it's blocked
22:39 <sumpfralle> no one objected: the official meeting shall be deemed over now. See you in two weeks (19 UTC) for the next meeting. Have fun!
... technical discussions continued ...