I am following the build instructions on github but when I run make -j$(nproc) it fails to build. the only thing I can see is it says ccache is found but unusable

but I checked and I can certainly use ccache

<omurad:matrix.org> ccache is probably not the issue, there's likely another error further up in the logs

This is everything that I see bpa.st/BUMA

<omurad:matrix.org> You're on the newest version of CMake, which doesn't seem to play nicely with v3.10+

so I ran `cmake -Wno-dev` and then `make -j$(nproc)` and that appears to have worked

my repo is an absolute shitshow now, but the binary did get built xD

<kiersten5821:matrix.org> hi > <@plowsof:matrix.org> hello from matrix org account

<ofrnxmr:xmr.mx> miguel: This should be fixed a long time ago

<ofrnxmr:xmr.mx> monero-project/monero #9932

<ofrnxmr:xmr.mx> fixed here: monero-project/monero #9932#issuecomment-2910782334

<hbs:matrix.org> Bumped into an issue while testing the upcoming version of Monerujo, the format of the monero_wallet URIs it supports differs from the format supported by Cake Wallet. I filed an issue almost a year ago to bring clarity to the URI specification but it has remained unnoticed until now.

<hbs:matrix.org> I am therefore calling all Monero wallet developers to look into the issue related to Monerujo (m2049r/moneroju-issues #1) and to the issue related to the URI spec (monero-project/monero #10168) so they can consider vetting the proposed changes, bringing clarity and advanced fe [... too long, see mrelay.p2pool.observer/e/07yVn-cKM3BPOEhs ]

<321bob321> There here somewhere

hbs step 1 first remove the "address=" param from your uri, its a path and not supported in wallet2 afaict, noted by the "hierarch." and the resulting error when attempting it with wallet-rpc - if this is confusing suggest clarification, im not concerned with third party not adhering to uri specs. step 2: the monero gui will interpret "height" as

blockheight OR date when creating a wallet depending on value entered, not sure if this is implemented by wallet2 but think logically - passing a date has to then be converted into an estimation blockheight and can be inaccurate (reg inaccurate height estimations ofrnxmr linked monero-project/monero #10165/changes) step 3:

make an issue on docs so ofrnxmr knows about the Note reg payment id not being accepted anymore in parse_uri / make_uri (confirmed just now) step 4: reg name, look at create_wallet wallet-rpc call - it accepts a `filename`, use human language to justify the inclusion of a filename param in the uri instead of your proposed `name`

also hbs "calling all Monero wallet developers" i left a similar comment on the other issue which had no response from you. and you have just had feedback from monerujo dev on the issue. do you actually want feedback or are you looking for people to agree with you

<hbs:matrix.org> plowsof: It's not mentioned in the original spec as part of the path hierarchy, hence my proposal to clarify the spec. Unfortunately Cake so far has considered it as a parameter (the column where the address name appears is called Parameter, so this is a perfectly valid interpretation).

<hbs:matrix.org> plowsof: I don't want people to agree with me, I want people to realize there's an issue to be debated to improve things. I answered @m2049r:matrix.org latests comment 4 hours ago, I don't see any more recent one, is that the one you had in mind?

kind -> hierarchy. , again, if you think it's an issue submit a suggestion to clarify.

hbs we're not even at any step yet, you seem to think mentioning "all wallet devs" will tag them should they happen to read the backlog

<hbs:matrix.org> plowsof: Could you please read what I wrote? The document github.com/monero-project/monero/blob/master/docs/URI_SCHEME.md DOES NOT HAVE a kind column for describing the monero_wallet URIs, that column is only present for the monero scheme, this is the reason why I opened the issue in the first place, to propose a clarification of the spec!

great, lets suggest improvements first, step by step instead of coupling them with your needs/wants

and ignoring my comments for those needs/wants

<ofrnxmr:xmr.mx> monero_wallet:41pr4B7Cw6Ke4C54ngcy2FBVVGCLAzhi1PgMy68baMMYW7DXq9C8SS42HCaPyc7wyVZFaF8bJJEtq6eZkXT8yCFWR3eRbB9?

<ofrnxmr:xmr.mx> address=41pr4B7Cw6Ke4C54ngcy2FBVVGCLAzhi1PgMy68baMMYW7DXq9C8SS42HCaPyc7wyVZFaF8bJJEtq6eZkXT8yCFWR3eRbB9&view_key=41bedfd209fa9df3879fbbabddee27bd1b03d0a4b812340f8959b0d9de576a06

<ofrnxmr:xmr.mx> Why have the address specified twice?

because it can be a subaddress?

just guessing

<ofrnxmr:xmr.mx> its for restoring a wallet

<ofrnxmr:xmr.mx> So would have to be primary

<ofrnxmr:xmr.mx> Cake docs docs.cakewallet.com/faq/glossary/ur…me/#universal-wallet-restore-format

<ofrnxmr:xmr.mx> Cake example

<ofrnxmr:xmr.mx> [... more lines follow, see mrelay.p2pool.observer/e/hIqQp-cKUXIyZ0F4 ]

<ofrnxmr:xmr.mx> > Cake Wallet for example expects (or at least expected until recently) the address to be provided in an address parameter in the query string.

<ofrnxmr:xmr.mx> i don't think this is correct. I dont recall cake's doc changing for years

<ofrnxmr:xmr.mx> Cake's internal scheme uses address as a parameter: docs.cakewallet.com/faq/glossary/uri-scheme/#cake-restore-format

<ofrnxmr:xmr.mx> cakewallet:monero-wallet?address=467iotZU5tvG26k2xdZWkJ7gwATFVhfbuV3yDoWx5jHoPwxEi4f5BuJQwkP6GpCb1sZvUVB7nbSkgEuW8NKrh9KKRRga5qz&spend_key=029c559cd7669f14e91fd835144916009f8697ab5ac5c7f7c06e1ff869c17b0b&view_key=afaf646edbff3d3bcee8efd3383ffe5d20c947040f74e1110b70ca0fbb0ef90d&height=100000

<hbs:matrix.org> @ofrnxmr:xmr.mx: This doc mentions a scheme of monero-wallet instead of monero_wallet too

<ofrnxmr:xmr.mx> Yeah, cuz cake does cake things

<hbs:matrix.org> to be compatible with the maximum of wallets for as long as the spec is unclear > <@ofrnxmr:xmr.mx> Why have the address specified twice?

<ofrnxmr:xmr.mx> adaik, monero-wallet and monero_wallet are interchangeable in cake

<ofrnxmr:xmr.mx> @hbs:matrix.org: Restoring multiple wallets at once?

<hbs:matrix.org> @ofrnxmr:xmr.mx: wallet software I should have said

<ofrnxmr:xmr.mx> delete the address= and it should be compatible with all walleta

<ofrnxmr:xmr.mx> If its not, the wallet is using a non-standard spec

<hbs:matrix.org> @ofrnxmr:xmr.mx: last I had checked cake did not support the address in the path portion of the URI, will test again

<ofrnxmr:xmr.mx> cakes example says they do

<ofrnxmr:xmr.mx> i will try now

<ofrnxmr:xmr.mx> works fine

<ofrnxmr:xmr.mx> I have an older version of monero.com (5.6.0) and qr restore is broken

<ofrnxmr:xmr.mx> Cake 5.8.0 is not broken

<ofrnxmr:xmr.mx> Broken = it doesnt accept even their own examples

<hbs:matrix.org> Works with monero.com 5.9.0

<hbs:matrix.org> \o/

<hbs:matrix.org> So this is probably a recent change indeed

<hbs:matrix.org> Never the less I think it is important to clarify the spec to avoid such drama

<ofrnxmr:xmr.mx> cake has it clarified in theirs, but theirs was still completelt broken.

<ofrnxmr:xmr.mx> i dont know whay heirarch. ? Query fragment mean

<hbs:matrix.org> hierarchy if the path portion of the URI (the one after the URI scheme in the absence of authinfo + host / port)

<hbs:matrix.org> The fragment is the part introduced by a hash (pound) sign.

<ofrnxmr:xmr.mx> Could jist be simplified, like. Path vs param

<ofrnxmr:xmr.mx> @hbs:matrix.org: tx_description is not kntroduced by a # sign

£ time for a cup of tea

<hbs:matrix.org> @ofrnxmr:xmr.mx: It should as per the table on github.com/monero-project/monero/wiki/URI-Formatting, but it is not in the examples provided!

the example wants us to end with description? using "&"? how to describe that correctly if so

<hbs:matrix.org> plowsof: The table should describe tx_description as being a parameter, in which case both examples would be correct, ?tx_description=.... when tx_description is the first parameter in the query string, ...&tx_description=.... when there are preceding params.

also this is my opinion

are "?" and "&" interchangeable delimiters for things in URI land? i dont know the significance

the seed should be a base64 of the seed

the seed paramter*

and not the polyseed/24-word encoding of the seed

<hbs:matrix.org> plowsof: ? introduces the query string, within the query string parameters are separated by ampersands

it wastes too much URI space

<hbs:matrix.org> Cindy_: can you decode base64 in your head?

this is literally a URI

it is decoded by a program

not by a human

<hbs:matrix.org> Cindy_: 99% of the scams are due to people not checking URIs, maybe it's time humans start doing just that?

<hbs:matrix.org> Oh and base64 of the seed would consume 33% more space than the actual seed

just saying, i don't like how the specs say the "seed" parameter is required to be a 24-word/polyseed representation of the seed

because it wastes too much space

"Oh and base64 of the seed would consume 33% more space than the actual seed" 24-word/polyseed consumes 160%+ more space than the actual seed

actually 160% is too small

it would probably be 500%

<hbs:matrix.org> I think you assume seed to be the secret derived from the mnemonic? I think in this spec seed means the mnemonic

spend+view keys rather than mnemonic right? this is also supported to save the most space afaict

i meant seed key rather than mnemonic yeah

(the key encoded in hex/base64 or whatever, rather than in mnemonic)

<hbs:matrix.org> plowsof: Though using hex is bad for conciseness

plowsof: if the spend+view keys are derived from the seed key, then wouldn't it save extra space storing the seed as hex?

it would be one 32-byte seed

rather than a pair of 32-byte keys

molly wallet can restore a full wallet from just the spend key iirc

<hbs:matrix.org> Cindy_: It's not really about storage efficiency but conformance with what wallet software expect. I have yet to see a mobile Monero wallet which asks for the seed key instead of the spend/view key when restoring a wallet. Have you met such a beast?

oh wait

what are they called... deterministic wallets?

seed key == spend key

ah

<hbs:matrix.org> plowsof: Only if the wallet used a deterministic wallet though

the view key is derived from the spend key

now i remember :P

<hbs:matrix.org> Cindy_: Not necessarily

asking permission to say a rot13 joke

<hbs:matrix.org> plowsof: You'll ask for forgiveness after, bring it on

hbs: but doesn't CryptoNote say that?

ok so ROT13 does not add any size to the seed what so ever.. zero.. none and adds encryption with zero drawbacks.

sorry

the seed is the spend key, and the view key is derived from the spend key

if your wallet software doesn't follow this, then well uhh.. good luck :P

<hbs:matrix.org> Cindy_: The deterministic wallets derive the view key from the spend key, but technically they are independent

👍

yes they're independent

but to prevent any headaches with compatibility and such

wallets just use the same algorith

<hbs:matrix.org> We are so lucky the wallet software (end user and libraries) support setting them independently, otherwise atomic swaps would not be possible > <Cindy_> if your wallet software doesn't follow this, then well uhh.. good luck :P

if part of the spend key is provided and part of the address - our device could brute force the winning seed to reduce space even further

<hbs:matrix.org> plowsof: Proof of Wallet!

<sgp_> Skylight Wallet for iOS TestFlight is now available: testflight.apple.com/join/YSjKgHQ6

<hbs:matrix.org> @sgp_: Does Skylight Wallet support monero_wallet URIs for restoring wallets?

<sgp_> Not currently

PSA: the software linked above is being marketed by a senior director at a blockchain surveillance company

sgp_: a message like that would be great