BUIP181: BU Mobile Wallet Project

BUIPs
1

BUIP181: BU Mobile Wallet Project
Submitted on 5th January 2022 by Singularity

Motivation

With BU creating its own new cryptocurrency I think it is extremely important that there is at least one easy-to-use mobile wallet for users of that network. Currently there exists Andrew Stones Walley Wallet which has advanced functionality but this could benefit from some work to make it more user friendly and modern.

Objectives

Research → Design → Implement → Document

Primary Objective

The primary objective of this project should be to produce a mobile wallet that:

  • Is secure.
  • works on both Android & iOS.
  • Has an easy-to-use UI of equivalent quality of the bitcoin.com wallet or better.
  • Have minimum viable features (a future BUIP can be used to expand the features further).
  • Makes use of the software libraries developed by Bitcoin Unlimited.
  • Connects to both BCH and NEXA blockchains.
  • Is open-source.

Secondary Objective

The secondary objective of this project should be to create the wallet in such a way that it acts as an example project for others wanting to create a wallet using Bitcoin Unlimited’s software. The project should produce a set of well documented software libraries that developers can use to make their own financial tools such as a wallet for BCH or NEXA.

Funding

Budget of $100,000 over a twelve-month period commencing from the date of vote. This funding will go towards hiring a small team to research, design, implement and document the wallet and associated libraries.

The elected BU officials: President, Secretary and Developer will jointly agree expenditures for this BUIP and will monitor progress through monthly reviews.

Expected Impact

This project will provide the BCH and NEXA ecosystems with a high quality secure wallet to store their assets. The project will also provide the libraries and documentation to support developers in creating their own financial tools for BCH and NEXA therefore helping to accelerate development of the ecosystem.

1 Like
2

I suggest prioritizing a JavaScript wallet as a Chrome and Firefox extension (Metamask style).

Able to do TX with a specific OP_RETURN and UTXO. To be implemented in systems like memo.cash, read.cash or BMP. Without exposing the private key.

And with the typical functions that Metamask already has like integration with hardware wallets and interaction with smart contracts (for SmartBCH and if NEXA has EVM).

This is what I need to make advanced web applications with the best usability out there. Interconnect web systems and blockchains. It is so good this strategy is called web3 and it is clearly the future.

You can build a mobile application if necessary by reusing the core JS of this extension.

This development is critical and decisive. I recommend trying to develop it jointly for NEXA and BCH. This requires joint funding and next level coordination.

2 Likes
3

Good idea, Paul. I would love to contribute (from an early stage) as a software architect.

I’m very hyped for this to pass and getting consensus on using kotlin multiplatform or: “Making the right tech choices”. These early tech decisions are super important now, and I think the “Kotlin/Native way” is the obvious best choice right now.

I think the architecture we should use is:

  • Kotlin/Native shared library
  • Client for each(any) platform

If we write the core business logic in Kotlin/Native using platform-neutral crypto software can be re-used across all platforms, including android, ios, mac, windows and Linux.

“works on both Android & iOS.”

→ I strongly recommend starting with one platform for the MVP stage and still keeping it multiplatform compatible, of course expanding when the MVP has landed on one platform.

“Have minimum viable features.”

→ Agreed! As minimal as possible

Re-using and building on code from VotePeer

