sounds like people here haven't read The Mythical Man-Month

full rewrite projects fail almost 100% of the time

it's not like there aren't decades of computer science academic and industry experience on this sort of thing already...

<p​olar9669:matrix.org> Tor arti failed ?

<s​ilverpill:poa.st> Even if full rewrite will fail, perhaps some code can be integrated into monero-cpp? Rewriting mission-critical components in Rust might make sense

<1​23bob123:matrix.org> But its memory safe !

<p​lowsof:matrix.org> next meeting 2nd September monero-project/meta #886 , a new idea from xmrlovera to produce educational content awaiting feedback ccs.getmonero.org/ideas, so too is the hidden MR to take over dormant monero-php proposal, more info here repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/402

<t​rasherdk:monero.social> Will there be serious security reviews, or are we going to leave that to wordpress, the most hacked framework, in the history of the internet?

trasherdk: ? what do you mean exactly?

<h​ator:matrix.org> I always thought of the Monero project as a very privacy focused project for obvious reasons. Maybe you are right @Rucknium in that permissive licenses have been used before. It never even crossed my mind that that would be the case in a project like Monero. Then a great opportunity is lost now to rectify this flaw. It will weaken Monero, privacy first does not seem to go here. I <clipped message>

<h​ator:matrix.org> can only congratulate the corporate lobby for pushing this decision through, job well done. And a warning to the people that depend on Monero because they need to stay out of sight of government, keep close eyes on developments in this project and take appropriate measures.

<r​ucknium:monero.social> hator: I don't understand what the license has to do with privacy. You and people like you use the threat of leaving to try to get your way like an abusive spouse.

permissive license allows proprietary companies to build "monero-compatible" apps that no outsider has the ability to review or verify

that in itself is a major red flag

one most monero devs have ignored sincethe beginning of the project

I opened a discussion on licensing a few years back but got massive pushback and gave up

the biggest reason given, not to change to copyleft, was that it would prevent proprietary companies from supporting Monero

frankly I think we should have told any proprietary companies affected in such a way to go to hell

we invested all this effort into creating reproducible builds for our software, but we let for-profit companies do whatever the hell they want, with zero possibility of oversight or recourse.

stupid shortsighted decisions.

<r​brunner7:monero.social> Frankly, if you ask me, if both types of licenses - permissive and copyleft - are still around, and are still chosen for brand-new projects, after all those years, after so many things happened, and so many experiences were gained, that wants to tell us something: Neither of the two is decidedly, unequivocally, unmistakenly better, and the other is only still alive because of dumb<clipped message>

<r​brunner7:monero.social> people and inertia. They have, like almost everything and anything, trade-offs, both of them. What is "stupid" and "shortsighted" from your point of view, is - quite obviously, IMHO - not stupid at all from the viewpoint of other people.

<r​brunner7:monero.social> Stupid is, for me, to assume otherwise.

from the viewpoint of developers in an open source community, allowing your work to be explouted by closed-source companies is stupid. self-defeating.

and breaks any kind of trustworthiness one might otherwise build up.

<r​brunner7:monero.social> I didn't expect to sway you :)

the only reason the free software movement got diluted into foss / floss was because proprietary companies wanted to benefit from all that software without having to give anything back. period.

"open source" is a scam, at its core.

"free software" / copyleft is the only thing that actually protects developers' rights

this conv is particularly relevant for Monero, where we routinely preach that price and profit don't matter. where we scoff at bitcoiners' "NGU" obsession.

because permissive licenses are for the benefit of for-profit enterprises.

and that's in direct opposition to what we claim as one of our core principles.

if the monero rust project were to stick with (A)GPLv3 I'd endorse it.

<4​rkal:matrix.org> If the general ethos of monero remains don't trust closed source software I don't really see a problem. Proprietary shitpost apps can't exist if no one uses them.

and yet there are many closed source wallets out there

<4​rkal:matrix.org> Why didn't it?

and ignorant newcomers who don't know better which wallet to choose

<r​brunner7:monero.social> You only get only *so* far by calling people left and right ignorant and stupid, if you ask me.

"ignorant newcomers" isn't an insult. it's just what is.

competent developers choosing to allow their work to be exploited - yeah that's stupid.

note that the majority of monero devs had no choice, the license was set before they began working with the project

<r​brunner7:monero.social> I just took the first article about open source licenses that Google threw at me, and there I see that more than half of all "open source" programmers worldwide are stupid. And you know what? Their numbers are even growing. mend.io/blog/open-source-licenses-trends-and-predictions

LOL

that's a meaningless argument.

more than half of all "crypto" people use bitcoin.

<r​brunner7:monero.social> Those are all ignorant, yeah?

being in majority doesn't make them right.

