So you want to build a GUI in Zcash or a derivative

Zcash Apps
1

A few people have DMd me asking how they might get started building a GUI. A bunch of people DMd me saying they’d be interested in working for pay on it with the foundation (thats up to the new board when its finalized).

I figured it might be interesting to get a brain dump of what it takes to build a Zcash GUI. One side of this will be the zcash bits. Those are actually simple, no crypto needed. The other side is the GUI bits. I’d love if people would add a sort of skeleton on how to get a GUI up and running in python/javascript/electron/QT etc just in general or better link to good resources. Obviously the holy grail is cross platform. The point of this thread isn’t for you to build it, just advance the community’s knowledge. I figure everyone would be interested in what it takes to get started and might want to share any incites they have.

Unfortunately, I’m not the person to tell you how to do any of this. I’m a cryptographer who has near zero-knowledge of GUI programing. So hopefully people will come in and correct this as we go.

The rough sketch is zcash as you know it is actually zcashd, a command line client that also supports a JSON RPC Api. See the docs. Zcashd handles all the cryptographic logic and the business logic for managing coins. So the only thing you need to do is create buttons that make calls to zcashs APIs and handle a few events about receiving a payment. Most languages will have libraries to do JSON RPC. You don’t need to do anything as ugly as call the command line yourself and parse responses.

So the quick getting started is to download zcash for your platform. Natively we support linux, there are also experimental OSX and Windows builds. You’d manually get it running and then write a standalone program that displayed a UX and made calls via that API. (obviously later you’d make them both start via launching the app and package it , yada yada)

You will probably want to start running on testnet and use the z-cash test-net faucet to get coins. Testnet is “fake” zcash, the money is not real and its there to play around with. You can also run your own local testnet via regtest=1.

Beyond that, you then need to actually build a GUI. Have some main function that launches, makes the initial JSON RPC calls, and then do your thing. No need to handle cryptography, networking, or anything.

6 Likes
2

Also, be sure to read the UX Checklist For Wallet Developers.

6 Likes
3

How about Electron https://electronjs.org/ assuming it used the JSON RPC API (not to be confused with Electrum!)

4

Here are some handy links to past Zcash ports/GUIs: (some depreciated)

https://github.com/radix42/winzec

There is potentially some “low hanging fruit” with a few wallets that support Zcash Forks like
GitHub - zcash-community/electrum-zec
GitHub - BTCPrivate-Legacy/electrum-btcp-legacy: BTCP Electrum (Lite Wallet), Use all wallets with caution. You should never share private keys, seed, or wallet file with anyone.
Releases · btcz/bitcoinz-wallet · GitHub
(Though the Electrum wallet still has a pretty terrible GUI)

And here is a SPV library by Guarda: GitHub - guardaco/zcash-SPV: Zcash Grant SPV library (Sapling)

Hopefully some of those links can start as a jumping point to get a proper native Zcash GUI built.

If we are serious about adoption we need the process of setting up and interacting with a Zcash wallet to be as simple as possible!

1 Like
5

Should work. There are some security concerns to be very careful with. https://twitter.com/durumcrustulum/status/1009165297037856768

The typical problem with Electron apps is people can send you content that the app tries to render and ends up executing javascript. So X This would come up with e.g. the memo field.
Would be safer to use Chrome as a standalone app. This is what Signal does.

1 Like
6

Can anyone point to a JSON GUI builder? All I could find was old stuff: GitHub - jdorn/json-editor: JSON Schema Based Editor
http://metawidget.org

Or new stuff (but in Chinese language): GitHub - duilib/duilib

7

I’ve never used it but just noticed that Decred’s cross-platform GUI wallet is built on Electron GitHub - decred/decrediton: Cross-platform GUI for Decred.. I’m not sure if there are others that anyone knows of?

1 Like
8

A simple tutorial on doing UX in JavaFX/Kotlin by Mike Hearn of all people. React’s TicTacToe tutorial, in Kotlin/JavaFX | by Mike Hearn | Mike’s blog

I really think it would be interesting to see a similar thing for zcash wallets. All the business logic is handled by zcashd. Aside from the pain of getting zcash up and running, it should be simple.

9

Hey thanks for the topic. I’ve been wondering about this off-and-on for a while now. Good to have these links to the testnet and faucet and the JSONRPC docs for Zcash. To add to this, while I’m not sure what exactly is in BTC 0.11.2 json-rpc and therefore Zcash:

https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)
https://blockchain.info/el/api/json_rpc_api

It would be nice if Zcash had a fully-curated json-rpc documentation so developers wouldn’t have to mentally merge the bitcoin docs (and then think about what version different things were added). It would be nice to have a one-stop shop for Zcash’s JSON-RPC functions.

Hrm. Seems like this would be easily avoidable by not requesting external content from the app?