The Android app-layer of VotePeer (https://voter.cash) is a wallet prototype. VotePeer can receive funds, and it supports mnemonic backups.

VotePeer uses mostly Kotlin/native supported libraries. The app can be re-used and forked to an Android app template that supports BCH and Nextchain.

The Android app layer depends on libbitcoincashkotlin, enabling rapid expansion of wallet functionality.

The app is still dependent on some android libraries. Not fully multiplatform. All tough android runs on windows 11.

Votepeer android app-level (Wallet-level), votepeer android library (voting library-level), and libbitcoincash depend on android, but the implementation is written in kotlin with multiplatform in mind.

photo_2022-01-19_20-20-21

Thus, a kotlin/native fork is feasible.

Significantly, the local storage database layer needs to be moved from the Android room to a kotlin/native library.

When writing a new Wallet client now, I think using as much kotlin/native as possible now is beneficial. We can re-use the core wallet code for most clients, Including native support.

I would imagine one kotlin/native layer/base library and one client for each platform that imports the Bitcoin Unlimited Wallet (Core) Kotlin/Native library.

  • Kotlin/Native shared library could be a fork of libbitcoincashkotlin (Depends on android) to libbitcoincashkotlinnative (Kotlin/Native dependencies only)

Some clients can build and run with ease straight from the library. Other clients, such as iOS, need more tweaking.

Con: Kotlin/native is relatively new

photo_2022-01-19_20-25-36

References:

photo_2022-01-19_20-25-55

PS: ^ Outdated. Android native UI is kotlin/native compatible now. IOS still requires Native UI.

PPS: Super relevant case study: https://kotlinlang.org/lp/mobile/case-studies/cash-app

PPPS: I can draft an architectural overview and implementation path suggestion if anyone is interested.

1 Like
4

Greetings BU Team,

I absolutely love this initiative!

I’ve been working on a web wallet since 2020 called nito.cash and I’ll be spearheading a new multi-currency FOSS wallet this year, hopefully to be ready before (or soon after) the May 15th upgrade. I believe this new FOSS wallet would meet most if not ALL of your baseline requirements for the NEXA wallet.

With all due respect, I strongly disagree with @jQrgen regarding Kotlin/Native (which I assume implies Swift for iOS). My FOSS wallet will be written in React Native and that is definitely my recommendation for this initiative.

It’s NOT all that I disagree that Kotlin/Native would deliver a “better” finished project, however, you mention that you want to encourage developers to extend this application for their own purposes, which I support 110%. However, doing that with Kotlin & Swift is extremely prohibitive for “MOST” developers. That and that alone is my justification for using RN.

Anyhoo, I see that the voting has concluded (approved) and I’d love to through my hat in the ring to bid on the BUIDLing of the “official” NEXA wallet. Please advise on how to do so…

(Paul I also DM’d you in the BU Slack)

Cheers!
Shomari

5

Hey Shomari.

Welcome to the forum.

I’ve been working on a web wallet since 2020 called nito.cash and I’ll be spearheading a new multi-currency FOSS wallet this year, hopefully to be ready before (or soon after) the May 15th upgrade. I believe this new FOSS wallet would meet most if not ALL of your baseline requirements for the NEXA wallet.

Great initiative.

With all due respect, I strongly disagree with @jQrgen regarding Kotlin/Native (which I assume implies Swift for iOS). My FOSS wallet will be written in React Native and that is definitely my recommendation for this initiative.

Kotlin/Native provides bi-directional interoperability with Objective-C/Swift

Here is an architecture proposal I find reasonable.

It’s NOT all that I disagree that Kotlin/Native would deliver a “better” finished project, however, you mention that you want to encourage developers to extend this application for their own purposes, which I support 110%. However, doing that with Kotlin & Swift is extremely prohibitive for “MOST” developers. That and that alone is my justification for using RN.

Kotlin/Native provides bi-directional interoperability with Objective-C/Swift

I think that both Kotlin and Swift are top quality modern programming languages. What prohibitions do you see?

6

@jQrgen thank you for the warm welcome and the info links :hugs:

tl;dr I’ve been coding for Android since day 1, but I’ve NEVER used Kotlin, so I can’t speak on how well it ports with Objective-C/Swift, it’ll take me some time to review what you sent.

I took a quick peak at the articles and I already know that I’m gonna have to take a deep dive into understanding Kotlin/Native provides bi-directional interoperability with Objective-C/Swift. I know I won’t be able to do that until the weekend, at best, but rest assured that I’ll make time asap and respond appropriately.

fwiw, I’m very biased towards JS, so that has to be taken into consideration. I’m of the firm belief that JS has far greater utility when it comes to open-source “community” projects & initiatives, like this one. closed-source would be an entirely different story.

cheers!
Shomari

2 Likes