<r4v3r23> with 0 creativity or innovation, just a free claude plan > <@plowsof:matrix.org> the fork will probably be called ANONERO - Community edition, where people actually provide feedback on planned features

<r4v3r23> you do your fork, and copy our real development when were done

<r4v3r23> now merge the CSS

<r4v3r23> luigi1111 plowsofs games have gone on long enough

<r4v3r23> and @ofrnxmr:xmr.mx have you seriously got nothing to say here. you said youd support the proposal, and you see exactly what plowsof is doing

<r4v3r23> and have done 0 innovation or benefitted that acutal wallet space in anyway > <@plowsof:matrix.org> compare yourself to other moneujo forks who have actually amassed a community and grass roots contributions who have existed for a shorter time than ANONERO

<r4v3r23> unless you are the one funding CCSs, you have 0 right to block people from supporting

<r4v3r23> merge it and leave it unfunded forever if you are so confident in what you say

<r4v3r23> and about your nitpicking bugs, we are happy to review any cases where you can demostrate how they can be ectively exploited

why not add an exchange service to your wallet? should have no problem raising 100 xmr with commissions from trocador and some others (with a minimum number of users)

<r4v3r23> geonic: because that goes against the ethos of the wallet

<r4v3r23> why not just merge the request and let to community decide whether to fund?

<r4v3r23> they did last time for the first CCS

<pw:xmr.mx> wallets don't need built in exchanges. there are already exchange services and wallets with it built in

<monerobull:matrix.org> @r4v3r23: we have to execute everyone who brings this as an argument for merging a CCS

<plowsof:matrix.org> 0 creativity? ANONERO is now the first mobile wallet which can seamlessly connect to/from a monero LWS server without losing history codeberg.org/iuanv9/anonero-fork/releases

<plowsof:matrix.org> any problems / requests make an issue on the repo for the rent a dev

<plowsof:matrix.org> @r4v3r23:monero.social: "Create a wallet" -> "select a node" 😆 maybe he should make it an actual cold signer

<plowsof:matrix.org> @user2570:unredacted.org: have the MDC created any concepts for the new ui you would like to share?

<pw:xmr.mx> @plowsof:matrix.org: oh God. you had to open that can of worms didn't you

<r4v3r23> @monerobull:matrix.org: even a project hat has already completed one....?

<r4v3r23> have fun with your fork, enjoy it > <@plowsof:matrix.org> 0 creativity? ANONERO is now the first mobile wallet which can seamlessly connect to/from a monero LWS server without losing history codeberg.org/iuanv9/anonero-fork/releases

<r4v3r23> now merge the CCS

<r4v3r23> lmao chat gpt fork

we are talking about someone making some fork of monero that spammed rooms a while ago

<jpk68:matrix.org> He just uploaded a vibeslopped P2Pool clone in one commit and then vanished

<jpk68:matrix.org> The AI revolution and its consequences 😔😔

<rbrunner7> Who? That "iuanv9" dev?

see privatebin.net/?d8f3e606367d3cae#6k…P8FC4sTo5jxChP9YTtZSL6mujebfqdYd2NB and privatebin.net/?5217fc19017cc479#6d…4yVyqy9T9WsGAkXLe31GoNnqixB18tFAAEF

damn rbrunner7 you ALSO talked with this one

and forgot like sech1

<pw:xmr.mx> privatebin.net awsesome. thanks for that one DH

<jpk68:matrix.org> {i,u,d,f}uyua9 is presumably some account-farming bot

<jpk68:matrix.org> Make 10 accounts to get bugfixes merged in "famous" projects, and then sell them

<rbrunner7> Ah, that mythical, mysterious July 1 Monero fork. We do have a lack of forks nowdays. Back in 2017 and 2018 we had one come out every month or even faster. Those were the times.

<rbrunner7> But already back then, sadly mostly code forks, not chain forks where you have the real fun.

<hbs:matrix.org> @rbrunner7: This one was a planned chain fork, I guess the forkers must have too poor network coverage to keep us posted

<r4v3r23> @rbrunner7: chatgpt

<r4v3r23> plowsof has a personal grudge against anonero and is trying to vibecode everything just so we dont get funding

<pw:xmr.mx> @r4v3r23: why do you think so. he has offered help and has even helped with a few small things..

<pw:xmr.mx> surely I can't be misreading/understanding

<r4v3r23> @pw:xmr.mx: no he heasnt. thers history here. yo ucan look kat his comments before starting his fork, its clear

<r4v3r23> all this conern trolling for the quality of the project suddenly came up when the new CCS was getting support

<r4v3r23> despite ANONERO being around for years and already completing a CCS

<r4v3r23> either way, were not obligated to merge or accept any of his AI slop

<r4v3r23> our CCS features are already well researched and designed

<r4v3r23> if he genuinely wanted to help, hed do his job and merge the supported CCS and then offer to help in the process for things we missed

<r4v3r23> but hes actively gatekepping and trying to block it at every turn

hbs is your MoneroSwap project also using `label` to export/import wallets? monero-project/monero #10168#issuecomment-4875936763

<hbs:matrix.org> It doesn't export/import wallets per se, but the monero_wallet URIs it generates to restore wallets (both view only and full) include a label parameter which contains a unique (well most likely unique) name for the wallet so it can be automatically assigned (though only by Cake Wallet for now) when the QR code is scanned.

