Client Development - Fall 2023 #2483
Comments
|
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 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. |
|
What I'd call "delegated transaction signing" would definitely be a challenge, and may be impossible without a trusted party, but all other scenarios are just your own instance of dexc running on a remote server, so you would still be signing your own transactions. It would just allow you the freedom to shut down your client app whenever you wanted without risking penalty or having your order revoked. There are a couple of UX roadblocks I'm looking to solve.
I think either of these alone might be debilitating for adoption in the face of other options. I can download Exodus wallet and use it virtually right away. I can create an account on Coinbase, go through all of their KYC/AML process, and be trading in like 15 minutes; faster than syncing our SPV wallets. When I look at those options, I see immense risks to privacy and security, but many or most others probably just see a smoother experience.
Hmm. What would be the difference?
Feel free to suggest goals that you find important. Aside from what's listed, you can always update docs and review code. Reach out on Element if you're not sure. |
Just light wallets and trading, and just a library I suppose. In my mind you need to |
|
Just personal opinion, integrating new tokens/blockchains (along with simple UI to browse those) would make the most impact in terms of DEX adoption. In particular Solana seems to be primed for winning "peoples chain" race, and interestingly there are decent chances it's decentralized enough (compared to what most people who did not spend much time analysing/comparing think of it). |
We can always come up with a sleeker UI for the settings page but it proly won't blend with the other pages, I think. |
This is a bit boring compared to features mentioned above but I'd invest in release management and onboarding flows. 1. Make the release process documented (at least privately) and strict to not miss any steps, so that when we announce the release on Twitter/Telegram/etc. all docs, links, and packages would be up-to-date. Moving all docs in the main repo was a great step to avoid "the dcrdocs mistake" (no clear ownership => stuff is always outdated). But there is more work to do, e.g. v0.6.3 was in half-baked state for several weeks and we weren't sure if it's ready for ANN. Now most of the steps are done but AUR packages, asset list in website footer, and now Decrediton v1.8.0 links are still outdated. Going forward the app will commit to more OS Packages (which would be great for adoption!) and we will have more stuff to forget about. Release routine is not fun but chaos tends to spread if not addressed. If it helps I can submit a release checklist template based on the steps above. 2. Streamline and simplify onboarding flows. Choices and navigation are hard for newcomers. Eliminate unnecessary choices and guide through remaining choices. Pay attention to what newcomers complain about, record it, and fix any issues. Imagine where non-devs and non-sysadmins would get stuck (or better, hire them to test UX and report the pains). Example areas to improve:
3. Reproducible builds. Explore if it's possible to piggyback on existing build infra in the release tool and achieve reproducible builds for DCRDEX. |
|
@xaur I'd really like to deputize you for coordinating releases. Up for the job? |
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. auth: v2 ConnectResult #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.
all wallet keys are generated and stored on the server. That doesn't work at this scale, so we'll need clients to be
able to handle private key operations. It's not as simple as the dexc server offering access to full nodes. The user's
dexc instance (or equivalent) still needs to run on the server to accomplish the goal of offloading. There's a needle to thread
here to optimize privacy. Something like "remote signing", with a solution for the need for server-led trade settlement without a connected client.
🌟 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.
The text was updated successfully, but these errors were encountered: