[WIP] Bisq Mobile MVP

[rodvar]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

Background

This proposal is in line with making Bisq Network accessible on Mobile Platforms following the philosophy of Bisq2 - to make it easier for both, experienced and newcomers, to trade Bitcoin in a decentralized way as well as defending Bisq motto: exchange, decentralized, private & secure.

We want to do an MVP (Minimum Viable Product) from 0 to release in the market and hopefully grow from there if we see enough interest.

To achieve this goal, we are building a total of 3 mobile apps that can be divided in 2 categories:

Run a Bisq (Easy) Node in Mobile

An Android app (called androidNode) that runs bisq core in its veins aiming to bring a fully featured trading version of Bisq2 (also referred to as its main protocol - Bisq Easy) to Mobile for full privacy & security.

Share a trusted Bisq Node

A thin Bisq App Client (coming in Android & iOS flavors) able to be configured to connect to a trusted Bisq node (over clearnet) to cater to people willing to try Bisq from somebody they trust (popularly described as "Uncle Jim") who is willing to share his Bisq node with them.

For more information on the challenges that this poses please refer to the:

• Discussions on Bisq-Mobile that finally lead to this proposal
• POCs of efforts to validate different possibilities

Proposal Summary & Limitations

We propose a timed-effort of a well defined MVP scope for 3 apps:

• 1x Android-only Bisq2 (Bisq “Easy”) app refered as androidNode app includes curated security/anonymity related Bisq2 networking code will support bisq-easy clearnet only (for MVP, potentially adding tor in the near future though there is ongoing effort to bring this for the MVP) potential to support more options in the future
• 2x bisq client apps (1x iOS and 1x Android) referred to as xClients or androidClient and iosClient apps allow users not willing to run a bisq node to configure a trusted node and still be able to use bisq2 from their mobile this option allow us to have bisq in iOS too that still has a big market share in developed countries
• The proposition includes 1 codebase to rule them all using Kotlin Multi Platform (Compose) framework.

Limitations

• xClients apps depend on having a Bisq2 API and that is not part of this proposal. This is because there is still ongoing discussion on what the API should allow and how it should be implemented. However, this proposal includes developing the client apps with a mocked API implementation for them hoping the API will be done either in parallel or right after this effort is finished.
• MVP (Minimum Viable Product) will focus on the following:
  • Respectful to Bisq L&F UI following best mobile practices for a delightful UX experience
  • focus on the minimum we need to get trades going on mobile (buy/sell , my trades, min settings and just create one new profile if not existent already)
  • In plain words, users of Bisq mobile will be able to connect to Bisq on their phones and do Bisq-easy trades from start to finish.

What makes this mobile proposal attractive?

There have been many intents to bring Bisq to mobile with no real success, some Bisq maintainers called it specifically “big failures”.

We believe this is a winner proposal because:

1. The node version leverages already curated JVM Bisq 2 code by using a JVM compatible platform (KMP), the way it works is by locally publishing through maven a java 17 compatible Jar of the needed bisq 2 modules (with some adaptations Henrik is working on). This remove huge risk away from the project.
2. The proposed solution also caters for including iOS in some form which is still very desirable to have specially in the so called “developed countries”. This is a very challenging platform for specific software focused on privacy and security like Bisq. Since 90%+ of the UI will be shared across the apps, the solution allows to cater for this without increasing the costs significantly.
3. The proposal of “1 codebase, 3 apps” allow us, by sharing modules in the form of kmp-libs, to gain progress in all fronts regardless of limitations of not having externalities ready. This is a huge advantage for xClients since Bisq API is not developed yet.

What has been already done prior to this proposal?

• Feasibility analysis and POCs of available frameworks covering the restrictions discussed in Bisq Mobile discussion
• Initial designs for apps
• Bare bones kick-off project KMP with shared Compose UI that generates 3 apps (2 android, 1 iOS) from the same Kotlin codebase.
• Bisq 2 Branch to be able to generate Android Compatible (Java 17) jars and a local publish mechanism (maven) for easy re-usal in androidNode development
• and Android native POC that showcases how these jars can be used for the mobile devs to have handy or directly port to the KMP androidNode app
• bisq-x project showcasing how bisq-api could be implemented