<hbs:matrix.org> It assign a name MS-CCC-HHH-XX-{V,F} where CCC is chainid, HHH is part of the contract address, XX is the swap id

<hbs:matrix.org> and V is for View only, F for Full

<hbs:matrix.org> While you're dusting off this issue @plowsof:matrix.org , the convention for height also needs to be clarified so dates can be specified. I suggest the same convention as for time lock be used, i.e. values below 1500000000 are considered block heights, anything above is considered a timestamp in seconds since the Unix Epoch

<ofrnxmr:xmr.mx> i think we should just stick to block heights

<ofrnxmr:xmr.mx> or, if the field is and iso8601 formatted date, to use a date

<ofrnxmr:xmr.mx> or, whatever logic monero-wallet-cli uses to differentiate between heights and dates

<ofrnxmr:xmr.mx> but KISS is to just use heights. pretty sure even polyseed will accept a height

<ofrnxmr:xmr.mx> > <@hbs:matrix.org> It doesn't export/import wallets per se, but the monero_wallet URIs it generates to restore wallets (both view only and full) include a label parameter which contains a unique (well most likely unique) name for the wallet so it can be automatically assigned (though only by Cake Wallet for now) when the QR code is scanned.

<ofrnxmr:xmr.mx> and fwiw, monero_wallet was changed to monero-wallet. cake might still support _, but its invalid

a locktime convention on a height param could satisfy both capms

camps

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

<ofrnxmr:xmr.mx> so if moneroswap uses monero_wallet, should change it to monero-wallet (cake supports - as well, so no change to end user)

ah the underscores, forgot about that 👍

<hbs:matrix.org> The issue is when generating URIs where the block height is not known and not easily accessible but the restore date is, so I believe there is a need for a way to specify an ISO 8601 date or epoch based timestamp. > <@ofrnxmr:xmr.mx> i think we should just stick to block heights

<hbs:matrix.org> Good that the spec is being evolved, too bad some of the clarifications I suggested are still pending, notably where some of the parameters should be specified which is unclear (examples contradict the description).

<ofrnxmr:xmr.mx> its because its not a PR :p

<hbs:matrix.org> @ofrnxmr:xmr.mx: The inital spec was on the Wiki which did not accept PRs as per GitHub enshitification

<ofrnxmr:xmr.mx> diffs make the world go round. its a lot of work to open 2 tabs

so work is still required to get everyone to _leniently_ accept the "legacy" JSON (with optional label fields) 😭 + move to standard URI's (in unknown signer users pick between the json or uri when exporting)

<hbs:matrix.org> @ofrnxmr:xmr.mx: will open a PR this we then

<ofrnxmr:xmr.mx> plowsof: Why would anyone accept non-standard json

the millions of users with JSON qr's in the safety deposit boxes will be furious

<ofrnxmr:xmr.mx> Wallets who generated it, can keep reading it, but absolutely nobody should be expecting to have that mumbo jumbo sent to their wallet on a qr code restore

<ofrnxmr:xmr.mx> Imagine is moneroswap thought it was normal and started using that junk too

i guess only the group of esisting JSON-ees should support each other

<ofrnxmr:xmr.mx> if that. I doubt there is anybody with a printed qr code of the json, and old versions of cupcake, feather, snd even anon are not recommended / are fully deprecared

but these wallets have been around for years !!!!

<ofrnxmr:xmr.mx> So.. just because you have an old version of cupcake on an airgapped device, doesnt mean its actually supported

<ofrnxmr:xmr.mx> But yeah, cake doesnt usually remove stuff (still supports monero_wallet, just added monero-wallet), but the apps generating the json should stop

yep

<ofrnxmr:xmr.mx> Since it is, by definition, not following the spec

<ofrnxmr:xmr.mx> Unless, of course, the goal is to be incompatible with other wallets (version: 66) etc.

<ofrnxmr:xmr.mx> The info is entirely universal, so no idea what that version string is used for, other than noise

<ofrnxmr:xmr.mx> @hbs:matrix.org: i notices feather, when restoring from keys > wallet type > spendable = it only asks for spend key (not main address or view key). so im not entirely sure either of those is required (as per your chart)?

<ofrnxmr:xmr.mx> non-deterministic wallets require spend, view, address though

<ofrnxmr:xmr.mx> and view require address and view

<hbs:matrix.org> @ofrnxmr:xmr.mx: yep, non deterministic wallets need both view/spend

<hbs:matrix.org> @ofrnxmr:xmr.mx: I'll add a note stating that for deterministic wallets viewkey can be omitted.

<ofrnxmr:xmr.mx> address too

<ofrnxmr:xmr.mx> note would be something like 'address', 'view key', * only required for non-determinisitic wallets

would you believe me if i said ANON doesnt import featherwallet wallet QR's

FW has a walletName param 😭

<hbs:matrix.org> @ofrnxmr:xmr.mx: @plowsof:matrix.org monero-project/monero #10854 if you can have a look at that first draft.

<hbs:matrix.org> @hbs:matrix.org: I was thinking about adding QR Codes to that page, to make it easier to test how those URIs work.

<hbs:matrix.org> @hbs:matrix.org: Enough thinking, added the images.