if you define intelligence or correctness by majorities we all may as well just quit here.

<r​brunner7:monero.social> If you frame it with "right" and "wrong", you are already on a bad track, IMHO.

good/bad, better/worse

you can't avoid those angles

<r​brunner7:monero.social> Sometimes things are so complex, and multifaceted, that there is no "right" nor "wrong", just different viewpoints, that you shouldn't just declare "invalid" somehow to exclude half of all people.

again - if the majority are more valid, then we're all just wasting our time here and can just go away

<k​inghat:matrix.org> isnt that like saying volunteering your time and work for charity is stupid because youre not getting anything in return?

kinghat: no, that's saying volunteering your time and work for Elon Musk is stupid because he's already making a profit

Retro-active funding for Kayabas research into FCMP will reach a decision soon after this weekends meeting on saturday repo.getmonero.org/monero-project/c…als/-/merge_requests/403#note_22263

<k​inghat:matrix.org> those i give my time and work to also receive value. it doesnt have to be charity. you can volunteer your time and work anywhere.

Father luigi may just look at 9 up doots 0.down doots and merge so everyone is happy

<k​inghat:matrix.org> i get your point but i get my own value from giving away my time and work. i dont bother with what happens downstream. good(being used to aid or create new things) or bad(any liability). it stops there.

<k​inghat:matrix.org> i dont see how that is stupid if i consciously make that decision.

it's still stupid to give your energy to people who are already wealthy, vs to people who have less than you.

<1​23bob123:matrix.org> Tldr?

<b​oog900:monero.social> opened an issue to discuss the license: Cuprate/cuprate #26

<-​coffeeplease-:matrix.org> Please understand that my rand is not directly pointed at you @Rucknium. I’m not as much trying to “ get my way like an abusive spouse.” (I hate violence btw). I am trying to let you all think about what forces are driving the decisions and what the consequences of those decisions might be. I am worried sick and all I get are personal attacks.

<s​adlittlewannabesamurai> i think an alternative node would have more value being licensed under the GNU AGPL (called "AGPL-3" in the github post)

Reg multiple implementations in practice : monero-python , popular library. Had its own output detection code, critical bug, maintainer unreachable to patch it for a long time. Even now, i think it still doesnt check unlock time. In my eyes "rewrite monerod in rust" has already been rejected by the community, the consensus rules document i hope

provides value and maybe even notices something that results in PR's to monero-core (and not just serai-dex)

50% of.cuprates dev team os already unreachable

<1​23bob123:matrix.org> I’d be posting in the css proposal so its attached to the proposal.

The ccs proposal isnt for a rust node though , slander!.

<1​23bob123:matrix.org> I’ll use WD40 on it and it will be just a node

<s​ilverpill:poa.st> Could you clarify what you mean by "too restrictive" in the issue description?

<s​ilverpill:poa.st> (I agree with the statement, but it would be good to state explicitly what kind of behaviour is going to be restricted.)

<e​dge7:matrix.org> Just to understand, what are the main reasons for rebuilding monerod in rust? Rust memory safety or what? Cheers

<r​ucknium:monero.social> edge7: The proposal has a Why section: ccs.getmonero.org/proposals/boog_2_months_cuprate.html

<r​ucknium:monero.social> Does anyone have a complete view of the status of XMR<>BTC atomic swap projects? plowsof?

<r​ucknium:monero.social> COMIT: Unmaintained(?), has a GUI, and earlier version some reports of users getting funds stuck

<r​ucknium:monero.social> Farcaster: Just CLI(?) Not really in production form yet(?)

<r​ucknium:monero.social> Basic Swap: Claims to have atomic swaps working and user-friendly. Are they really atomic? Do they go through Basic Swap's token/coin?

<r​ucknium:monero.social> Any clue about transaction volumes?

Binarybaron releases some stats (actually just the other day released an update moving to RPC calls instead of talking to the cli swap client)

<r​ucknium:monero.social> plowsof: do you remember where?

I think they are specific to a "swap provider" .. im not aware of anyone (its possible?) Tracking atomic swaps on chain ( there is a bounty for this so its possible?) bounties.monero.social/posts/3/0-50…tter-bot-for-comit-btc-atomic-swaps

<r​ucknium:monero.social> Can you tell from the bitcoin script on chain?

<p​lowsof:matrix.org> #unstoppableswap:matrix.org room , (1 other swap provider shares stats sometimes also.. let me check)

<r​ucknium:monero.social> COMIT is being maintained again? Good.

<p​lowsof:matrix.org> E.g. someone posted their stats from may matrix.to/#/!hGgunYBCcqReUmQGNo:mat…rg&via=monero.social&via=sibnsk.net

<p​lowsof:matrix.org> Excuse the matrix link

