JoeGruffins
commented
1 year ago On mobile, I feel like maybe a lightweight client makes the most sense. The user needs to be ready to sign swap transactions when it's time, so hard to imagine a service having much to do? Unless you let the service sign for you... but that would be going against what we are trying to make imo. Unless there is a way to make a tx that says this amount can only be traded in this way and pre sign it. Probably doable with an eth contract but can't imagine how to with utxo. Then client also needs to be partially aware of what's going on in order to refund if the service went offline.
On offloading, the first option is already doable! I am doing that within my home network and it works well. Refining that process, even if it's just writing a readme would not be much work. Hard to imagine what The collective would look like. As I said above, how much does The service really add? If we are only talking about trading, the key holder has to be ready and aware anyway. I guess if there are a lot of extra things added? Maybe a light version with only trading basics and a loaded version should be buildable if the goal of a service is mobile trading?
Monero, lets do it. Cake Wallet has a lightweight version that works on mobile even. The build process is involved but I think it gives us something working to emulate/copy.
On current proposal, anything you want me to focus on? Staking is to the UI part that I think you are hammering out. If no suggestions nothing really jumps out at me but I'll pick something and ask if that's alright to work on.
buck54321
norwnd
ukane-philemon
xaur
As we move into the future of client development, this working draft of a task list can be used for coordination.
Please comment below to help me add or remove items, clarify direction, improve language, etc.
I expect we will have sufficient discretionary funding to expand the first section below. What can I add?
Targets for funding in current proposal
There are a number of initiatives that could be funded under the current client dev proposal.
Features and new assets
Fiat onboarding. Something like stripe embedded in our front end. But maybe not stripe, if I understand their docs correctly.
Custom tokens (prototyped, see @buck54321). These tokens would lack gas tables and other info, so could not be used for trading.
Figure out Zcash. zcashd JSON API is unusable. Solutions proposed, but devs are slow to respond. Can we work around it?
Zclassic. Will be a ShieldedWallet.
Arbitrum (in-progress, @buck54321).
UI Development
Transaction history. Goal: Leave core out of it. Approach: Start with an
asset.WalletHistorianinterface and add assets one-at-a-time.Bonds UI. User's should have access to many more details when settings or updating bond preferences.
Reputation. I want to know what the server thinks of me. #2471 is a step in this direction.
Wallet view. We need to iterate. Our typical desktop wallets view for an asset looks like this
. It's a three-column layout that changes into a two-wide grid at medium widths and a single column layout at mobile widths. 
. At desktop widths, the middle and right pane are underutilized. The nice thing about the three-column though is that the columns are width-limited and so force layouts that degrade nicely to mobile. On the other hand, it creates dead space and assigns a lot of real estate to relatively unimportant information. So the way I see it then, our best approach is to add more relevant information in these areas. Maybe we can add a tabbed section to the middle column that switches between a handlful of different data views, including transaction history from above. Could we add a market-making summary here too? How can we improve the active trades section? Wide open to suggestions here.
Settings view and server configuration dialog. These views are very rudimentary and have never undergone any serious design consideration. While that's good because it keeps maintenance and design costs low, it's bad because it look like crap. Let's upgrade.
🌕 Moon shots / Proposals needed
🌟 Asset features
Dash Staking
Firo privacy
MimbleWimble on Litecoin. ltcsuite doesn't support it, so we'd be doing a lot of work one way or another. Whether it would be "easy" or even possible might depend on if and how they commit extension block i/o to their block filters and whether we can sync history without a full node.
Stacks, BRC-20 on Bitcoin
CashTokens on Bitcoin Cash
Expose accounts for UTXO assets. Give users control over creating account and maybe even selecting particular accounts for trading on an order-by-order basis.
🌟 Browser extension
I've prototyped a browser extension that connects to an instance of dexc. Why though?
🌟 Lightning network integration
Bitcoin and Decred. Start with some basic channel management. Add features like Bison Relay and Taproot Assets. One target is a Bison Relay-backed trollbox on DEX markets.
🌟 Monero wallet
I think we should figure out how to do a Monero wallet, but not for trading at first. The community loves Monero, and implementing a wallet will prepare us for adding a Monero trading protocol to DEX. I'm open to allocating substantial efforts towards wallet development to make a native light wallet work.
🌟 Point-of-sale system
This could be an entirely new front end to our current client stack. It could also be a view in our existing app, but a dedicated front end has advantages in terms of marketability, as it can be packaged into a dedicated, single-purpose app.
🌟 Offloading client management
How can we facilitate offloading of time-sensitive and resource-intensive processes? Can we unburden the user of responsibility for 1) blockchain syncing, 2) trade settlement, 3) lightning channel policing, etc. I think we can. I see future development along these tracks as progressing through series of larger and larger target markets, each with solutions that have unique security and privacy tradeoffs. These are all variations of what I'll call below the remote dexc server.
The hacker. Our initial target is tech-savvy. This mode is just administration of a dexc instance on a remote server. In this operating mode, the user opts for built-in SPV wallets, as these wallets minimize sync times, networking, and storage requirements. You can already do this, of course. You just gotta get a static IP and some bandwidth. Maybe add a little nginx for TLS.
The collective. Really, our full-node RPC wallets are our best wallets, assuming we have access to a synced trusted full node. If we have to run the full node ourselves, it's probably not worth the costs. But if we can share the duties of server/node administration among a group, then at some group size the economics of it start to make sense. For hosting of remote dexc clients you could have an efficient system in which a large number of clients can run with relatively low resource utilization. The collective model requires a fair amount of meat-space coordination. Members have to secure server space and access to full nodes. While the administrative work load is, ideally, distributed among all members, in reality, most work will be done by a few. So, especially for larger groups, the incentives are not well-aligned. This likely limits this mode of operation to small groups of dedicated members.
The service. We build off of the collective model by introducing paid administration. In this model, access to the remote dexc server is paywalled, but there is an increased expectation of uptime and customer service.
🌟 Ticket splitting and DEX mesh role expansion?
Could DEX somehow facilitate P2P ticket splitting? If we have a healthy DEX network, it seems like a great place to coordinate between participants. What other services could the DEX network facilitate. Lightning watchtowers? Mixing? Can the DEX mesh provide auxiliary services while maintaining a limited role in administration of said services? Can DEX's reputation tracking system be used more widely?
🌟 Mobile wallet?
Some questions persist. @itswisdomagain thinks we can do it.
My personal view is that even SPV wallets are gonna be finnicky and at-times resource intensive for mobile. I think a better overall solution would come from the Offloading Client Management roadmap above, in which case the mobile app could be basically a targeted browser window. Webview or whatever.