Add Monero Formula

[c0mmando]

Commitment

I confirm that I have read the following resources:

• How to contribute to Qusal
• How Qusal is designed
• How to ask questions The Smart Way
• Writing the perfect question
• Question checklist
• Could you please make my preference the default?

Current problem (if any)

I'm curious why Monero formulas are not in qusal considering unman's implementation at https://github.com/unman/shaker/tree/main/monero

Proposed solution

Add Monero Formulas

The value to a user, and who that user might be

Any Qubes user should probably be using a privacy coin like Monero. The value add is privacy and financial sovereignty.

[ben-grande]

I'm curious why Monero formulas are not in qusal considering unman's implementation at https://github.com/unman/shaker/tree/main/monero

I don't plan to have 1:1 parity with Shaker. From a quick look, Qusal doesn't have i2p, ids and monero, not for any reason specific to any of them, but I preferred to focus on other projects.

Ok, but isn't it useful? Yes it is, but it is also time consuming on my end. Doing the sys-bitcoin formula was a journey in itself and I believe adding a monero formula would take the same amount of work (at minimum a full week) (I spread the making of the bitcoin formulas, including the electrum servers and client for ~3 months, non consecutive days, just counting from the first starting point till the first commit).

Shaker formula doesn't work anymore as Whonix doesn't package monero anymore and the current documentation suggests to use Flatpak, which I am reluctant to use as it is a trouble to update on offline qubes, if I give a binary installation option, it would be from the official site. Build from source code option also needs to exist and this can take some time for testing due to build times.

After build or installation from binary is complete, I have to take a look at the manual to see which options should be adjusted, this can also take some time to study, test and deploy. There may also be optional configuration for different use cases, depending if user wants to share the node or not.

I'd do it for a bounty, problem is with every formula I add, I try to keep strictly up-to-date (no more than a week) after upstream releases, so adding a new formula that requires testing on every update can be a burden on the maintainer (mostly because there is no build in CI for Qusal and I don't have powerful computers to serve to fast builds (more RAM and CPU needed). So, a bounty doesn't cover those costs, only recurring payments does.

Patrick Schleizer (Whonix maintainer) did receive payments to package Monero and when the contract was not renewed and the package was dropped from Whonix, many people complained, as if it was Whonix fault. I don't want to drop a package, but if I need to do so because I don't have resources to maintain, I will surely drop a package also instead of leaving users with outdated and possibly vulnerable versions, if users come to complain that their formula is not supported anymore, would it be a lack of their support to the future of Qusal or a lack of Qusal doing good deeds even if burdening the project itself?

Do you have a proposal to contribute to Monero formula builds and testing over a long period such as months and years? I can't rely on someone that will disappear and not keep in touch. Trust can be earned over time contributing to Qusal when possible. But money I understand is not everyone can dispose off, so contribution is always appreciated but it doesn't pay all the maintenance costs.

Any Qubes user should probably be using a privacy coin like Monero. The value add is privacy and financial sovereignty.

I think people mistake Qubes for being privacy focused while it is strictly security focused, but I understand that privacy can only come if there is security. I think the added value for Qusal use case is: added isolation between monero daemon, monero wallet, monero gateway (tor via Whonix) and host computer (QubesOS). Privacy is only possible because those security features are true, if the host computer of the monero gateway are insecure and compromised, there is no privacy.

[ben-grande]

The Monero CCS is not a good source to rely on due to hacks, from a source controlled by monero maintainers, that lost access to the community funds. What will they do in the future to prevent malicious actors from stealing the maintainers PGP keys and produce signed releases to be uploaded? Will they increase their machines security? Will they upload a package that can compromise user fund? This is all questions that should be asked. Are my assumptions correct on this matter?

While the Bitcoin binaries hashes are signed by multiple parties, the Monero hashes are signed by a single entity. This is not a good practice, if builds are reproducible, why aren't more developers signing so I can have a root of trust spread across different entities?

Maintaining a Monero formula is certainly more work than maintaining the Bitcoin formula, as Monero hard-forks used to be common at least till 2022, if I don't upgrade the fetched version in time, on non-contentious hard-forks, user funds will "disappear" until they upgrade the node, which can lead to claims of "stolen funds, where are they?". Sure, the same can happens on a normal day even with Bitcoin when the node fails to synchronize and the wallet doesn't show funds, still, who are the users going to blame? The P2P network, the computer, the wallet, the formula?

For more information to understand why dealing with archives instead of packages from distributions is difficult, there is a quick summary of the work necessary to be done on upgrades in the design documentation.

[c0mmando]

Thank you for the clarification. I wasn't aware of the issues with shaker and whonix. Until things change, it's probably best that monero qubes are individually maintained by users. If enough users are interested, reoccurring payments may be a viable option to support the necessary work. If anyone else is interested in pooling contributions for this effort, please reach out.

[tlaurion]

If anyone else is interested in pooling contributions for this effort, please reach out.

@c0mmando when where how?