<p​lowsof:matrix.org> binarybaron: can hopefully point us to some stats of his swap provider

<r​ucknium:monero.social> There's a proposal for BCH<>XMR atomic swaps. I'm trying to understand what's happening with BTC<>XMR atomic swaps so I can help the BCH devs: gitlab.com/0353F40E/cross-chain-swap-ves/-/blob/master/README.md

<r​ucknium:monero.social> ETH<>XMR atomic swaps are being bundled with PiNodeXMR now: reddit.com/r/Monero/comments/164tise/pinodexmr_adds_atomic_swaps_beta

<p​lowsof:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/mVibhHRjruGOplGcBxbDyCSG

<p​lowsof:matrix.org> twitter.com/UnstoppableSwap

<p​lowsof:matrix.org> .farcaster team are in #monero-swap:monero.social .. not much going on since the web interface was unveiled (btc to and from with farcaster at least unlike comit)

<p​lowsof:matrix.org> Is that room also bridged DataHoarder?

Can it be please* eventually it will be handy

<p​lowsof:matrix.org> I do not know.. great if true (on chain stats of successful / failed atomic swaps when)

<r​ucknium:monero.social> Not good for privacy if true. Taproot?

don't think so, plowsof

I'll look at it once I go through a rest cycle :)

<b​oog900:monero.social> If we go of the first proposal then yes that was rejected, but writing a Rust impl of the consensus rules part of this CCS was not hence I don't think "the community" as a whole rejects the idea of a Rust Monero node.

<b​oog900:monero.social> I am obviously biased and I may have missed discussion that you have seen but I think creating a Rust Monero node as seen quite a bit of support.

<b​oog900:monero.social> I can also point to an alternative implementation spotting problems with Monero: DangerousFreedom. Although the bug he found was not exploitable it was a bug non-the-less found by his python impl of Monero's crypto. Having an alternative node will extend this work allowing verification of Monero's consensus rules as well.

<b​oog900:monero.social> I do admit Cuprate will be experimental for a while so shouldn't be used (without also running monerod) in an environment in which it would be very bad to be on a "minority chain split".

<b​oog900:monero.social> I personally believe the benefits from an alt impl out way the cons but again I am biased :)

<s​omeoneelse495495:matrix.org> I can confirm

<r​ecanman:agoradesk.com> I am working on monerophp, not wordpress.

<r​ecanman:agoradesk.com> There are a couple of people who have been reviewing my PRs (one of them is serhack). Since this is a library, I think that the users of the library will check the input from the client, and not directly pass it to monerophp. I don't know about an official security audit though, and how much that would cost.

<k​ayabanerve:matrix.org> plowsof @plowsof:matrix.org: Hot take to your prior message on monero-python (unsure how many days ago it was, sorry)

<k​ayabanerve:matrix.org> Libraries SHOULDNT error on unlock time.

<k​ayabanerve:matrix.org> Wallets should.

<k​ayabanerve:matrix.org> The most a library should do is a very explicit API around lock time, such as my own work does because I competently understood the issue.

<k​ayabanerve:matrix.org> That comment somewhat throws shade on the monero-python dev, who I assume didn't have such an API (and missed a prior crit) which I don't mean to do (as they clearly know enough to do a lot of Monero code), yet aims to highlight any project handling financials must have experts. To take a project which didn't have an expert, and use that as a black mark on a concept, is unfair and manipulative.

<k​ayabanerve:matrix.org> In addition to boog's comment on DF's work:

<k​ayabanerve:matrix.org> I think I wrote on a Reddit comment I linked here how boog's proposal can be seem as extension of DF's work. I can also confirm monero-serai was used to find a (believed to be) prior unknown invalid TX on-chain (it did not mint funds, and it arguably wasn't invalid as it made it on-chain, yet mooo suggested it be banned in the next hard fork. Planning to release it at trivia 👀)

<k​ayabanerve:matrix.org> And then I believe DF also used monero-serai to verify BPs (they at least added code for that purpose), and then I took my BP+ impl intended for FCMPs and integrated that into monero-serai. I'm running it against the chain now, effectively confirming that Monero's BP+ impl matches the paper and clearly showing implementation-specific details.

<k​ayabanerve:matrix.org> Alternative impls have found several pieces of bad behavior. Anyone against work on alternative impls either doesn't understand the value of an well-understood and demonstrably-intact network, or doesn't care.

<k​ayabanerve:matrix.org> (Deployment of alt impls as nodes being a separate discussion)

having some short downtime, to prevent longer downtime

and it's all back

<p​lowsof:matrix.org> Iirc i had to make the PR myself to python lib to fix the output detection (jberman held my hand as i dont know what i was doing) the python dev eventually appeared and got to work

<p​lowsof:matrix.org> Jberman contacted him to help fix it