[… spends 5 minutes Googling and reading up on the issue …]

So, I see things like Electron is insecure before update to Chrome 50 · Issue #5210 · electron/electron · GitHub …

I think that if you check-in all of your assets and never request 3rd-party JavaScript and Images you should be fine…

OTOH as I survey the landscape, I think that one of the best/easiest ways to build a cross-platform app would be using react native and proton which obviates the need for electron, apparently. Proton Native - React Native for the desktop, cross compatible

I’ll try to stand up a little hello world boilerplate that can talk to a full node … (from iPhone, Android or Desktop)

1 Like
10

In zcash, the only time it should come up is if you render the memo field. Thats arbitrary user provided content. The moral equivalent of a payment with memo: < script>alert(“pwnded”) would probably cause issues.

Effectively memos are a third party assets. This can be guarded against

2 Likes
11

Take a look at this. It’s automatically generated from the zcashd client https://zcash-rpc.github.io/

The Zcash specific stuff is also well documented here: Zcash Payment API — Zcash Documentation 5.2.0 documentation

1 Like
12

Perfect, thanks. After some more reading, I’m not that keen on proton (I really would like to write react native and then have it also work on desktop from the same codebase). This looks promising though: GitHub - status-im/react-native-desktop-qt: A Desktop port of React Native, driven by Qt, forked from Canonical

1 Like
13

The JSON-RPC piece turns out to be super-simple. I think this is an under-appreciated library right now. Seems to work great for Zcash:

2 Likes
14

Just barely getting started. But here is a skeleton with:

  • react-native (react-native-macos)
  • yarn workspaces
  • redux
  • stdrpc

At this point, it can store your username/password and talk to the local zcashd. It’s almost all skeleton and no meat. Maybe someone can help me mash out the rest. I’ve mostly been working on the code organization and the developer workflow :wink:

04%20PM
04%20PM1612×1064 111 KB

2 Likes
15

What kind of help do you need @skyl ? I can do graphic design but am not familiar with the back end stuff.

For the front end there are some good off-the-shelf UX/UI elements Antiqueruby React Native Material Design UI Components by aliansoftware
I would be willing to purchase a license for us to use if you think it would work/save time.

16

I’m a build/devops/backend/full-stack guy who can do some stuff on the frontend. I’m mostly concentrated on build systems, developer workflows and scaling development teams in my day-to-day work.

My first goal with react-native-zcash-wallet (I might take off the -wallet) is to make the codebase modular so that we can build multiple applications from the same repository with common reusable core/component libraries. This way we can put together different applications fairly easily and the application harnesses can be somewhat lightweight and disposable. There are a lot of potential advantages to this approach. For instance, there are different boilerplates, bundlers, build systems, libraries and on and on and the ecosystem is constantly evolving. Instead of having 1 application and having to do experiments in branches or having to overhaul a single monolith to try to upgrade to a new boilerplate/lib/whatever, we can just add a new application and have access to the same component libraries to compose together in a different way. So, most of the code should live in eg core/ or components/ and should be pretty agnostic to how an application will configure itself. This way we don’t have to make too many decisions upfront or have decisions that have wide impact on the rest of the codebase. By using small, modular components and multiple apps, we should be able to have more people working in parallel without stepping on each other. We can also have different applications for different use cases:

  • A lightweight wallet that does the absolute minimum for send/receive
  • A power-user interface that can do everything the command line can do
  • An app that teaches you about the network/blockchain, gets all of the network data and has links to learning resources about those different terms and aspects
  • SPV mobile wallet …
  • Block explorer …

Right now I have 2 applications, 1 application with create-react-native-app that uses Expo and 1 application that uses react-native-macos (those 2 things don’t yet go together too well in the same application):

We could try something like the UX/UI elements you linked to, I’m open to that. My first target personally is OSX, so things are a little different on react-native-macos compared to the ios/android.

In terms of help: wireframes, drawings, specs and stuff are always good. Styling help would be awesome. Any color I choose will be at random … padding, rounded corners, themes, layouts … I plan to spend a minimal amount of time on that stuff myself. But, I hope to have it teed up so that someone who is really good at style/design/visual can just come and hit a homerun. Now that I have a couple of applications that can import components, I could use help just banging out those components - I only have a couple. But, I think I have a decent pattern carved out:

this component uses this call: getblock - Zcash 4.5.1-1 RPC Docs

The stdrpc library makes talking to local zcashd trivial. So, I’m going to bang out a few of these one-to-one-component-to-rpc-call components for a while and see where that takes me.

17

How is this GUI project going?

The UX checklist is a great place to start.

@skyl it sounds like you can contribute a lot on the dev side, but you need the right design partner for the project.

