05:41:14 Dev meeting in 11 hours. 13:37:20 are tests on master working for other people? I'm seeing failures in functional and unit tests 13:47:42 Since no actual details seem to be forthcoming... unit tests are known to fail in DNS tests in some setups. 14:06:44 woodser: they seem to be working 16:01:05 Snipa, binaryfate, moneromooo, selsta, xiphon meeting in an hour 16:31:20 test failures with dnssec were pretty common for me 16:31:35 seemed to depend a lot on specific version of libunbound you built 16:31:56 but also depended on libunbound correctly detecting cipher support in OpenSSL 16:55:40 sarang: also 16:55:43 meeting in five 16:56:07 roger 16:56:08 o/ 17:00:14 Good morning/evening everyone. It's time for a dev meeting. 17:00:35 hi 17:00:39 We've moved these to be really on an as-needed basis, and it was requested by binaryFate to have one. So let's get started. 17:00:42 1. Greetings 17:00:48 hello! 17:00:52 Hi 17:00:53 https://github.com/monero-project/meta/issues/449 17:00:57 The meeting issue ^ 17:00:57 Hello 17:01:19 Hi 17:01:44 hi 17:01:45 Here as well 17:01:58 2. Brief review of what's been completed since the previous meeting 17:02:15 hey you sexy community you 17:02:20 Let's keep this section just to information updates. Discussion on research or dev points will come next. 17:02:20 should I start? 17:02:24 go for it vtnerd 17:02:31 Hi everyone - my first dev meeting attendance :-) 17:02:48 oh whats the difference between information updates and dev points? 17:03:13 Meta? 17:03:23 oh whatever, I'll start and someone can stop me if necessary 17:03:31 vtnerd: meaning this is just saying what you did. We can discuss if people have issues or questions a bit later. 17:04:20 I posted a github issue explaining my attempts to improve the zmq-serialization in particular for perf and multiple formats. it could also be applied to epee, which would accelerate p2p traffic (syncing, etc) 17:04:40 it may have been too much macro and c++ for some, but that will have to be left to others 17:05:04 I've also been hoarding code that gets rapidjson to write directly into a `byte_slice` to remove the last remaining copying on zmq-json output 17:05:23 I've been hoarding it waiting for reviews to settle, but I'll probably just post it shortly even though it blocks with some thing else 17:05:27 * hyc always a fan of zero-copy 17:05:57 this can also be used to replace std::stringstream in epee binary output and with some more work the json output there too (definitely faster, don't have numbers off-hand) 17:06:23 lastly, zmq-pub is finished and only needs unit tests. txpool and block events are supported 17:06:38 https://www.github.com/vtnerd/monero/tree/feature/zmq-pub 17:07:04 https://github.com/vtnerd/monero/tree/feature/zmq_pub 17:07:40 underscore not hyphen, sorry. dont have much else that i can think of. might be some more minor perf stuff to serialization 17:07:47 fin 17:09:10 man github is weird, https://github.com/monero-project/monero/compare/master...vtnerd:feature/zmq_pub?expand=1 might be more helpful for zmq interested people 17:09:58 nice. Thanks vtnerd. Does anyone else have an update? 17:11:25 Ok, let's move on to 3. Research items for discussion 17:11:41 sarang: is there anything you'd like to see is/was/has been in the pipeline and want feedback on? 17:11:48 More progress on CLSAG, which I see has its own agenda item 17:12:05 yeah, 5 and 6 will probably be merged. 17:12:06 Triptych and Triptych-2 have their preprints out 17:12:17 Multisig and join-type math is being worked on for those 17:12:44 There has been talk of Janus mitigations that would add a little bit to transaction sizes; I support this idea, but it didn't seem to gain much traction when brought up a while back 17:13:34 One proposal for Janus would also provide better uniformity based on subaddress destinations 17:14:09 i.e. each output has its own tx pubkey, and then there is a "global" per-transaction pubkey for Janus testing 17:16:09 How much larger would txs be? 17:16:52 Most transactions would see 32-64 byte increase 17:17:14 Keep in mind that CLSAG would already decrease typical transaction size by something like 600 bytes 17:17:26 and the benefit is better uniformity, ye? 17:17:32 and detection of Janus attempts 17:17:54 Note this does not imply extra verification time for the whole network (aside from parsing out these values) 17:18:02 I think the subaddress uniformity benefits are underrated personally 17:18:03 Only recipients perform the Janus computations 17:18:22 Would that mean subaccounts are as secure as separate wallets? 17:18:23 and the Janus computation is pretty trivial 17:18:33 From a Janus perspective, yes 17:18:44 Recipients could detect attempts to Janus-link addresses 17:19:01 at which point they would...? 17:19:27 Wallets could either choose to accept/spend the funds, or treat the transaction as "not destined for me" 17:19:33 (the latter is safer) 17:19:36 "There has been talk of Janus mitigations" <-- best place to find these discussions? 17:20:02 Has been brought up during many -lab meetings and other discussions, as well as research-lab repo issues 17:20:17 Can discuss at this week's research meeting too, if desired 17:20:32 Maybe a small write up of this would be warranted? Pros, cons, background info, etc. 17:20:45 Would be very interesting. Not saying you to do it sarang. Get someone else to learn and writ eit. 17:20:51 *write it 17:20:57 See: https://github.com/monero-project/research-lab/issues/71 and https://github.com/monero-project/research-lab/issues/62 17:21:11 Ok, anything else on this topic? If not we'll move forward. 17:21:20 What would be helpful for me is to know whether or not people support such a size increase for this benefit 17:21:33 If not, we can drop it and provide better user education on subaddress limitations 17:21:40 If so, we can hopefully move forward and deploy the mitigation 17:21:46 Never offload to users what can be done by the software. 17:21:54 When first brought up, there was a lack of general dev support 17:22:04 I would probably take that for 64 bytes anytime ... 17:22:16 I say yes deploy, just because of UX 101. 17:22:19 I think it's a good idea for subaddress protection and for uniformity 17:22:28 Note that it doesn't have to be consensus, but could be 17:22:34 The wallet would probably provide a big warning to users, but funds shouldn't be unspendable. If someone actually pulls off a Janus attack even with mitigation in place, that would be very interesting 17:22:49 I also think it's needed to make subaddresses function as people believe they do 17:22:56 UkoeHB_: an attacker could easily post such a txn 17:23:00 More likely is other wallets failing to implement it correctly 17:23:01 it's up to the wallet to decide how to handle it 17:23:56 At the risk of stating a potentially unpopular thought, I think making it consensus would be necessary, since subaddresses are a part of our ecosystem and are here to stay. 17:24:06 So to recap, under the assumption of CLSAG, txs still become much smaller than they are presently 17:24:10 This makes it fairly idiot proof, no? 17:24:12 and still become faster to verify 17:24:20 Consensus is questionable since it's not verifiable 17:24:35 UkoeHB_: I mean consensus in terms of the presence of the expected number of tx pubkeys 17:24:36 All you can require is a few extra bytes exist in the tx 17:24:39 yes 17:25:41 Anyway, please carefully consider this idea 17:25:51 Well, unless there is other thoughts on this, we can discuss at the next MRL meeting. 17:25:54 Let's move on. 17:25:56 I think it would be ok to require that, since ECDH info is already a precedent 17:26:19 I'm going to merge items 4, 5, and 6 17:26:45 Dev items for discussion, D++ & CLSAG, and v0.15.1.0 discussion respectively 17:27:06 Let's actually start on the tail end of that. v0.15.1.0. When? How? Why? 17:27:34 vtnerd: is that supercop stuff ready to merge after review? 17:27:55 yes 17:28:21 it can be used within monero or another project, or be built and installed as a standalone lib 17:28:42 Is the wallet integration also PRed already? 17:29:03 or is that not required 17:29:15 yes, but its marked with do not merge because it requires the supercop merging first, and then a pin to the hash of the supercop 17:29:52 ok, I would like to get Dandelion and supercop in for v0.15.1.0 17:30:00 do you think that’s realistic? 17:30:04 you know, that was probably never mentioned in a -dev meeting either so yeah more stuff to mention 17:30:29 um, the supercop might be tough for reviewers, that will be the biggest holdup 17:30:38 can we get either context or a link for "that supercop stuff"? 17:30:41 https://github.com/monero-project/monero/pull/6337 17:31:00 https://www.github.com/monero-project/supercop 17:31:18 see the single PR 17:31:20 with very little additional efforts the meeting would be easier to follow for bypasser/newcomer 17:31:23 thanks 17:31:53 I’m on mobile so I can’t post links :) 17:32:06 it accelerates wallet scanning on x86-64 boxes, using code from Daniel Bernstein, et al's supercop repo 17:32:42 Waiting for quite some time, right? 17:32:47 the ed25519 code could not be used directly, modifications to work with monero specific stuff was required, thus the tough review (its hacking a C crypto implementation) 17:33:17 yes, although expected giving the situation 17:33:23 who has the skills to review ASM? 17:33:46 or do we have to review the ASM? 17:33:56 Has anyone outside monero dev expressed interest or been recruited to look at it? 17:34:18 the ASM is very similar to the existing supercop code. you can diff it between the existing "base" code and my new additions 17:34:33 ok, that’s probably reviewable 17:34:35 but you would still need to know a bit of ASM to understand what its doing and why 17:35:11 yes, if you trust the supercop amd64 ASM, then its easier than reviewing completely from scratch. 17:35:26 moo and I have a discussion about this in the PR for the files that need to be compared 17:35:33 No (friendly) fork with enough traffic to have interest in this as well? 17:35:45 To help to review, I mean 17:36:40 I think mooo was interested in reviewing it but I don’t want to speak for him. 17:36:41 Isn't the point of C/C++ to avoid ASM? 17:36:56 we want ASM crypto to speed wallet scan up 17:36:56 why not write everything in ASM? 17:36:56 crypto libs man 17:37:25 because its tough to get the perf + constant time code 17:37:39 I think it's a well-defined and reasonable use case for ASM 17:37:47 i don't buy it 17:37:49 did you reach out to Bernstein and co-authors for a review? 17:37:57 that ASM I wrote keeps the code constant time, whereas some other forks _definitely_ dropped that feature when taking the supercop code 17:38:12 it's never a bottle net to begin with 17:38:15 neck 17:38:31 fuwa, writing constant-time code in C is harder than you think, please read 17:39:02 I saw the RP, I can't read it :p 17:39:06 So it would not only be a little faster, but also better concerning timing attacks? 17:39:24 if you drop the constant time behavior, crypto code will be much, much faster 17:39:44 it's not slow, even on my phone 17:39:47 sarang could probably comment on this with regards to the variable ECDH thats lurking in some sports 17:39:54 yes, it is 17:40:13 look at the perf numbers 17:40:27 There are plenty of spots where we use vartime scalarmult operations in particular 17:40:31 this is an optional wallet feature that I can change to disabled by default 17:40:51 - but wallet viewkey scanning ? 17:40:56 mostly on the verify side, no? 17:41:23 mostly, yes 17:41:31 on the topic of supercop, have you used ctgrind to evaluate this yet? https://github.com/agl/ctgrind 17:42:02 no idea this existed, but awesome 17:42:13 I'd forgot about that PR since it's elsewhere. I'll try to go through it soon. 17:43:02 So are we looking at maybe a couple of months if we want to get both of selsta's requests in this next release? 17:43:39 I wanted to get v0.15.1.0 out in 1 month or so. 17:44:03 Maybe it would be better to only include Dandelion and then supercop + CLSAG in the next HF 17:44:20 Let's discuss CLSAG real quick 17:44:34 sarang: can you comment on how close it is to production ready on both a code and audit level? 17:44:35 as for perf numbers, scanning the whole blockchain went from ~46 mins to ~20 mins on a 2014 mac mini. An older piece of hardware, but not _that_ old 17:44:47 did anyone reach out to Bernstein and/or co-authors for a review? 17:45:18 * sarang will wait for this topic to conclude 17:45:26 You mean hiring Bernstein for a review? 17:46:00 I mean just asking for a friendly quick check from one of the authors or maybe a student of theirs but anything is possible. 17:46:35 D. Bernstein was speaking at the Monero assembly at the CCC a year ago, on a panel on privacy and stuff. Who knows maybe there is enough interest. 17:47:06 Nice. Maybe someone who can write well can reach out. 17:47:26 Just letting them know we have this thing going on and are looking for reviews, see where it goes 17:47:45 vtnerd: did you see moneromooos faster fetching of txs PR? 17:48:30 That's daemon only, while vtnerd's wallet side. They won't interfere. 17:48:56 But should result in even greater speedups? 17:48:59 together? 17:49:11 Yes, if you run both on the same machine. 17:49:21 ok :) 17:49:45 Well, less load. But it's likely one of them will be the bottleneck, so the other will wait. 17:50:18 The wallet's probably the bottleneck there. 17:51:15 So the daemon will be done faster with the request, but will sleep for longer till next request. 17:52:25 rehrar: maybe you can add writing Bernstein on a todo so that we don’t forget it 17:52:32 Already done. 17:53:22 Ok. Ready to discuss CLSAG? 17:53:27 Sure 17:53:44 I had been waiting for some time on changes/approval from coauthor suraeNoether 17:54:04 However, he just recently gave me permission to make the changes and post the revision without his further input 17:54:17 So, I'm completing that, which should be done within a couple of days 17:54:35 Optimized CLSAG code has been merged into moneromooo's now-rebased `clsag` branch 17:54:56 My local copy of that branch has some new plumbing to help with trezor/ledger support 17:55:24 I'm now working to coordinate that, so trezor/ledger will be (ideally) ready to go right away at upgrade time 17:56:06 The 600 bytes reduction is already visible on that branch or assuming further changes? 17:56:27 The 600-byte (for a 2-2 txn) has not been changed throughout CLSAG's development 17:56:45 So yes, a transaction generated from that branch will see the expected size reduction compared to MLSAG 17:56:55 and will see verification speedups 17:56:59 some of which are relatively new 17:57:11 this is awesome :) 17:57:30 Because of some speedups to MLSAG that are already in place, the current speedup going MLSAG->CLSAG is around 16% IIRC 17:58:11 I can't comment on how trezor/ledger development will take, but the preprint will be on IACR within days 17:58:34 and my device-specific plumbing changes are minimal and could be merged to the `clsag` branch whenever convenient 17:59:05 and it's best not to put CLSAG in the release until Ledger/Trezor is properly integrated, yes? Because then that puts us with very angry users. 17:59:13 yes 17:59:15 I agree 17:59:28 However, I'm actively in contact with those folks 18:00:06 They are using that `clsag` branch for their work 18:00:14 So if selsta wants to try to get 0.15.1.0 out next month (And so far nobody else has given a timeline) then maybe it's too soon for CLSAG indeed? When would we do a hard fork release after that? Two months from now? Three? When ready? 18:00:27 Is there a need to rush it? 18:00:33 The upgrade, I mean 18:00:33 CLSAG would not be included in v0.15.1.0 18:00:58 CLSAG would be v0.16.0.0 due to hardfork. 18:01:02 ah, I see. 18:01:05 my bad. Sorry. 18:01:21 Review on moneromooo's `clsag` branch would be welcome 18:01:58 and/or the additional pending commit on my `clsag-device` fork of that branch (which adds device-specific plumbing) 18:02:15 Would May or June be when we can start looking at v0.16? Just as an idea of a date, not committing to anything obv. 18:02:34 I think we can think about a date once we know how long the audit is going to take. 18:02:38 If Teserakt are chosen for the review, they had previously indicated a very short turnaround time 18:02:44 that's up the audit workgroup 18:03:07 can people who have participated in the audit workgroup be named so we can get this on their agenda? 18:03:09 Reviewers would need the preprint (just a few days away) and the finished code 18:03:24 AFAIK sgp_ has been coordinating that effort 18:03:32 ok, thanks. 18:03:39 anything else on this topic? 18:03:48 I'm offering my support as a researcher, but will not be making any decisions on that 18:03:58 (I think it's good practice to have that handled separately) 18:03:58 Maybe at some point we need to give a timeline or soft deadline to ledger/trezor? With some good margin on top anyway before the freezing for hard fork. To have some visibility and not depend on external things a bit opaque. 18:04:14 binaryFate: I only reached out to them a few days ago, so they are reviewing the changes they expect 18:04:28 They've indicated the changes should be straightforward and relatively minimal, FWIW 18:04:31 sounds good 18:04:50 I'll follow up if/when I hear more details 18:05:17 I think code reviews are extra appreciated in the next days / weeks so that we can get a lot in for v0.15.1.0. We will fork from master branch. We will also need a bit of time for testing before release. 18:05:42 Were there any outstanding CI issues with current master? 18:05:47 no 18:05:50 ok 18:06:02 compilation was failing yesterday but it is fixed now 18:06:25 Forking after going through some PR / merging backlog? 18:06:49 yes 18:07:07 Nice 18:07:10 Ok. We're running a bit long, so I'm going to move to the last item. 18:07:17 These days i'm thinking of the possibility of organizing a hackaton for 0.15.1 and let people fix bugs. Maybe we could open a CCS for a prize 18:07:26 binaryFate: you wanted "seeds" added to the agenda. Can you open us up on this? 18:08:17 It's simple: the situation with the seed nodes is sub-optimal. We're right now at 3 up, because we raised the issue last days, we only had 1 up before for quite some time. 18:08:46 mooo PRed a node. 18:08:47 What, on mainnet? 18:08:52 Same situation happened 2 months ago, we raised the issue and got 2 nodes back up (thanks to fluffypony), but we eventually went back to 1 node again 18:09:26 Yes mainnet. So we are 1 single node from newcommer downloading Monero and being unable to sync without going on forums to find extra commands and stuff 18:09:34 So, was ok but close call 18:09:40 You can see seed nodes here: https://community.xmr.to/xmr-seed-nodes 18:09:41 I knew that there were no seeds at all running for testnet, but mainnet .. 18:09:59 Actually testnet and stagenet had 3 nodes up when mainnet had only one... 18:10:23 Cool 18:10:24 I’m interested in traffic requirements for a seed node. 18:10:32 Out of the 3 nodes up, I believe one is ran by Snipa and 2 by fluffypony. The other afaik we don't know 18:11:55 Also there are domains in the code, to be used to get seed nodes, but none of them have any dns records 18:12:28 So there has been some kind of ... bit rot :) 18:13:05 Yeah been slowly driffting downward. So how do we improve at next release? 18:13:53 I'd suggest in general to get 3-5 domains up, and maybe a dozen seeds up from trusted volunteers. 18:14:14 Remove any existing seed where we don't even know who is supposedly taking care of the node 18:14:23 I would be quite interested in running a seed node, for example... 18:15:00 Also, someone in #3425 was interested in running a seed node. That was a while back though. 18:15:52 I can vouch for yugyug that I know IRL (we work together). 18:16:25 We'd need to find these volunteers. Do we just put out a PSA and choose the most trusted responders? 18:16:50 In might be useful to have a ball park for traffic requirements of a seed node. 18:17:31 fluffypony: do you know ? Combo of print_net_stats and status. 18:17:32 Well, you can restrict at any time, probably most important to get to know peers for other nodes, no? 18:17:45 yes, if a $10 VPS (~2TB traffic) can run one it will be easy to find volunteers 18:18:54 selsta: for that price will it have enough storage? 18:19:04 pruned node, yes 18:19:16 indeed all the network wants from a seed is that you can serve a quality up-to-date peer list, not necessarily syncing much from it directly 18:19:18 Exactly - assuming the main role of a seed-node is intodroducing new peers it should be enough 18:19:56 if $6 you can get 100GB SSD storage and 20TB traffic. 18:20:02 for* 18:20:08 at hetzner* 18:20:14 In that case then yes, shouldn't be much an issue 18:20:36 and i confirmed they dont care about running i2p nodes or xmr nodes. 18:20:53 kinghat[m]: Hetzner is nice but probably the most provider, we should diversify a bit 18:20:58 most used* 18:21:21 do they accept btc or Monero? 18:21:51 Would surprise me 18:22:00 i dont think so 18:22:09 eh 18:22:25 ok. binaryFate anything else you wanted to say or ask regarding this? 18:22:47 everyone who wants to run a node should open a PR adding their node, mooo did this recently 18:22:49 next steps about seeds? Visible PSA or just mentions here and maybe -community? 18:22:52 run a seed node* 18:23:23 * kinghat[m] uploaded an image: image.png (14KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/hfuCSSdvVEpwRWIFBJqEfzsf > 18:23:31 ok. selsta shall we wait to merge them? In case there are 50, we will want to select 18:23:39 selsta: this may be the way to handle it. Which ones get merged can be discussed on the PR in regards to tr;ust. 18:23:43 yep 18:24:06 maybe mark them as WIP for now 18:24:11 discussion can take place in the PR if the user is new 18:24:41 rehrar: I would like to add a quick meeting item: moving back to Github for all repos 18:24:59 ok, discuss 18:25:09 selsta: you have the floor 18:25:09 anyone against this? 18:25:41 I think we have tried gitlab for a while now and there are some restrictions / limitations. 18:25:47 What about the CCS stuff? 18:25:51 What is that, in addition to the website? 18:25:59 Doesn't that require some GitLab-specific stuff for the backend? 18:26:13 It would be best to leave it online as a repo backup but move back to Github. 18:26:21 sarang: afaik xiphon coded github code for it 18:26:54 simply pulling the css backend from github should be enough no? 18:27:01 Community discussion happens as GitLab MR comments 18:27:08 Which presumably would be lost 18:27:20 sarang: Xiphon and I did some work for Zcoin to launch their CCS. They use Github, and Xiphon made the stuff for it to happen. 18:27:29 So, in theory, switching over shouldn't be too big of an issue. 18:27:32 rehrar: is there an advantage to moving CCS to github? 18:27:34 is it possible to seamlessly switch over to gitlab operating as a mirror if github gets ugly? 18:27:48 I assume that CI stuff is not important for CCS repos 18:27:59 it would IMO be best to have everything in one place 18:28:03 are the current limitations listed/discussed somewhere? 18:28:04 sure, but it must be annoying to run a whole gitlab instance for just CCS things. 18:28:08 the existing discussions would stay online 18:28:12 There was a github issue comment 18:28:19 https://github.com/monero-project/meta/issues/236 18:28:24 rehrar: wouldn't there still be a gitlab instance for mirrors? 18:28:26 (last 2 comments) 18:28:44 yes, gitlab instance would stay online as a mirror 18:28:54 binaryfate: i tried to make a summary: https://github.com/monero-project/meta/issues/236#issuecomment-605023567 18:28:55 IIRC mirroring only works the other way. 18:29:24 It shouldn’t be too difficult to write a script to mirrors the repos. 18:29:25 (unless manual scripts to pull I guess) 18:29:52 It would be nice to have things like easier 2FA and SSH access for everything 18:29:58 (that's a huge gitlab limitation IMO) 18:30:14 and working CI for PRs 18:30:19 ssh is not gitlab's fault, it's cloudflare's fault. 18:30:58 the only thing we should look into is a regular backup of all Github discussions 18:31:02 Well, but same end result for users ... 18:31:42 I don’t know if Github has an option for this or if we have to use a scraper. 18:32:04 regular backup of all Github discussions <- yes, we should look into ways to preserve history in case things gets bad 18:32:06 To mirror manually ? A set of git pull. 18:32:18 isses / pr discussions 18:32:20 issue* 18:32:21 moneromooo: true regarding SSH, but we still don't have it :/ 18:32:24 Oh, sorry. 18:32:55 GitHub-only would also remove some of the common account issues people seem to have 18:33:02 regarding forks, and github credential use, etc. 18:33:22 we can check https://github.com/marketplace/backhub 18:33:49 binaryFate: maybe they offer a free service for open source software 18:33:50 they use github API and seem to be able to get metadata 18:34:04 else I guess $12 or so sounds okay. 18:34:08 There has to be since gitlab could pull all the history. 18:35:18 what about microsoft thing? Was primary driver to move... 18:35:38 The issue comments discuss the problems with gitlab 18:35:45 regarding accounts, CI, etc. 18:35:52 We still don't have anybody speaking out against the "next spawn of satan" :) 18:35:58 (see issue title) 18:36:04 FWIW it seems that MS has done a good job of not interfering to the extent possible 18:36:07 I personally don’t think that Github has gotten worse since the MS acquisition. 18:36:11 ^ 18:36:23 They always do until they fuck you over. 18:36:47 sarang: it's still a time bomb. The point is to have a self hosted platform, but gitlab that supposed to be the best, turned out to be not that great 18:36:59 fair 18:37:14 If there is an issue it the future we can migrate back. 18:37:27 But FWIW, seems that having self-hosted will always result in fewer developers being on that platform compared to something like GitHub 18:37:40 That's not really a GitLab issue, but a "where are people" issue 18:38:03 Anyway, nobody is at the moment seriously voting from moving *away* from GitHub for the main repos, right? 18:38:03 sarang: i thin the problem is that all main repo are on github excpet for one, the website 18:38:04 For better or worse, people are on GitHub, which has good CI 18:38:09 And using monero rather than bitcoin, or Linux rather than Windows. We still do :) 18:38:22 Well, I guess some here use windows and Bitcoin. But still. 18:39:25 i see the problem of the missing people on gitlab more like a problem caused by the split than something related to the platform itself 18:39:49 I mean people still have to signup for the wesite repo compared to Github so there will always be less people IMO 18:40:21 Is anyone here against migrating back to Github for all repos? 18:40:51 And keeping the existing instance for its discussions etc.? 18:40:55 I'm indifferent. 18:40:56 (useful esp. for CCS) 18:41:00 I kinda agree that the CCS is probably best left on gitlab in theory. Whether it's worth the expense though, I dunno. 18:41:00 IMO visibility and ability to attract contributors should be priority especially in these turbulent times (cons: many projects will probably die, pro: many people are stuck at home with some time), we can adapt to new things if there is a spawn of satan situation 18:41:25 has anyone ever contributed to monero by stumbling across it while surfing github? 18:41:35 I kinda like that people have to jump through an extra hoop for the CCS though. 18:41:52 I think I might have. Not sure. 18:41:53 It's a step 0 for people requesting money. Can't even do that, we don't want their proposals. 18:42:21 I don’t care about CCS repo. Mostly site repo. 18:42:50 i think would be better to move everything, but i see why could make sense to keep CSS stuff on gitlab 18:43:00 let's start with site then 18:43:07 CCS is not urgent to move, but can be down the road 18:43:37 sounds good 18:43:50 +1 18:44:10 ok. Anything else in this hour and forty five minute meeting? 18:45:02 o_0 18:45:24 cool deal. Let's break. 18:45:30 Did we discuss CLSAG audit(s) already or? 18:45:30 Thanks everyone! Bai! 18:45:36 The update TXT records. Would be nice to get them updated. 18:45:43 fluffypony ^ 18:45:47 I pinged pony, but he might see that in like a month. 18:46:03 After the pandemia, I suppose 18:46:16 Ah yeah. Packets should stay on the local network. 18:46:34 fwiw we're working on me having dns access as well, but the transfer isn't done yet. So next time can be faster turn around. 18:46:55 Actually... Given pony lives on planes, I wonder if he's stuck in a plane doing figures of 8 above somewhere for weeks... 18:47:17 Did we discuss CLSAG audit(s) already or? <= Found it in the logs, nvm 18:47:19 Like I said, get a monerojet, and I shall get type rated for it :) 18:47:34 Still? Even after scaling back Monero involvement? 18:47:42