08:15:41 <selsta> hyc: trezor seems to work, but will do some more testing
11:45:25 <w[m]> <moneromooo> "I'll /unignore now since "he..." <- I told that guy 3x over 3 days... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/aa0f9a7dbc315c16a59b5b86a7e0082fa6983013)
11:46:43 <w[m]> * I told that guy 3x over 3 days... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/d6fd94f3126b1d34542927c6111dea367e127599)
12:34:43 <hyc> selsta: great
15:17:55 <moneromooo> Is there anyone here who does not contribute to monero but would if there were parts in rust ?
15:18:58 <moneromooo> And I'm not sure how to say that non insultingly, so: and who's a competent coder (yes, it's subjective).
15:19:55 <tusqvarna> Are there many competent Rust coders?
15:20:26 <tusqvarna> Seems more like Rust is a solution looking for a problem.
15:21:43 <kayabaNerve> Yo
15:21:49 <hyc> rust has only been stable enough to use seriously for a couple years
15:22:01 <hyc> before that the language was pretty much rewritten with every update
15:22:02 <kayabaNerve> I saw the one previous issue, yet I didn't appreciate it.
15:22:15 <kayabaNerve> Is there a new reason this is coming up moneromooo, or just polling?
15:22:49 <kayabaNerve> Personally, I despise working with C++ and its tooling. I've spent the last month rewriting a significant portion of XMR wallet code in Rust.
15:23:01 <moneromooo> Someone somewhere asked whether we'd accept rust code in self contained bits. One of the conditions is that we have enough people willing to read/debug/maintain/review such parts.
15:23:20 <kayabaNerve> Though I will note I already had use cases the existing C++ code didn't handle, and I've heard horror stores about wallet2 specifically.
15:23:44 <kayabaNerve> I'd be more than willing to help with review and maintenance, though my personal long term preference would be a dual-impl, not a merge-impl.
15:24:06 <hyc> dual makes more sense, agreed
15:24:24 <kayabaNerve> ... unless it's a merge-impl where all the Rust code is a singular lib. I don't see value in piping out individual functions randomly, but I would enjoy seeing all of RingCT moved to Rust.
15:24:25 <moneromooo> What is dual-impl, and what is merge-impl ?
15:24:31 <hyc> but a lot further in the future
15:24:35 <kayabaNerve> We have monerod and monerod-rs
15:24:43 <kayabaNerve> monerod is C++ and monerod-rs is Rust
15:24:56 <kayabaNerve> merge-impl would be we have monerod, which requires both to compile as it has both.
15:25:08 <moneromooo> Ah, you mean make your own separte codebase ? It's not a term of art ?
15:25:17 <kayabaNerve> But again, the discussion should never be "Can I write random functions in Rust and give you a C FFI?" That's a mess
15:25:40 <kayabaNerve> The discussion should be what's currently in C++ that'd be better done in Rust, either for the libraries, the safety, or the people willing to work on it
15:26:15 <kayabaNerve> For example, the ZK membership proof I'm prototyping. We may legitimately want to use a Rust impl for it. In that case... we'd want this one portion done in Rust as an isolated component which solely defines `prove` and `verify`
15:26:34 <kayabaNerve> And yes, I did mean a separate codebase by dual impl
15:27:20 <kayabaNerve> Not only am I effectively doing a full wallet right now, I'm also interested in an impl of BP+ in Rust (so I can micro opt it, not to mention better understand the algorithm), but I would love to see a seraphis-rs
15:27:37 <kayabaNerve> Rust is great at highly composable packages and so on. Perfect fit IMO
15:28:05 <kayabaNerve> Though I know koe doesn't prefer Rust, and accordingly, Seraphis should be in C++. The only discussion would be about individual proofs, such as the membership proof, as *most* ZK code is in Rust.
15:28:23 <kayabaNerve> Though I do eventually want to propose a BP solution we can do in C++ as well without too much hell :)
15:28:49 <tusqvarna> Its an incredibly risky proposition to go refactoring the codebase just to fit Rust in.
15:29:04 <kayabaNerve> To clarify, was this the issue from a few weeks ago, a new one, or a non-issue yet just a question?
15:29:19 <hyc> new asker, same question
15:29:35 <kayabaNerve> Do they have an issue?
15:29:39 <hyc> from -research-lounge
15:29:42 <kayabaNerve> Got it
15:30:05 <moneromooo> I did not realize it had been asked earlier, sorry. I thought "would we have maintainers" was an easy filter to check :)
15:30:24 <kayabaNerve> Oh. It was specifically within the context of the membership proof
15:30:26 <hyc> I raised the "do we have maintainers" point last time around
15:30:40 <moneromooo> Did you find any ?
15:30:42 <kayabaNerve> I think that'd be a prime target to do in Rust, though I don't plan on submitting one infeasible for us to do in C++
15:31:13 <kayabaNerve> I and anyone who worked on COMIT/Farcaster...
15:31:39 <hyc> moneromooo: nobody jumped up and down last time
15:32:06 <kayabaNerve> Also, hyc, it should cross compile to every platform in question (I'd have to double check, and I can see why that'd be a requirement of course, but it does have a ton of targets)
15:32:18 <kayabaNerve> And C FFI can be done in just a few lines.
15:33:10 <kayabaNerve> `pub(crate) fn c_generate_bp(len: u8, amounts: *const u64, masks: *const [u8; 32]) -> *const u8;` Here's a C function. From the Rust side, I have 2 lines to format the inputs as needed.
15:33:39 <kayabaNerve> And then I was lazy and instead of doing the proper struct for the output (which is possible), I just serialized/deserialized it each way. I'm still relying on monero-rs types in my work...
15:34:28 <kayabaNerve> As for jumping up and down, I didn't know this was asked last time :p Rucknium[m] was helpful enough to ping me this time and I am happy to jump to present clean programming with modern package management and building which offers memory safety and great cryptography :D
15:41:40 <BusyBoredom[m]> Bringing this over here from *-lounge: https://github.com/monero-rs/monero-rs
15:41:40 <BusyBoredom[m]> ^ I think looking at the contributors to that project gives a good idea of who in the community can make meaningful rust contributions. Not many, but maybe enough? 
15:46:49 <jeffro256[m]> .merges
15:46:49 -xmr-pr- 8046 8220 8226 8235 8262 8277 8278 8279
15:54:52 <UkoeHB> Ideally there would be multiple independent implementations of everything, with the C++ code as canonical verifier. What dangerousfreedom is doing with python is a good example.
15:57:24 <wernervasquez[m]> UkoeHB: glad to hear that said. Years ago when I lurked there was a seemingly prevalent attitude that that was unneeded, unwanted, and a waste of time.
15:57:43 <wernervasquez[m]> But perhaps I only lurked when cranky people were talking
15:58:45 <moneromooo> It depends, obviously.
15:59:16 <moneromooo> It's a waste of time if it's people working on monerod leaving to start another impl, which in all likelihood will be abandoned.
15:59:26 <moneromooo> If it's new people who want to do that, it's not.
16:00:40 <moneromooo> It's wanted if it acts as a bug finder/comparator, it's unwanted if it ends up used by half the people as main daemon, leading to possible forks on economically important nodes.
16:01:00 <moneromooo> If you have little manpower, you don't want to waste it in duplicate work.
16:02:42 <moneromooo> Several people popped up over the years saying they'd like to code a rust wallet and/or daemon. AFAIK none ever did. Maybe some starting code was done, and then it got abandoned.
16:03:15 <moneromooo> Though there's this github link above, maybe that's one of these people. Who knows.
16:04:06 <moneromooo> I mean there are pros and cons. And I'm cranky.
16:05:17 <moneromooo> monerod also used to be a more moving target than it is now.
16:20:09 <BusyBoredom[m]> The github link above is a library of utilities for working with monero in rust. It handles things like checking ownership of outputs. It's pretty complete and used in a number of projects (including my own payment gateway library, acceptxmr). kayabaNerve mentioned above that he's using it too. 
16:20:09 <BusyBoredom[m]> So while I agree that many "let's rewrite this in X!" projects are wasteful, the work going into the monero-rust ecosystem seems to be paying off pretty well (in my totally unbiased opinion :P ). 
16:20:54 <kayabaNerve> BusyBoredom[m]: I'm actually trying to drop that lib. It has a lot of bad design decisions when you work on a deeper level IMO and it was written as a minimal set of types meant for RPC work expanded as needed.
16:21:14 <kayabaNerve> And while it's great with its functionality state, I don't believe it's optimal for more complicated work.
16:21:49 <kayabaNerve> I do believe it counts as new people who want to do a full daemon. I don't currently want to do a full daemon.
16:22:02 <BusyBoredom[m]> Ah that's a bummer, I've only used it for higher-level stuff so I wasn't aware of the low-level deficiencies :( 
16:22:13 <kayabaNerve> It just constantly byte encodes D:
16:23:00 <kayabaNerve> I do believe the XMR protocol should be formalized and we should aim for the ability to have a multi-daemon future as I believe those only fail when there's no protocol spec to match or implementors suck. I don't see that as any immediate goal though, and it'd be a multi-year target.
16:23:30 <kayabaNerve> Pinging sethforprivacy due to a semi-related discussion we personally had earlier on protocol development
16:24:37 <hyc> an actual protocol specification would be great...
17:55:17 <selsta> hyc: intel binary it also runs on 10.13 according to jeffro256[m]
17:55:37 <selsta> i'm quite surprised that using the new SDK works for such old OS versions
18:48:19 <hyc> we're at the threshold I think. older 10.x revs are gone from there
18:48:46 <hyc> so it sounds like we're in good shape for this PR
18:58:14 <selsta> hmm I just remembered that I have a 10.12 VM, I'll test it too
18:59:29 <selsta> but in any way 10.13 is good enough for backwards compatibility
22:00:29 <hyc> still have min version set to 10.8