Here are three suggestions:

  1. Find a professional ux/ui designer to lead design at Zcash. It will be worth it.
  2. If you can, go native and avoid cross-platform. Learn why here.
  3. Take on GUI one project at a time. I would go for your top platform / application first, and make that awesome vs. trying to do everything at once.

@secparam hope that helps.

1 Like
18

How about Electron https://electronjs.org/

The problem with Electron is every single Electron app includes the entire Chromium browser inside of it. This causes the program to be huge and drain resources faster. If you’re running Slack and Atom concurrently then you’re already running two Electron apps. The more of them you add the worse the user experience becomes.

I just wanted to add that user experience has been the largest hurdle to adoption. Other coins often punt this to businesses to develop, but then you end up with a bunch of required middlemen to facilitate user adoption. In my mind that hurts the case for crypto in general. If Zcash can make strides in making adoption easy, clear and secure/opaque by default then Zcash will soar.

3 Likes
19

I haven’t been able to work on react-native-zcash in a few days but I do have an ugly UI running on OSX that I can look at my balance, send coins, and check a few network stats with. I don’t have any SPV functionality yet - the UI expects a full node running locally at the moment and uses the really good stdrpc library to make talking to the full node trivial. I have started a zcash-redux library that makes retrieving/using/modifying state pretty easy/nice.

21%20AM
21%20AM769×461 33.7 KB

I’m fairly well versed in the pains of react-native and am experiencing plenty right now :smiley:. Currently I’m trying to maximize platform-agnosticism and setup Storybook so that individual components and combinations of components can be developed outside of the context of any application. I’m trying to push as much of the code as possible into the stateless-doesn’t-know-anything-about-the-application bucket. On paper I’m in love with this idea. But, in practice, I’m dealing with a lot of pain. For starters, react-native-macos doesn’t support selectable on a Text node and the workaround is to use TextInput which doesn’t look good on a phone. This is a pretty big problem that shows itself at my barely-more-than-hello-world level of sophistication. But, I feel the ecosystem will be aggressively tackling problems like this in the near future. Note that Microsoft recently took over react-native-windows. This is part of the reason I want to develop the components and core libraries in relative isolation - when better application patterns/harnesses/boilerplates come around, the deprecated applications can be thrown away without much regret.

Another problem I’m experiencing is my stubborn insistence on using yarn workspaces to share code in a monorepo. I really love yarn workspaces. But, unfortunately, many many pieces in the react-native world expect the application to stand alone, have hard-coded paths in the application’s node_modules directory, do not use the root node_modules directory that yarn hoists dependencies to, do not use symlinks … Again, this is a class of problems that I think will be more thoroughly solved in the next several months by the react-native community. But, as an early adopter of this type of code organization I’m having plenty of problems getting it setup. I’m probably going to give up on yarn workspaces for now (maybe wait until the tooling comes around) and use local file: dependencies between packages in the monorepo. This way each application will make it’s own node_modules without symlinks…

ANYWAYS … you can see that I’m pretty deep into the weeds of things that don’t have that much to do with the OP. Sorry about that :smiley:

Regarding full native versus react-native.

If you can, go native and avoid cross-platform. Learn why here.

If someone wants to go full-bore making a native android or native ios or native whatever UI, I’m all for it. But, I don’t think that AirBnB’s experience of trying to start with React Native in 2016 and add it to their existing large mobile apps is comparable to starting from scratch today with Zcash components. I read all five parts from your link and agree with pretty much everything said in those posts. But, note this interesting tidbit:

29%20PM
29%20PM1480×1066 74.3 KB

React native is pretty swell and it’s evolving rapidly. But, I’m biased - my skills are pretty much limited to Python, JavaScript, Go, Ruby … Java and ObjC are way down my list of languages that I like and have experience in. I think there are more devs out there like me who might be able to contribute to a family of react-native apps than a single-platform native app. Since these devs might be relatively low-quality like me :wink:, I’m hoping to setup a good build system that can enforce healthy practices and scale to many mediocre developers (and possibly also provide entry-points for creative non-developers to contribute via things like Storybook). … IDK, we’ll see. But, it suffices to say that I’m pretty excited about the prospects and thanks to @secparam for getting the conversation going.

4 Likes
20

This is awesome work. I really like the idea of building a sort of wallet playground where people can write there own UX and " scale to many mediocre developers." This provides a nice way for any wallet done by the foundation/company not being the only one. Effectively its a very well done skin.

In my utterly not expert opinion, I think react native is fine. I saw the AirBNB blog, but the wallet is not nearly as complicated as airbnb. And even if its slightly non native UX, for starters we just want to beat existing crypto currency wallets. Finally, its accessible to developers and saves work. The foundation/company could pay to support native apps on windows/OSX/android/IOS. But if the goal is eventually to decentralize the ecosystem for development, the lower the resource requirements in maintaining it, the better.

4 Likes