03:11:52 Whats souping 09:26:23 [CCS Proposals] plowsoff opened merge request #542: closure/repurpose: close netrik, award remaining to v1docq47 https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/542 12:50:41 https://github.com/monero-project/meta/issues/1149 12:52:48 This shouldnt be repurposed unless the proposer (v1d) requests it 12:54:21 Funds should should sit and chill in the jetfund until requested. V1d's ccs is picking up donations, and its only been a couple weeks 12:55:53 If v1d requested it, i'd ACK it, but w/o a request (or any interaction from him) i dont think we should be spending just bcuz we have it. Save the funds for someone who needs it, not just the first similar ccs that is posted 12:56:10 If we acknowledge that proposer can request leftover funds then everyone is going to do so. 12:58:02 What is the issue with CCS coordinator deciding to redirect funds to similar CCS 12:58:06 And again, we shouldnt be reducing ccs amounts when we repurpose "Reducing the requested amount from 45.6 -> 30.6". We should instead be donating the xmr to the ccs 12:58:08 They already can and do 12:58:50 xmrchat, acceptxmr, haveno app (💀), as example 13:00:04 Doesn't make a lot of sense then. If everyone request it, then the request have no value, the CCS coordinator can just assume everyone would like the repurposed fund and can distribute it accordingly to the relation of the CCS. 13:00:12 The funds dont belong to plowsof - he's not deciding to do anything, he's proposing and iim NACKing 13:00:46 alr 13:01:15 The funds are supposed 2 go tl generalfund. It's my idea that they do not go to GF, and instead remain with community for a rainy day fund. To ideally find like-ccs's in times of slow donations 13:03:37 V1d's ccs has been up for just a few weeks and is typically funded w/o issue 13:06:10 whales (probably) wont be funding things forever. Generalfund is unreliable. The jetfund should be there for us on a bad day, not be empty when we have that day. That was im intent everytime ive discussed jetfund. Not convenience, but necessity. 13:06:12 finishing / build upon another ccs (tipxmr -> xmrchat) is different than a repurpose 13:07:54 Example. I feel dangerousfreedom's dev ccs (if redistributed) should 13:07:54 A) be distributrd equally among current devs 13:07:56 B) be held until devs struggle to get funding 13:07:58 C) be donated to a larger dev initiative, like audit 13:08:00 D) be paid to a dev who finished the work that DF was going to do 13:08:02 Not just be paid to the next dev to open a CCS 13:09:56 ofrnxmr, draft some rules for repurposing, if i like it i can add it to the CCS ransom. 13:10:02 ofrnxmr, draft some rules for repurposing funds, if i like it i can add it to the CCS ransom. 13:11:37 Are we allowed to chop off fingers? 13:11:52 obviously yes 13:21:48 Sounds good 13:37:29 We should admit for a second that monero.garden is incredible. 13:45:14 v1do has been up for funding for 53 days. achieving loose consensus takes time also. Netriks coordinator ccs proposal will have no applicable proposal in sight for repurposing (on account of translation proposals not allowed on the CCS 13:46:44 ofrnxmr "we shouldnt be reducing ccs amounts when we repurpose "Reducing the requested amount from 45.6 -> 30.6". We should instead be donating the xmr to the ccs" Currently not possible as it would require a tweak to the back end. This is why the amount is reduced manually and a _note_ attatched, as is the plan for XMRChat. The CCS maintainer is 13:46:44 fine with this at the moment. 13:48:23 I thought it went to funding in jan? 13:48:28 It doesnt require a tweak, just required luigi to send the funds 13:49:34 the first payment is due 31st December (the confusing part) 13:50:01 it was merged on the 10th December https://repo.getmonero.org/monero-project/ccs-proposals/-/commits/master/v1docq47-monerotopia-2024-voiceovers-and-working-on-xmr.ru.md 13:50:28 just putting it up now for discussion 13:50:35 attaching a note is a poor way to do accounting 13:50:36 All funds should be accounted for in the ccs totals and milestones, not in comments and descriptions 13:51:52 i consider it to be acceptable enough , and so does the maintainer. the alternative being self sending from a cold wallet 13:52:25 xmrchat, v1d etc should not appear on the funding page as worth less than they are 13:52:27 Doesnt req a backend change. Just requires luigi to send 15xmr to v1ds ccs 13:52:50 Or from the spend wallet. Doesnt really make a different 13:53:49 if the funds are literally in the GF, then its still no diff, as the funds need to come out of the GF to pay v1d 13:54:56 By this, i'm referring to the progress bar for funding. 30/45xmr shouldnt show as 15/30. The ccs is 45 xmr, not 30 13:56:28 Better the funds come out now, than v1d claim the funds and later we are wondering if the funds were ever send from GF 13:56:28 currently "_Note: 15XMR has been awarded to v1docq47 after closure of [Netriks translation coordinator proposal](https://ccs.getmonero.org/proposals/netrik-translation-coordination-2.html)_" , this can be changed to make the original total clear 13:57:01 there are more funds to be sent from the general fund - likely in a batch rather than individually (eventually) 13:58:55 or even the title of the proposal can include the original amount 🤷 13:59:49 My point is, is we simply lower the amount on paper (not on chain), then the funds are still in GF 14:00:13 When paying v1d, where are the funds coming from? Ccs wallet. Ccs wallet doesnt have the funds tho? 14:01:08 The logical solution to any of this is to physically send the donation and call it a day 14:01:10 No messy paper tracking, no need to chase down transparency reports or find out where the money is 14:01:26 Everything is done 1 time and problem solved. 14:01:32 i also changed the bigger re-purposing proposal https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/537 14:01:49 simply " will be repurposed or reallocated to similar proposals (subject to community consensus)." 14:02:11 Literally "hey bf, send 15xmr to this proposal. Thx" 14:02:16 Donr 14:06:36 > whales (probably) wont be funding things forever. Generalfund is unreliable. The jetfund should be there for us on a bad day, not be empty when we have that day. That was im intent everytime ive discussed jetfund. Not convenience, but necessity. 14:06:38 > finishing / build upon another ccs (tipxmr -> xmrchat) is different than a repurpose 14:06:53 I disagree with the part about trying to maintain a 0 balance 14:07:41 This means its first come, first serve, and leaves us (community)bnothing to fall back on for a rainy day 14:08:08 (we have GF, which proved useless for a lot of people during out last rainy day event) 14:08:39 Literally got bailed out by our 🐳 buddy 15:20:56 if repurposing 15xmr to a 45 xmr ccs, should the funding page should show as: 15:20:58 A) 0/30xmr (+ a note in description about the 15xmr) 15:21:00 B) 15/45xmr (funds physically sent to the new ccs) 15:21:02 imo: 15:21:04 pros - a) initially easier for wallet holder (dont have to do anything, so ofc maintainer is OK with it), makes ccs appear less costly to casual observer b) accurate display of cost, better accounting (accurate totals and milestones), bonus: if funds are in GF (most purgatory ccs are in GF) then we paying proposers using funds that dont belong to them (we payout from ccs wallet bu 15:21:06 t the funds being repurposed are actually in GF. They need to be moved. Better to move them directly to the proposal than to just mark it on a comment and hope its paid before milestones are collected) 15:21:08 cons - a) gives false impression about value. Requires more work to track b) requires making a transaction 15:23:42 I just realized something 15:23:54 We are calling CCS proposals, the proposal to be approved into CCS. 15:23:59 then we are funding CCS proposals 15:24:05 then CCS proposals are being worked on 15:24:08 then CCS proposals are finished 15:24:23 PROPOSAL SHOULD STOP AT THE FUNDING STAGE 15:24:32 it has become sentient 15:25:12 plowsof what would you call a "CCS Proposal" pass the idea stage? CCS contract? 15:26:24 CCS funding required** 15:26:33 has anyone seen my bike? 15:26:38 lol 15:27:19 After fundind required CCS WIP, then Completed CCS 15:28:49 alright I'll just call these "CCS items" 15:32:59 for v1d, there is also the funds from his own overages 15:33:58 I thought we were talking about the overages 15:34:54 overages not involved in this https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/542 15:35:31 giving netrik the boot (sorry) 15:36:29 Its also not netriks fault that TL workgroup is dead 15:37:18 And it might be alived again when new site comes on 15:37:23 ofrnxmr the cons can be addressed with notes or Notes or **NOTES** or for extreme visibility, amounts in the title so donors can clearly see. and the original quoted amount is written in the proposal 15:37:39 you are underestimating the extreme opsec measures , and risks required to just send a transaction 15:38:02 life and death, the maintainer is not going to addd any extra risks, nor is the GF custodian 15:39:49 netrik was already being replaced michael... michaelizer? by erciccione, he was invoilved in some controversy regarding poor translations already so not happening 15:40:15 and irrc there was a few voices from community suggesting there not to be "1 coordinator" of translations, that each language should have a leader of sorts 15:42:41 why are calling them "maintainer" and "custodian" 15:42:43 Luigi sends funds every couple weeks. Bf wakes up the GF a few times a year 15:43:05 We'll know from the transparency report how often the GF is woken up to pay for infra + donations. 15:43:52 theres 0 rush. He can send the 15 xmr the next time he wakes GF up 15:44:19 And AGAIN, if the actual fund are in the GF, then they HAVE to be sent from GF sooner or later 15:45:30 yes, later, in a batch when necessary 15:46:38 is this later before or after v1d collects his MS? 15:47:48 i could only guess 15:49:30 If after, then v1d is collecting someone elses funds 15:50:03 Theres no reason bf cant send 500xmr today / next time he unlocks the wallet, and luigi donate directly to repurposed ccs when he does payouts and merges 15:52:47 better to focus on things we control 15:54:22 We should control the jetfund 15:54:45 thats like, literally the point of it 15:54:48 the current repurposing amounts which need to be sent to the CCS at some point are noted here https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/503#note_27312 15:56:34 Were those actually paid out? 15:56:47 Monero Outreach round 3 15:56:48 36.68 xmr repurposed 15:57:03 as an example ^ This was repurposed but not claimed yet, right? 15:57:20 correct 15:58:28 brb need to finishe these dishes in 3 mins 15:59:58 geonic has not claimed it yet (although appears to be completed) 16:00:13 surely there isn't a meeting beginning right now 16:00:39 https://github.com/monero-project/meta/issues/1149 16:00:54 Meeting time, greetings! 😬 16:02:36 a new release is on the horizon, selsta made the final checklist here https://github.com/monero-project/monero/issues/9758 16:03:20 if anyone would like to build the release branch (and also pull in 9740 and 9759 that would help them out) i've done so with 3 nodes 16:03:41 Hopefully 1 more pr gets added to that list 0xfffc ! Lol 16:03:43 greetings gentlemen 16:04:22 syntheticbird : i hear cuprate is a daemon that is syncing blocks? 16:05:08 sup 16:05:21 hello r4v3r23, thanks for joining 16:05:28 Greetings from the other side 16:05:38 hey 16:05:42 👋 16:05:52 Hello mr needlewoods 16:06:25 Gm r4v3r 16:07:24 to follow cuprate / cuprated progress, please join the #cuprate channel , theyve been syncing the entire chain faster than release monerod (in _full_ verification and fast sync mode) , their roadmap which is under discussion if interested https://github.com/Cuprate/cuprate/issues/376 16:08:32 -dev should dive into why cuprate is faster than monerod 16:10:06 plowsof suggested I give an update on my OSPEAD CCS: https://ccs.getmonero.org/proposals/Rucknium-OSPEAD-Fortifying-Monero-Against-Statistical-Attack.html 16:10:28 Like I said last meeting (I think), I submitted Milestone 2 last month. I plan to publicly post all OSPEAD-related documents and code on about February 20. 16:10:34 thanks Rucknium! 16:10:54 Since Milestone 2, I learned a bit of Rust and ported a short but time-consuming piece of the OSPEAD R code to Rust. 16:10:56 I achieved a 15x speedup over the R code. This bit of code consumed about half of the times of the whole procedure that used to take two weeks on a powerful machine. 16:11:06 😮 16:11:20 Special thanks to Synbhebird (Crodyceps infected 🍄☣️) for critiquing my novice Rust code. 16:11:22 re: ANONERO - first version (milestone 2) will be ready in a few weeks 16:11:42 thanks syntheticbird! 16:11:47 aiming for end of feb 16:12:10 r4v3r23 sounds great, have there been any surprises along the way? 16:12:51 yes, we had some delays on dev side which i didnt expect 16:13:01 and i underestimated the amount of time/work needed 16:13:12 kotlin and jetpack compose isnt as quick and easy as flutter 16:14:12 thanks for the insight, glad you are pushing forward still 16:14:29 valldrac had contacted me 2~ days ago to share progress on his next milestone (CI / Test related) and feels the 1st July deadline is more than enough. 16:14:53 anhdres / monero gardens repo is active (even had an organic shoutout today) 16:16:44 napoly 16:17:24 <0xfffc:monero.social> 🫡😭 16:17:57 News: [Monero Observer](https://www.monero.observer/) - [Revuo Monero](https://revuo-xmr.com/) 16:18:57 we can jump into the ideas if nothing else at hand to discuss? 16:19:17 add moneronews.net (joking) 16:19:51 ofrnxmr has also completed several milestones recently with basicswapdex and his personal proposal 💪 16:20:22 ya, lets go 16:20:27 Hi together. Giving some sign of live from me :) 16:20:44 👋 16:21:05 can jump into the ideas, some will likely be deferred to no wallet left behind but brought up none the less 16:21:07 a. [XMRChat - a service for content creators to receive messages and tips in Monero.](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/524) 16:22:04 FiatDemise has confirmed that the self hosted version is now working, and successfully sent a tip to their instance. thye've added coin swaps (via trocador) which requires an api key for self hosted instances. 16:22:06 Xmrchat was used on some biger stream the other day and pulled in >100$ 16:22:14 sry for the big delay, 16:22:16 plowsof: indeed, alpha is coming soon 16:22:18 Rucknium: np 16:22:20 ofrnxmr: They are busy enough and Im sorry to think they cannot reproduce such improvements because of the complexity of C++. Cuprate have a very complex architecture when you remove the crates layer. 16:23:04 We accept the challenge 16:23:10 Rucknium suggested the retro payments cover exactly 70.56, and this change was made 16:23:31 🤺 16:24:09 so this would be merged at the same time tipxmr is put to funding https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/530 16:24:44 Yea, to go back to premeeting suggestion, i dont like that the 70 was removed grom the total. It should be included in the total and donated to the proposal at the time of merger 16:25:15 a note at the top should be added to help clarify the funding situation https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/524#note_28356 16:25:39 I just think its adding complexity to a simply task. I dont know where tip funds are (gf or ccs) but if jn ccs, its even easier 16:26:06 If in GF, save the note for a DM to BF for refund 16:26:50 The funds shouldnt (but technically can) be paid paid to from ccs wallet, if the funds are in GF 16:27:24 other than that, the self hosted version "works" and presumably should be merged to funding 16:28:09 I think so. Payouts dont have to be immediate, if more verification is needed 16:28:31 seems we can move on to the next? 16:28:41 👍 16:28:57 b. [NoShore: Groundwork for on-the-go offline payments](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/525) 16:29:13 i had invited the proposer to this room (they where not in) after the previous community meeting 16:29:44 it has been open since 11th December 16:29:47 also invited on the proposal itself 16:30:20 enough time to reach a conclusion, or show something to extend it 16:30:23 I think this is a close.. reopen if they reappear with am update or addressing some feedback or smthn. 16:30:48 But its been nacked and deferred for a while and no feedback this year 16:31:03 i support closure on this one, lack of a buzz around it 16:31:10 we can move on? 16:31:29 actually vthor's work shuld be beneficial to this proposal eventually. 16:31:37 or could be 16:31:49 otslib documentation is boomin 16:31:53 lol 16:32:18 Thanks for the ping I didn't know! Summer here has been crazy busy. Looking forward to work more on the garden soon 16:32:20 Offline Transaction Signing library :) 16:32:37 whats that 16:32:51 vthorksksksksk 16:33:05 Xmrsigner 16:33:09 Think it is another place of construction, full disclosure I was exited to talk with fullmetal science before CCS, and when I finish my CCS it is one thing I want to dedicate my time with to get a protocol up because I think its on of the upmost important features. 16:33:24 also proposal link https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/495 16:33:48 so a closure and open invitation to return for NoShore 16:33:50 @vthor can you send me relevant info 16:33:54 in that threat are also the most conversation about it 16:33:58 if offline signing apps need to make any changes 16:34:28 No, there will be no need, at least for version 1 16:35:22 It will serve exact the same workflow and work as drop in replacement, only for a developer it should be as easy as possible to archive an offline signer. 16:36:08 everoddandeven also made a stand alone monero lws library of sorts 16:36:45 @ https://github.com/woodser/monero-java/pull/117 could be interesting for you both 16:37:09 sorry, not monero-lws, but related 16:37:51 i think we can move on? 16:38:01 r4v3r23 https://otslib.monerodevs.org/sdk/ots/reference/ https://github.com/DiosDelRayo/monero-docs/tree/ots 16:38:02 Yea 16:38:10 c. [dmvp2p: Donate Monero Via P2Pool](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/531) 16:39:02 after the last meeting, i went ahead and made sure to install dmvp2p. 4rkal was correct that its 'simple' (current version requires you to point it to xmrig /p2pool binaries and such. but it simple, and small (less than 20~MB) 16:39:30 i still feel this could be implemented into gupaxx .. a lite mode of gupaxx of sorts 16:40:17 I think value propor a stanalone app to dust accoints requiring primary addresses, isnt there. As a gupaxx plugin, maybe. Echoing myself 16:40:23 proposal created on 23rd December, does not look to have enough positive merge sentiment. 16:40:33 r4v3r23: Sorry was the wrong link, https://github.com/DiosDelRayo/monero/tree/otslib/ots this is the source, I'm not yet awake. 16:40:58 looks to be a closure. 16:41:27 if no changes made by next meeting, i'd say close 16:41:55 moving on then 16:41:56 d. [Funding Proposal for Unstoppable Wallet: Enabling Native Monero Integration on iOS & Android](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/532) 16:42:16 Big nack based on their new funding model that charges $ for privacy 16:42:20 this has still not been acknowledged by the unstoppable wallet team as being real, or any responses in the comments to the serious negative points raised in the comments 16:42:29 Collects data unless you pay them not to 16:43:35 unrelated note: edge wallet (on getmonero) is basically spyware. We should remove that as well 16:43:38 i would also close this before next meeting unless they ..... hm 16:44:26 Unless they stop charging money to opt out of usage statistics. Etc. But they merged those prs despite user feedback 16:45:22 does anyone have comments about UnstoppableWallet ? thefuzzstone has detailed the implications of a subscription based funding model https://github.com/horizontalsystems/unstoppable-wallet-android/issues/7795#issuecomment-2600839762 16:46:02 else we can move on 16:46:09 unstoppable is charging a subscription model for privacy 16:46:29 Tor, usage statistics, duress password 16:46:46 apologies for rushing to cover all ideas, people can drop comments on others out of sync if they wish 16:46:48 The second (usage stats) is an instant close for me 16:46:58 :D there was a time I hoped unstoppable wallet implements finally like promised monero, but always something else was then implemented. Result was I dropped unstoppable wallet. Title unstoppable and without monero is a contradiction. 16:47:34 I've had unstoppable installed for 3+ years, and i'll be deleting it. 16:47:44 ofrnxmr: interesting to hear that, one reason more to not lose a thought on it. (not that I have a bitter sentiment :D ) 16:48:49 Edge is _terrible_ as well. You cant even create wallets unless you are connected to edge 16:49:25 Anyway, i vote close for 2 reasons. Milestone 1 (r&d) and the direction of the software (anti privacy) 16:49:35 lets move on then 16:49:48 e. [Revuo Monero Maintenance (2025 Q1)](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/535) 16:50:25 first payout is already due because of slow to merge and the community are in uproar. this needs to be rectified asap 16:50:53 we can move on. waiting for merge? 16:52:00 dukenukem rottenwheel ^ 16:52:13 moving on? 16:52:36 Next 16:52:44 f. [Btcpayserver plugin](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/538) 16:53:20 Napoly has confirmed there are no blockers for this proposal to be merged as is https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/538#note_28439 16:53:25 Napoly recent comment "As far as I know, there is no support from version 2.1 onward" 16:53:59 is directly contradicted by btcpay dev above "As for the BTCPay Server team, our priority is to release version 2.1 with a Monero plugin that works as it does today, minimizing disruptions for our merchants. What happens beyond this is up to you." 16:54:29 https://github.com/btcpayserver/btcpayserver-monero-plugin and the 2.1 plugin is here 16:55:16 I commented this ^ on the ccs and rotten thumb-down'd my comment as if it wasn't fact. Idk why ppl want to play games 16:57:09 sgp commented " I would support an immediate task to _document_ exactly how lws would work with the plugin and if there are any missing features or performance issues. That doesn't need to wait, if Napoli and deverick want to start on that" 16:57:27 7 up doots and 1 down doot, looks like a clear merge 16:57:58 "wait and see" is very tempting to luigi though 16:58:34 its not a clear merge 16:58:50 The updoots are all from ppl that cant read, no offense 16:58:56 😮 16:59:21 Sgp understood the ccs properly, and as he said theres nothing to do atm except for document the switch to lws 16:59:28 And wait for the 2.1 plugin 17:00:04 bitcart.ai multi wallet / third party instance is up.. working.. dockerised.. simple , i wonder why its not taken off? 17:00:04 Napoly commented just days ago that there is no monero support for 2.1, showing that his finger isnt on the pulse of his own ccs 17:00:21 (more coins than btcpayserver) 17:00:46 Nicolas commented directly on the ccs that btcpay 2.1 would have monero support out of the gate 17:01:23 As sgp said, whatever comes after that should be the focus. Not redoing the whole thing and pretending like there is no monero support 17:02:08 I say leave open, but nap and deverick need to address the fact that a plugin already exists and adjust ccs to account for that 17:02:28 open for feedback, moving on 17:02:51 g. [Add jeffro256 full time dev 2025Q1](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/540) 17:03:00 Clear merge 17:03:08 Bitcart ai is used by servers.guru btw 17:03:24 thats great, did not know this 17:03:33 Monerokon's new pos app uses moneropay 17:03:42 MrNaif^ 17:03:59 working on 🥕implementation , busy bee 17:04:22 servers.guru @servers.guru:matrix.servers.guru servers.guru @serversguru:matrix.org 17:04:46