xiphon part-time coding
What
Would love to prolong my part time Monero coding for another 3 months.
There are a couple of specific tasks i would like to work on first.
- Improve automatic public node selection algorithm used in
Simple mode(---bootstrap-daemon-address auto).
Currently we use first iteration of the algo and according to the users' reports there is a room for improvement. - Implement update downloading and verification functionality in Monero GUI.
There is standalone monero-update tool already.
Integrating the tool into Monero GUI is the next logical step forward, i.e. downloading and verification new update binaries just in one click. - Focus on Monero daemon performance and stability.
I plan to do monerod cpu/memory profiling to investigate possible bottlenecks/weak places, implement appropriate optimizations/fixes based on the profiling results.
As usual will be working on Monero Core and Monero GUI code:
- Inspecting and implementing outstanding feature requests
- Submitting bug fixes
- New functinality
- Addressing ongoing issues
- Code review
- Putting my efforts where it is appropriate
Who
I'm Xiphon, active contributor to Monero Core and Monero GUI since July 2018.
My previously completed CCS proposals:
During the recent 20h/week proposal i focused on fixing ongoing issues, sumbitted numerous bug fixes and improvements to both Monero GUI and Monero Core repositories.
I strongly encourage you to visit the following Github links to see the amount of work done by me, its quality and importabnce for the Monero Project.
Please check the following links to inspect my Monero-related activity:
- Monero Core - https://github.com/monero-project/monero/pulls?q=is%3Apr+author%3Axiphon
- Monero GUI - https://github.com/monero-project/monero-gui/pulls?q=is%3Apr+author%3Axiphon
Proposal
Looking forward to coding and accomplishing mentioned and ongoing tasks and issues. Implementing new code/functionality that will be needed. Investigating bug reports and submitting bug fixes, fixing build and compilations errors/warnings/etc. Would like to inspect and complete/fix/address issues and feature requests that are reasonably desired and/or worth to spend time on. Improving GUI, fixing UI/UX issues, implementing design changes.
Dedicate 30 hours per week to Monero Project, at 55 USD/hour rate for a total of 307 XMR. XMR/USD rate is based on the 14-day moving average exponential on Kraken from 29 Jan 2020, which is approximately 64.43 XMR/USD.
Merge request reports
Activity
I see some pitfalls with i2p-zero bundling and am yet not sure Monero is ready for it:
- Does this work well with GUI reproducible builds?
- Does i2p-zero support reproducible builds?
- Are we okay to bundle third-party binaries (to trust Oracle and bundle java vm binaries)?
Think implementing socks5 proxy support is a more natural step in the current situation. Is already implemented in the wallet's code, but is not yet implemented on the daemon's side, i.e. there is no way at the moment to force Monero daemon to connect to p2p clearnet nodes through user-defined socks5 proxy.
Once we get this done, to proxify all Monero traffic through tor, a user would need to just run local
tor/Tor Browserinstance and then enable socks5 proxy option in the GUI.That said I would like to add this to the task list if such functionality is desired.
-
Qouting @sgp's Reddit comment:
We're getting into personal opinion territory here, but I absolutely think it's critical for good UX to bundle it directly. Having users install something else isn't going to work. Arguments about keeping the dependencies "pure" should be reserved for the CLI.
First, I'm not that against i2p bundling.
I agree that bundling i2p will benefit GUI users with a better UX. Though i personally, as a user, would be pretty happy with just socks5 proxy support.
Regarding GUI reproducible builds, i guess it might not be a problem if we harden bundled i2p-zero and java vm version.
But still, is Monero ready for it? Do we have any i2p seed nodes to connect to?
Also necessary to meet consensus among the community on bundling third-party i2p-zero and Oracle's java vm binaries into GUI releases. Monero people were very strict on that matter recently.
I see some pitfalls with i2p-zero bundling and am yet not sure Monero is ready for it
The latest work beng done was not so much about "bundling", rather configuring.
Does this work well with GUI reproducible builds?
Given that there isn't reproducible builds yet for the GUI, I'm not sure of the relevance.
Does i2p-zero support reproducible builds?
There is no reason I can see that it wouldn't, but again, I don't imagine it being bundled with the GUI anyway.
Are we okay to bundle third-party binaries (to trust Oracle and bundle java vm binaries)?
I suggest you take some time to look at the work dsc was doing on the integration. It's not about "bundling" i2p-zero with the Monero GUI, rather make it pluggable/configurable. Thus, if a user has it installed already, the GUI would be able to configure it with the daemon the GUI launches. I suppose there could also be a download and configure option.
Happy to chat more on IRC if this is something you're going to pick up in the GUI.
@jtgrassie see now we have different opinions, since I'd like it bundled directly :)
In any case, I think this discussion is off-topic for this specific CCS proposal. It may be part of the requirements, but I think it's safe to move without.
Not to expand the scope if possible activities into the impossible, but would it be possible to add investigating multisig (MMS) integration? At least laying out requirements for future GUI development in that area would be helpful. I am reviewing basic code implementation of multisig, so it may undergo large-scale revisions before stabilizing, which would be disruptive to an actual GUI update. See this spoiler.
-
investigating multisig (MMS) integration? At least laying out requirements for future GUI development in that area would be helpful.
Could you please elaborate?
it may undergo large-scale revisions before stabilizing
Does this mean
- multisig wallet/tx creation flow may be changed in the future
- multisig implementation is not stable yet
From what I understand there is no one working on, or planning to work on, adding multisig capabilities to the GUI wallet. It seems like integrating the MMS is the best path in that direction, since it already automates many of the underlying multisig wallet/tx creation flows, in particular connecting non-local wallets via PyBitmessage. Of course, whether the MMS is the best path is open to investigation (not something I am qualified to evaluate).
There is one minimum change to tx creation flow from the MRL paper (security-related update), and a number of potential quality-of-life creation flow changes. I believe most or all of those changes will be under the MMS hood, and won't have much of an effect on how the user interacts with it. Rbrunner is the MMS expert, although this is an area of active research (on my part anyway).
Edited by koe
@xiphon Please consider making your proposals more than a few days before you desire/intend to start work. I don't like this trend of paying for already completed work (not directed at you specifically), even if we aren't actually disallowing it as of now.
mentioned in commit 3a0123b1
mentioned in merge request !139 (merged)
mentioned in merge request !157 (merged)
mentioned in merge request !179 (merged)
mentioned in merge request !208 (merged)
