I have a visceral hatred for EPEE and will not stop until it is completely dissolved

<jeffro256[m]> "I have a visceral hatred for..." <- why is it called epee by the way? does it have something to do with electronic urine or is there a different reason? I know its an old library that came from somewhere. I googled, but couldnt find anything.

jeffro256[m]: maybe it's easier to do it in a single PR with multiple patches?

better overview and easier to review

but you can keep the already opened PRs open obviously, just for future patches

spirobel[m]: it's a helper library written by andrey sabelnikov

allegedly it was used for botnets but he denied that

sabelnikov reused it when programming cryptonote and bytecoin

selsta > jeffro256: maybe it's easier to do it in a single PR with multiple patches?

Yeah I was going to ask: should I split it up into modular bits or combine it into one big PR? What would be easier for you all?

one PR with multiple patches

okay! I'll start one more new one, name it something general, and put future epee cleanup comits in there

sounds good

hi all, i got contacted by one of the airgap.it devs who's interested in creating a standard for qr-based offline txs in monero

its possible in theory, the only potential bottleneck is the size of the outputs/key images files from wallets with loads of txs

moneromooo: plowsof mentioned that you said there could be some easy wins in reducing those file sizes

I think so. I never tried to minimize the amount of data in those.

I guess I could have a look at it. Useful, and might get me back to coding.

technically animated QR can fit a few MBs of data, but users would have to scan for a few minutes which isnt a great UX

so any reduction in data size would help make this really user-friendly and add an awesome alternative to HWWs

moneromooo: thanks

AirGap re: offline txs - "We would definitely need help in the monero specifics because noone in our team has knowledge there. Also, our wallet is cross device (runs on phones, but can also be used on Linux (eg. Tails), so it is based on javascript. Are there any good libraries available in js to do all the crypto operations like generating addresses and signing transactions?"

If you want to code your own wallet, you get to read the code :)

But mymonero has js code to do some of that.

oh that's me

endogenic: guessing mymonero doesnt have the option for offline txs?

it does

you'll just need to use the interfaces for working with a light wallet server for now

i could provide you with a high performance and secure scanning service and then you'd use our code

for client side

well, that's the theory anyway

otherwise, you'd need a service to make various things available to your cold client

the code is very close to mainline's full wallet code

i've wanted it to converge for years

but i'm just one person

hard to keep up with everything i have on my plate sometimes

i've done lots of research into the techs related to your product

even developed a version of it

guess the cat is out of the bag

im not from airgap - i was asking around about qr codes for xmr and they reached out

they are definitely interested

oh my bad

yeah i mean the concept is legit

makes me want to cry

cause i'm slow

for sure. just needs to be worked out

but yknow what drake says. not about who did it first but who did it right

so i'll send them your mymonero-core-js lib

endogenic: you've got a working version?

yes but tell them i left that co 2 yrs ago

i have a much better core lib now

but it's not yet public

yes i do

i mean the concept already exists for monero

someone made a gtk(?) or qt app for it for linux ages ago

had a funky name

endogenic: would you be down to be their poc?

happy to talk with them, sure

im no dev so this will all go over my head

not my priority to provide enterprise services right not because i'm overwhelmed but my team certainly can do it

right now*

feel free to DM me

we can exchange contact indo

info

awesome, ill get the contact info and DM you

Hey the cmake generates the Makefile, right? if I wanted to run cmake with a new setting, how would I go about doing that?

Specifically I want -D CMAKE_EXPORT_COMPILE_COMMANDS=1

`mkdir b; cd b; cmake -D CMAKE_EXPORT_COMPILE_COMMANDS=1 ..; make`

That wrote everything to to the project root directory. Any way to avoid this?

jeffro256[m]: `mkdir build && cmake -S . -B build -D CMAKE_EXPORT_COMPILE_COMMANDS=1 && make`

jeffro256[m]: it should write everything into the `b` dir if you did the same steps as I wrote

UkoeHB solution should be equivalent

any traction on #1070?

bbqcore[m]: seraphis/jamtis will do that

yeah, but thats a while off

just realized there was a proposed solution for it already

bbqcore[m]: afaict that proposal adds data to txs, which generally kills enthusiasm in most ideas lol. Plus it would break the 'view key contract' that exists right now for view-only wallets (view keys can't see outgoing txs).

gotchya, seraphis it is then.

looks like consensus was reached re: fee change

has the next hard fork meeting been planned?

bbqcore[m]: I don't see any upcoming meetings in the meta repo

thats why i asked :)

My view of the status of tasks for the HF:

- fee change PR has 2 approvals (7819)

- bp+ PR pending final review from vtnerd (7170)

- view tag PR has 3 approvals (8061)

- multisig PRs have 1 approval each from vtnerd + pending final review(s) from h4sh3d (8149, 7877)

- I'm submitting a PR to bump the ring size to 16 today

idk if a meeting is necessary til reviews are done, we're just working through stuff. unless people think a meeting is necessary?

later today or tomorrow I will re-review the fee PR, then do ~final cleanup on the multisig address PR

Is project OSPEAD coming to this HF?

don't think so

dark: No, it's not. We decided a while ago that it's not going in the hard fork. And it doesn't need to be implemented in a hard fork since the change occurs in the wallet software rather than the blockchain consensus level.