Estimations and Timeline

Assumptions:

• Full Time (FT) : ~30-40 h/week
• Part Time (PT) : ~20 h/week
• Estimations include testing time which in a fully dev team as Bisq is a combination of:
  • unit and/or integration testing
  • cross testing with PR reviewers
  • code reviews
  • manual integration testing
• Costs expressed with “$” means USD

Available Resources per Cycle:

The following describes the “Initial Team”. We hope being this is an open-source project some people will join in along the way, but we consider this the team to be responsible for “crossing the river”:

• rodvar: FT // bisq-mobile maintainer and dev
• nostrbuddha: PT // designer and dev
• boilingfrog and cbeams: Hi experienced Bisq devs who offered to have a minor commitment of min 5h / week each for Bisq2-related tech barriers removal and project oversight.

Being an open-sourced project, there could be (and looks like there will be) more people joining in to help along the way but the proposal is done with the initial time that is ready to get the goal to the other side of the river altogether from the get-go.

Total Cost and Timeline

Shared

Feature	Time Estimate (Cycles)	Cost ($)
App Skeleton & Navigation Tabs	0.75	$12000
Profile Setup & Onboarding	1	$7500
Trading Workflow	2	$30,000
My Trades	0.5	$7500
Non-functional Requirements (UX, testing)	0.5	$7.500

Clients-Only Features

Feature	Time Estimate (Cycles)	Cost ($)
Settings for Trusted Node	0.25	$3,250
Client Onboarding for Trusted Node	0.25	$3,250
Mocked implementations	0.25	$3,250

Node-Only Features

Feature	Time Estimate (Cycles)	Cost ($)
Networking Integration (Secure Jars)	1 cycle	$15,000

note: for the xClients connectivity related stuff will be mocked until we have APIs in place.

Summary of Total Estimates:

Based on initial team availability, between 4 and 5 months of work is anticipated, details below:

• Total Time Estimate: ~4.5 cycles

• Total Cost Estimate: ~$90,000.- ( ~1.33 BTC at the time of writing)

  Important notes:

• This is a rough estimate based on all of the above

• A report to the DAO will be done at the end of each cycle to keep everyone accountable, track progress and maneuver accordingly if needed.

Timeline

Cycle 1:

• App skeleton, navigation, and partial trading workflow.
• App Architecture (prob. based on MVC) with examples of usage network client abstraction to allow implementation for client connections (client apps) and node connections.
• Setup CI to run tests on each push to master

Cycle 2:

• Continue the trading workflow, integrate profile setup, and settings.
• Networking integration for the node app.

Cycle 3:

• Onboarding for each app type
• Independent node app and client apps UI implementations

Cycle 4-5:

• General testing and bugfixing to ensure the app is respectful to the MVP guidelines
• androidNode app should be ready to release at this stage: prepare app listing on Google Play + upload and release on stages
• xClients apps: same if API is ready, otherwise API should start development to be able to release these

[cbeams]

Thanks so much, @rodvar, for putting this together. I've have read though it, but will wait to comment more fully until I've shared the materials I'm currently working on later today. I'll get back here in any case by noon tomorrow (Wed).

[cbeams]

I'll get back here in any case by noon tomorrow (Wed).

hi @rodvar, all, as mentioned in the "async debate" video I published today, I'd like to give folks a chance to watch that video and consider my arguments as to why we should not implement the full node option on Android. If there's a consensus that we shouldn't, then we could update this proposal accordingly and I would give it a thumbs up after possibly some more minor discussions. As it stands right now, I wouldn't give it a thumbs up because of the full node aspect, but I'm really glad to see the rest of the proposal and wouldn't want to prematurely downvote it. So if you don't mind, I would wait until, say, Monday or Tuesday to weigh in here. Thank you again, in any case, for putting it together.