01:25:27 OK, so about the proposed security page 01:25:44 Hopefully someone better at design/UI/UX than I can help me understand the optimal layout for this 01:28:30 Separately from this, I can make a PR that at least includes the CLSAG blag post... when could this get built/deployed? 01:28:44 I need to coordinate this datetime with OSTIF, who will also be posting the report on their own site 01:28:59 As a courtesy we'll be releasing the report simultaneously-ish 01:30:29 UI/UX? 01:30:37 where is rehrar? 01:30:50 To be clear, let's separate the two projects here 01:31:06 Project A is posting the CLSAG blag post and the audit report in a PR 01:31:22 Project B is developing a security page with VRP information and all audit report links 01:31:36 Project A needs to be coordinated with OSTIF, who say they would be ready as soon as Friday 01:31:47 Project B can be done at our convenience 01:31:52 (but after Project A) 01:35:57 If I make a PR for Project A, how soon could it be deployed and live? 06:44:06 sarang: Feel free to make a PR for A. There seems to be no clear agreement about how to show B. I can review A as soon as you make the PR, then we can ask luigi to merge and we should be able to deploy it soon after if necessary. 06:46:34 About B. I think we can make a simple page divided in two, with a VRP section and an audits section, then we can replace the "Vulnerability Response" link at the top of Getmionero with a link to this new page. We should also link to it from the MRL page 06:47:08 I can work at B as soon as we decide what we want to do. 06:47:32 .merge+ #1104 06:47:32 Added 07:45:38 -xmr-pr- erciccione opened issue #1107: Create "I2P" Moneropedia entry 07:45:38 -xmr-pr- > https://github.com/monero-project/monero-site/issues/1107 13:00:38 -xmr-pr- erciccione opened pull request #1108: README: updates + add 'Reviewing Process' section 13:00:38 -xmr-pr- > https://github.com/monero-project/monero-site/pull/1108 13:07:08 Yo 13:07:29 What is the best location in the source tree for the audit PDF, with the understanding that more will be added eventually? 13:07:51 And what's the proper way to reference these relative URLs in the markdown source for the blag post? 13:09:15 e.g. MRL papers live in `resources/research-lab/pubs`, but those don't need to be linked in posts 13:09:47 I would say resources/research-lab/audits 13:10:06 OK; how to reference properly from the post markdown? 13:11:08 will a simple `href` to `/resources/research-lab/audits/...` work as expected? 13:11:26 Or is there some magic incantation required because of the underlying engine 13:11:51 downloads.getmonero.org could be required. Let me double check, i'm not sure. 13:11:52 Of course we can move things around later if needed, but that sounds more annoying 13:11:56 ok 13:12:38 Putting them in the blag assets directory would work nicely, but that doesn't seem like the best place 13:13:26 yeah use simply `/resources/research-lab/audits/...` 13:13:32 neat ok 13:13:49 Almost finished with the PR, but I can't push it until the release date 13:13:59 (since the report can't be made public until then) 13:14:06 Does Friday (tomorrow) work for that? 13:14:38 No problem for me 13:14:45 Great 13:14:48 I'll coordinate that with OSTIF 13:15:25 Sure, jsut ping me if i'm needed 13:15:45 about downloads.getmonero i got confused, that's the separed box we use for downloads 13:15:49 Many thanks 13:16:22 (downloads of the binaries only) 13:16:22 np 13:16:27 I do remember there maybe being something about those existing PDFs being hosted on downloads, but perhaps I'm misremembering 13:17:20 yeah there used to be some more stuff there IIRC, that's what confused me 13:17:35 Ah ok, but that got moved? 13:17:45 No reason to be hosting small stuff like PDFs off downloads 13:18:57 The PDFs of the MRL are and were hosted in the research-lab/pubs folder AFAIK 13:20:20 Yeah, but for some reason I recall someone like fluffy or binary mentioning something about there being some odd way they were hosted 13:20:22 oh yes we have two PDFs in downloads 13:20:28 ok 13:20:34 Doesn't seem to be of consequence here, at least 13:20:52 the "annotated whitepaper" and "Brandon Goodell's Whitepaper Review" 13:21:04 got it 13:23:34 I think fluffypony made a list of what's in the 'downloads' box some time ago, would be good to have that list handy. i'll check 13:24:26 Would it make sense to move those PDFs? 13:24:34 Just for consistency, and to make any changes easier in the future 13:24:49 (not for this PR, of course, but a separate one) 13:25:10 I think so. I would be ok with that. 13:25:47 Does this mean the PDFs aren't even in the `monero-site` source tree? 13:25:55 (If not, that's a perfect reason to add them!) 13:25:59 correct 13:27:23 If nobody has nothing against it, i will add them both to /resources/research-lab 13:28:24 actually what might be good is to turn the downloads site into a Git repo 13:28:32 I'll work on that today 13:29:00 Still seems optimal to have research-related PDFs in a single location 13:29:02 IMO 13:29:36 In particular, it means they're in a repo that is managed by non-core people 13:29:38 good indeed. 13:29:40 (even though core does the builds) 13:30:26 Still seems optimal to have research-related PDFs in a single location <- yes i would move it either way 13:42:31 re: PDFs, we don't have any PDFs on downloads.getmonero.org except the CN whitepaper and the annotated CN whitepaper 13:42:40 and that's more for historical reasons 13:42:46 oh I see ErCiccione mentioned that already 13:43:10 Yeah, that's what we were referrring to 13:43:18 Moving those to the same place as the other MRL stuff seems reasonable 13:43:39 Of course, the newer preprints are just links to IACR anyway 13:43:44 yeah we can just have a redirect 13:44:00 I'm making the PR right now (writing the commit description as we speak) let me know if we shouldn't do it for some reason 13:44:07 but we had also discussed making the source to those IACR preprints available on a repo too (they're on my github right now) 13:44:11 do it = move the PDFs to the monero-site repo 13:44:53 (and noting that those IACR links are external) 13:45:26 sarang: i think we can move forward with that once those sources are uploaded somewhere 13:45:51 we were talking about a dedicated repo in monero-project IIRC 13:45:59 Yeah, it's on my list but I just haven't done it yet 13:46:02 that's on me 13:46:22 I still like the idea of keeping the IACR PDFs as external links 13:46:30 Alright, no worries. It's not prioritary 13:46:31 as long as they're marked and the source is available (which it is) 13:46:57 yeah specifying when links are external is in my TODO 13:46:59 "IACR could be compromised" is a good counterargument, but seems unlikely 13:47:19 and I don't think there exists a site that is viewed regularly by more security experts =p 13:47:33 https://github.com/monero-project/monero-downloads 13:47:35 created the repo 13:48:28 that was fast 13:48:37 Oh, it's empty 13:48:38 nvm 13:48:41 not that fast =p 13:50:04 lol 13:52:49 https://github.com/monero-project/monero-site/pull/1109 13:53:36 fluffypony: what is supposed to be in monero-downloads repo? 13:53:47 the downloads 13:53:52 once I've finished scp'ing them from the server 13:53:53 :O 13:53:58 but not CLI / GUI bins I guess? 13:54:03 else the repo will be huge 13:54:03 yes all of the bins 13:54:06 that's fine 13:54:13 it's not like everyone needs to grab the repo 13:54:16 What's the advantage of having them in this repo? 13:54:31 As opposed to packaged on the `monero` repo? 13:54:36 Maybe I'm missing the point 13:54:43 sarang: we don't want the monero repo to be like 500mb 13:54:55 if github allows that I guess 13:54:58 git lfs 13:54:59 and it allows us to deploy changes a lot more easily 13:55:03 ah ok 13:55:17 isn’t the bin archive over 10gb? 13:55:42 > Repositories have a hard size limit of 100GB. 13:55:43 ok should work 13:58:15 selsta: I'm excluding blockchain.raw 13:58:16 since that's created by the daemon 13:58:28 also I just noticed that it's not been auto-updated since we moved to the new environment, cc pigeons 13:58:37 .merge+ #993 13:58:37 Added 13:59:33 fluffypony: so the point is that the actual server will have its content deployed right from the repo? 13:59:38 Instead of via some other manual method? 14:00:33 it's still manual deployment from that repo 14:00:35 in case the repo is compromised 14:00:36 but yes 14:00:38 -xmr-pr- erciccione opened pull request #1109: Add whitepaper_annotated.pdf and whitepaper_review.pdf 14:00:38 -xmr-pr- > https://github.com/monero-project/monero-site/pull/1109 14:00:57 Right, not _totally_ automated! 14:01:09 But from the repo at least 14:11:56 Posted my usual update on reddit: https://www.reddit.com/r/Monero/comments/i0mpk2/getmoneroorg_updated_massive_performance/ 14:11:58 A lot of nice stuff 14:13:34 aaand automod blocked it 14:31:07 hah I take back my totally optimistic size estimate - it's more like 19gb excluding blockchain.raw 14:31:23 still, that comes in well under GitHub and Backhub's limits 14:32:31 fluffypony: the problem is that everyone who wants to add some PDF to the repo has to download 19GB if I understand this correctly 14:32:35 not sure if ideal 14:32:51 selsta: you can ask someone else to add it, or add it through GitHub's web interface 14:33:18 oki 14:33:19 it also makes it easier to deploy a new Monero website if anything happens 14:34:47 selsta: PDFs shouldn't be uploaded there 14:35:07 we are moving the only two which were there to monero-site 14:40:17 should we even bother redirecting or just leave them in that repo for historical backlinks to it? 14:40:22 any old backlinks aren't going to change now 14:40:57 I would just leave them there 14:43:24 kk 14:52:33 I just submitted the updated sitemap to google. I think they would re-crawl it anyway, but a little ping won't hurt 14:53:02 also one nice thing about this repo is that I just noticed nobody did the source tarball 14:53:10 for the 0.16.* releases 14:54:17 We also don't give a link to download it from the website AFAIK. 14:54:30 yes but it's used by the auto-updater 14:54:34 if you build from source 14:59:07 fluffypony: hi sir do you happen to have a box for `xmr-pr` 14:59:19 our beloved bot needs a stable dedicated home 15:00:15 sure - pigeons should have a spot on one of the Monero servers 15:00:21 he just lacks time atm 15:00:25 I'll chat to him when he's around 15:00:33 oh ok cool no hurries 15:01:27 fluffypony: the problem is 15:01:37 gui does not allow building without git repo 15:01:44 soo the sourceball is useless 15:01:51 until we fix this we didn’t create one 15:02:00 ok but for CLI? 15:02:07 yea CLI should work 15:04:04 I can do one for CLI in the future 16:59:53 Small PR to fix a link on an old post: https://github.com/monero-project/monero-site/pull/1110 17:00:11 Looks like the preview build doesn't show it since it's an older post, so I cannot test it 17:18:51 Seems straightforward. 17:19:13 .merge+ #1110 17:19:13 Added 17:22:32 sweet 17:24:48 What I see on the blog page: https://usercontent.irccloud-cdn.com/file/PX0dP5uw/blog-links.png 17:24:56 Anyone else get this weird link spacing? 17:25:18 on https://web.getmonero.org/blog/ 17:26:00 try to clean cache 17:26:13 https://www.getmonero.org/blog/ 17:26:22 looks good here 17:26:30 * sarang withdraws his comment :D 17:27:16 Can the HTTP responses for these pages specify cache expirations? 17:58:55 yes 17:59:13 but it's in our best interest for them to be long-lived (in general) 19:33:33 Isn't there a middle way? i think most of the people don't even know how to flush their cache and they end up weirded out by some broken css or something else 19:34:29 having a shorter expiration time for the css would make sense 19:34:37 other resources like images can stay the same