<r​brunner7:monero.social> Meeting in 1 hour

<j​berman:monero.social> Likely won't be able to make today's meeting unfortunately. This week will work on audit coordination and getting beta ready

<r​brunner7:monero.social> Meeting time. Hello! monero-project/meta #1344

<s​needlewoods_xmr:matrix.org> Hello

<j​pk68:matrix.org> Hello

<r​brunner7:monero.social> From jberman about half an hour ago: "Likely won't be able to make today's meeting unfortunately. This week will work on audit coordination and getting beta ready"

<r​brunner7:monero.social> In last week's MRL meeting it basically was also only Rucknium and me :)

<j​effro256:monero.social> Howdy

<r​brunner7:monero.social> Alright, what is there to report from the last 2 weeks? Me: Checking wallets and wallet source code regarding Polyseed support. Slowly arriving somewhere.

<j​effro256:monero.social> Me: Cypherstack finished their carrot_core audit: github.com/cypherstack/carrot_core-…dit/blob/main/carrot_core-audit.pdf. I finished with first round of review on beta scaling after talking with Artic and j-berman: seraphis-migration/monero #282.

<r​brunner7:monero.social> Found out that the `monero_c` build process is a true marvel.

<s​needlewoods_xmr:matrix.org> still mainly working on wallet-rpc, counting `m_wallet` 144/354 (354 is the count on `master` branch)

<j​effro256:monero.social> Also me: gave a talk at Monerotopia and implemented RandomX V2 support in monero-project/monero #10038

<j​effro256:monero.social> Talking with some auditors about upcoming FCMP++ integration audits

<r​brunner7:monero.social> A few words about Monerotopia? How was your talk received, live?

<j​pk68:matrix.org> Your talk was good, Jeffro :)

<j​pk68:matrix.org> I watched online

<r​brunner7:monero.social> Are the talks online already, linked from the Monerotopia website then?

<i​ntr:unredacted.org> I don't know about a link from monerotopia but they are on twitter (cut into individual videos), and the entire livestreams are on youtube on the Monerotalk channel

<r​brunner7:monero.social> This maybe: monerotopia.com/monerotopia2026-virtual-conference

<s​needlewoods_xmr:matrix.org> youtube.com/@MoneroTalk/streams

<i​ntr:unredacted.org> and:

<i​ntr:unredacted.org> x.com/XBTXMR/status/2022623288120250599

<i​ntr:unredacted.org> xcancel.com/XBTXMR/status/2022623288120250599#m

<j​effro256:monero.social> Monerotopia was awesome, definitely recommended to anyone if they can make it. There was nowhere near the OVK doomerism in person as online ;)

<r​brunner7:monero.social> Good to hear!

<j​effro256:monero.social> Lots of great talks in the dome and out of the dome

<j​effro256:monero.social> Met the Cyperstack folks for the first and they're great too

<r​brunner7:monero.social> You mean their new people?

<j​effro256:monero.social> Any of them ;) Never met Diego in-person, nor Luke, nor Rigo, nor Josh, etc

<j​effro256:monero.social> nor Brandon

<j​effro256:monero.social> I guess I've met Sarang, who *used* to be at Cypherstack IIRC

<r​brunner7:monero.social> I see. Yeah, it's nice to finally meet people in the real world, after so many virtual contacts

<r​brunner7:monero.social> Alright, seems that's it about the reports. Do we have anything to discuss today beyond those?

<s​needlewoods_xmr:matrix.org> I noticed something in regards to exceptions in wallet-rpc

