Mobile wallet

[holzeis]

Mobile wallet

Goal: Develop a mobile lightning wallet which offers non-custodial financial products based on bitcoin. The first financial product will be CFD trading.

• Setup mobile project #9
• Create wallet upon first start #11
• Open payment channel between taker and maker #10
• Source wallet from lightning #7
• Combine DLCs and Lightning Channels #8
• Setup build pipeline

Open Decisions

• What framework should be used for the mobile project? see discussion at Mobile wallet technology stack #5
• Do we want to build the wallet in typescript (what library to use) or build a native module using neon (https://neon-bindings.com/)? Second option may be hard to cross-compile for all architectures.
• The wallet needs to run a background task which is listening for events from the taker daemon, respectively which is monitoring it's own cfds and triggers an action e.g. if it needs to be rolled over. How should we build that part? headless-js? (https://blog.logrocket.com/run-react-native-background-tasks-headless-js/)

[bonomat]

• What framework should be used for the mobile project - react native? (reactnative.dev)

Most of the team are already familiar with react, so let's go with react native.

• Do we want to build the wallet in typescript (what library to use) or build a native module using neon (neon-bindings.com)? Second option may be hard to cross-compile for all architectures.

I propose to go for cross-compilation. Try for iOS and Android but if we have troubles on iOS drop it because it was mentioned it is easier for us to develop for Android by @klochowicz and @da-kami .

• The wallet needs to run a background task which is listening for events from the taker daemon, respectively which is monitoring it's own cfds and triggers an action e.g. if it needs to be rolled over. How should we build that part? headless-js? (blog.logrocket.com/run-react-native-background-tasks-headless-js)

Good question, we could build a simple polling process, which polls a backend every now and then (e.g. regular, on a certain action, or a mix of both).

[klochowicz]

I've got some questions about react native:

• how convenient is to use that with Rust?
• do we need to compile to wasm or is the plan to build the whole thing in TS? or is the idea to actually try compiling itchysats with neon as a nodejs library? or are we going for native compilation? This is the biggest unknown for me as for choosing react native.
• does react native have it's own component set or are we trying to use chakra there too?

my personal preference for the framework would be flutter (https://docs.flutter.dev/), as this seems as the fastest way to develop a compelling UI and it's straightforward to bind it to Rust (see: https://github.com/fzyzcjy/flutter_rust_bridge).
It can be readily deployed to both iOS and Android and desktop/web as well without any further change. It is also recommended over react native for the faster app development (in both senses of the word 'faster', the dev speed and resulting app is faster).

[bonomat]

I've got some questions about react native:

* how convenient is to use that with Rust?

I personally have no experience but I found a blog post about someone building an ethereum wallet with rust and react native which is very close to what we need

* do we need to compile to wasm or is the plan to build the whole thing in TS? or is the idea to actually try compiling itchysats with neon as a nodejs library? or are we going for native compilation? This is the biggest unknown for me as for choosing react native.

I think compiling to native is the preferred way to build for mobile. Particularly if we want to sign 100s of transactions we will appreciate the performance.

* does react native have it's own component set or are we trying to use chakra there too?

Afaik chakra can't be used in react native but we can reuse our components.

my personal preference for the framework would be flutter (docs.flutter.dev), as this seems as the fastest way to develop a compelling UI and it's straightforward to bind it to Rust (see: fzyzcjy/flutter_rust_bridge).
It can be readily deployed to both iOS and Android and desktop/web as well without any further change. It is also recommended over react native for the faster app development (in both senses of the word 'faster', the dev speed and resulting app is faster).

I'm against flutter because it is a

• new framework: flutter
• a new language: dart

We have no experience with neither.

[klochowicz]

I've got some questions about react native:

* how convenient is to use that with Rust?

I personally have no experience but I found a blog post about someone building an ethereum wallet with rust and react native which is very close to what we need

that project went only until setup & "Hello World" stage (!), this does not instil much confidence. It also needed to interact with JNI on android, and suggested creating custom Java bindings yourself.

* do we need to compile to wasm or is the plan to build the whole thing in TS? or is the idea to actually try compiling itchysats with neon as a nodejs library? or are we going for native compilation? This is the biggest unknown for me as for choosing react native.

I think compiling to native is the preferred way to build for mobile. Particularly if we want to sign 100s of transactions we will appreciate the performance.

* does react native have it's own component set or are we trying to use chakra there too?

Afaik chakra can't be used in react native but we can reuse our components.

my personal preference for the framework would be flutter (docs.flutter.dev), as this seems as the fastest way to develop a compelling UI and it's straightforward to bind it to Rust (see: fzyzcjy/flutter_rust_bridge).
It can be readily deployed to both iOS and Android and desktop/web as well without any further change. It is also recommended over react native for the faster app development (in both senses of the word 'faster', the dev speed and resulting app is faster).

I'm against flutter because it is a

• new framework: flutter
• a new language: dart

We have no experience with neither.

They seem quite straightforward; it's just declaring a widget tree and hooking up Rust functions. I would expect much, much less pain in the dev process thanks to the lack of virtual DOM, hooks etc.

[bonomat]

I've got some questions about react native:

* how convenient is to use that with Rust?

I personally have no experience but I found a blog post about someone building an ethereum wallet with rust and react native which is very close to what we need

that project went only until setup & "Hello World" stage (!), this does not instil much confidence. It also needed to interact with JNI on android, and suggested creating custom Java bindings yourself.

There is a part 2 of this blog post and here is the parity signer which was written in react native and rust and then moved to native iOS and native Android as it looks like.

But maybe React Native + Rust is not the best call afterall. Any other thoughts @holzeis / @da-kami / @luckysori?

[holzeis]

Well, any combination where we are cross compiling from rust to android and bridging it will introduce some complexities. I can't judge if this will only be a one time hassle or will follow us along the project. I feel like the easiest way would be to stay completely within TS, yet it does not look like there are many options for that. From a quick google the preferred way seems to build the wallet in rust and bridge to the respective platforms.

I can't say if flutter is better than react or the other way around. On the one hand I do agree with @bonomat arguments on the team skills, which rather speaks for react than for flutter. On the other hand, though, I don't think we should bother too much with that as I am sure the team will pick up the new framework very quickly.

I suggest we make quick prototypes with both frameworks and then go with the framework offering the best dev experience.

[holzeis]

@bonomat @klochowicz Lets continue the mobile tech stack discussion here #5

[holzeis]

I am closing this ticket as the discussion has already moved on.