Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[META] Wallet Roadmap #11

yeastplume opened this Issue Mar 8, 2019 · 2 comments


None yet
3 participants
Copy link

yeastplume commented Mar 8, 2019

Just a few thoughts on where I think core wallet development should be heading over the next while, roughly in order of when I think they should happen. Obviously all open for discussion, but I'd like to keep everyone working on the wallet on roughly the same page:

  • Misc additions to the Owner and Foreign APIs, such as 'invoicing' (payee initiated transactions,) and other enhancements that can be added over time.
  • v2 API Started here: #2 but will shortly become a meta-issue with several chunks of work that need doing. The main idea with the v2 API is to ensure JSONRPC stubs and documentation can be generated directly from the core rust APIs, to minimize the overhead in maintaining them and ensuring changes will be picked up as automatically as possible. Also this work should result in fewer bugs in the future due to differing code paths to call the same APIS. For instance. For instance the command line client currently links the rust structs directly while the current http client has manually-written stubs exposed that behave slightly differently from the command line. It's hoped that all consumers of the v2 interface will use the exact same interface, the only difference being the version of the generated stubs that are called.
  • API clients Following from above, it should be possible to automatically generate clients that call the v2 JSON RPC api, (javascript being an obvious target).
  • Integration Test suite with the v2 API in place, we need a comprehensive test suite calling JSONRPC directly and exactly how real clients would be doing it. There is already a start of a testing framework in place that simulates wallet to chain and wallet-to-wallet communication in-process, without having to open ports are the like. This needs to be extended a bit and tests written directly against the V2 API.
  • Persistent process command-line wallet or whatever you want to call this. At the moment the command line wallet lives for as long as it takes to execute a command. It should really behave more like wallet713 by default, whereby you start a wallet session and enter commands in its own command line. This version of the command line client should also use the v2 API via JSONRPC instead of linking directly, again to minimize the number of different code paths accessing the API.

This comment has been minimized.

Copy link

garyyu commented Mar 8, 2019

All good above.
And I would like to second the “invoice” feature, and add two more:

  1. give high priority for the Provable Tx feature (mimblewimble/grin#2652)
  2. and wallet performance improvement.

This comment has been minimized.

Copy link

akatasonov commented Mar 18, 2019

@yeastplume Hi Michael! Great work! I'm starting on a project for a mobile (both iOS and Android) wallet for Grin. Didn't know grin-wallet existed as I was mainly messing around with the node/wallet code trying to turn that into a lib.
What would be the best way to approach this problem? Does grin-wallet require a full node to connect to?
Also, do you see benefits in having a node running as part of a wallet?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.