<s​needlewoods_xmr:matrix.org> in wallet-rpc we often have this pattern `try { m_wallet->some_method(); } catch (const std::exception &e) { handle_rpc_exception(std::current_exception); }` e.g. [here](github.com/monero-project/monero/bl…t/wallet_rpc_server.cpp#L2367-L2384), meaning the exception comes directly from `wallet2`. Now the Wallet API handles<clipped

<s​needlewoods_xmr:matrix.org> exceptions on it's own (by `setStatusError(error_msg)` if there was something to catch) and does not propagate them.

<s​needlewoods_xmr:matrix.org> For now I added a macro to wallet-rpc that I call after `m_wallet_impl->someMethod()` to keep the pattern: `THROW_WALLET_EXCEPTION_ON_API_ERROR(tools::error::wallet_internal_error)`

<s​needlewoods_xmr:matrix.org> But this way we lose control of `handle_rpc_exception()` [src](github.com/monero-project/monero/bl…/wallet/wallet_rpc_server.cpp#L3809), most importantly the `er.code` for the response.

<s​needlewoods_xmr:matrix.org> Any suggestions are welcome.

<s​needlewoods_xmr:matrix.org> don't need an answer now, just wanted to get it out

<r​brunner7:monero.social> My first naive reaction is the question why still handling anything with exceptions in the RPC code? Are there other sources of exceptions than then Wallet API?

<r​brunner7:monero.social> Or better said, now that the Wallet API is no source of exceptions anymore, what is left?

<s​needlewoods_xmr:matrix.org> yes, a lot of arguments are getting pre validated

<j​effro256:monero.social> Ah I see, I think that I would break the pattern in wallet-rpc then if we plan to keep using the check-type API. Very few endpoints in the `wallet2_api` actually throw exceptions, right?

<s​needlewoods_xmr:matrix.org> I mean e.g. something like this github.com/monero-project/monero/bl…c/wallet/wallet_rpc_server.cpp#L651

<s​needlewoods_xmr:matrix.org> AFAIK if they throw exceptions, then the implementation is incorrect

<r​brunner7:monero.social> I would also strongly suspect that exceptions are not part of the API, so to say

<j​effro256:monero.social> Looking at the source, a lot of the multisig code throws exceptions, but that's all the exceptions that I can see which *originate* in the wallet2_api

<j​effro256:monero.social> So that feels like a mistake

<j​effro256:monero.social> So yeah if we plan to stay with the current `wallet2_api` exception handling, then it's RPC which hould be refactored

<s​needlewoods_xmr:matrix.org> if you are referring to [checkMultisigWalletReady()](github.com/monero-project/monero/bl…749a/src/wallet/api/wallet.cpp#L120) that method is called inside a `try` block [src](github.com/monero-project/monero/bl…49a/src/wallet/api/wallet.cpp#L1524)

<r​brunner7:monero.social> Your question basically is whether people also see your approach as the "least bad" that is possible while keeping the general exception centric approach, SNeedlewoods ?

<j​effro256:monero.social> If the `wallet2_api` exception handling isn't "rich" enough to keep the RPC API intact, then that information needs to be added to the `wallet2_api` exception handling

<s​needlewoods_xmr:matrix.org> Yes

<r​brunner7:monero.social> Don't remember right now, does the RCP interface give back detailed error info to the remote caller?

<s​needlewoods_xmr:matrix.org> An alternative I see (which I think is very bad) is to read the error messages in the wallet rpc and then throw according to the messages

<r​brunner7:monero.social> Or is it more a question of what goes into logs?

<s​needlewoods_xmr:matrix.org> The logs will change slightly, but that shouldn't be a big problem AFAICT. I'm more concerned about the error codes that get returned by failing RPC calls

<j​effro256:monero.social> github.com/monero-project/monero/bl…let/wallet_rpc_server_error_codes.h

<j​effro256:monero.social> These errors code should absolutely retain their place in the API

<j​effro256:monero.social> And also their corresponding error messages, but to a much lesser extent IMO

<s​needlewoods_xmr:matrix.org> I will focus on this during this week

<r​brunner7:monero.social> Maybe there is some way to make codes available to callers that does not break the API? And then it's only question of translating Wallet API codes to RPC wallet codes.

<r​brunner7:monero.social> That stuff is too far away, have to check again

<s​needlewoods_xmr:matrix.org> Alright, thanks for the feedback

<r​brunner7:monero.social> Ok, looks like we can close the meeting here. Thanks everybody for attending, read you again next week!

<s​needlewoods_xmr:matrix.org> Thanks everyone, see you

<j​pk68:matrix.org> Thanks

<j​pk68:matrix.org> I'm just interested in contributing - if there's something I can help with, I'd be happy to

<j​pk68:matrix.org> Sorry for sending late, haha

<r​brunner7:monero.social> Great! Are you already aware about this list? github.com/monero-project/monero/issues

<j​pk68:matrix.org> Yes :)

<j​pk68:matrix.org> I got a merged PR in the Monero repo a week or two ago

<r​brunner7:monero.social> Splendid.

<r​brunner7:monero.social> I think as soon as the FCMP++ stuff goes into broader use, e.g. with beta testnet, there will be a lot of work "at the fringes", beside what jeffro and jberman do as core devs

<r​brunner7:monero.social> And testing, of course. There can never be enough testing :)

<j​pk68:matrix.org> For sure, thank you

<j​pk68:matrix.org> Just posted in case there was anything wallet-specific recently

<j​effro256:monero.social> Please bully the Trezor and Ledger devs into responding to my emails

<j​effro256:monero.social> I'm trying to help them with the integration

<r​brunner7:monero.social> How long does this "game" already do on? Do they basically ghost you?

<r​brunner7:monero.social> *go on

<j​effro256:monero.social> Yeah, more or less. I'm sure they're actually busy but I have gotten zilch back

<j​pk68:matrix.org> Unfortunately I have no connections there ;)

<j​pk68:matrix.org> I wish I did

<r​brunner7:monero.social> I wonder when we reach the point where we can try to go public with this problem in our and their subreddits ... less directed, but a lot more eyeballs

<r​brunner7:monero.social> We could threaten them with making a million AI PRs if they don't react :)

<j​effro256:monero.social> matrix.monero.social/_matrix/media/…ero.social/iVxWkecrDmGvUPaYIxpiSSIz