Mobile Wallet Challenges

[nopara73]

Wasabi mobile depiction is for illustration purposes only.

With @soosr we have collected possible bottlenecks for a mobile version of Wasabi Wallet:

Step 1. Immediate Challenges

• startup time
• big wallet load time when the wallet is fully synced
• receive transaction time
• send transaction time
• there may be CPU usage issues, which may lead to draining battery
• network usage issues can also come up: mobile users not only tend to have more frequent network disruptions but also tend to pay after network usage
• we may use a lot of RAM as well
• we may have disk space issues (this one is unlikely IMO, but I put here for completeness)
• wallet synchronization times can be really problematic due to our usage of client-side filtering
• we can expect to be some serious friction with very different mobile devices, so testing on them should happen
• AOT compilation (maybe helps with some performance issues)
• ❗ iOS and Android stores may be a challenge to get accepted into (an interesting option is to aim for getting into the Mac store before we try the iOS store, a version should be built without Tor and without coinjoin to get into the store without privacy it's possibly easier)

Step 2. Privacy Challenges

• being able to run Tor on iOS and Android
• Rust Tor library (maybe helps with some Tor issues, also according to @MaxHillebrand, C Tor will be deprecated, so if it's challenging to make C Tor work on it, we may as well go with Rust Tor to begin with)

Step 3. UX Challenges

• the performance of Tor is insufficient for the user experience mobile users are used to (in theory, it can be explored which parts of the application do not need Tor)
• ❗CJ must run in the background, which will be a challenge

[nopara73]

One exciting realization we had is that the @zkSNACKs/ui-team can potentially build a mobile wallet as a proof of concept that solves none of these issues. (They don't even need to use Tor for starter.)

[nostitos]

How about forking an existing wallet and adding anonscore calculation?
On the go spending is the main benefit of mobile.

Mixing can get done at another time on desktop.

Main remaining issue is protecting from the lost of privacy when syncing.

[nopara73]

Only two of the big list of issues above are worrisome. The rest seems just a good amount of work, but relatively straightforward.

1. Getting into Apple and Google stores
2. Running CJ in the background

It'd be the wisest strategy to get into Apple and Google stores before we build any privacy stuff. This would accord with your second and third suggestions, but not with your first: we should go in there with our code, so updating it later with privacy stuff and getting the new reviews from store owners won't require reviewing a completely new application and thus minimize the risk of refusal.

[kristapsk]

we should go in there with our code, so updating it later with privacy stuff and getting the new reviews from store owners won't require reviewing a completely new application and thus minimize the risk of refusal.

Not sure how much it is so with Apple. With Damus for some versions they said nothing about feature of zapping individual posts, but at some point later said it was against the terms, with argument that it could be used to sell content without paying Apple their share. Likely just some different person reviewed it.

[nopara73]

Hmm... I didn't think of that. So basically, both ways have a good argument for:

1. if we launch all the privacy features later on, then we're betting on the lighter reviews for updates
2. if we launch with all the privacy features right away, then the first review may divide the reviewers' attention between many different things and won't focus on the privacy stuff

Which strategy makes more sense?

[nopara73]

DALL-E 3

[ichthus1604]

Regarding running background processes on specific Android brands: https://dontkillmyapp.com/.

I have effectively reproduced the problems described in that link on several Android devices (mostly Samsung).