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 into 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 led 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 referred to 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 an 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 allows 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.
• Just to make it clear: all of this is only related to the Bisq-Easy protocol, no plans for other protocols at least for now.
• 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 (already completed by Henrik). This removes huge risk away from the project.
2. The proposed solution also caters to including iOS in some form which is still very desirable to have especially 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 us to cater to this without increasing the costs significantly.
3. The proposal of “1 codebase, 3 apps” allows us, by sharing modules in the form of hemp-libs, to gain progress on 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-use 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 bug fixing 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.

[rodvar]

updated proposal, fixed typos

[rodvar]

ea5e61ab8da8c3a41205ef10070aab4ded41694574144960a0b66dfca457419a

[cbeams]

I would wait until, say, Monday or Tuesday to weigh in here

@rodvar, all, I've been glad to see the consideration given to the video I put together; thanks again for everyone's time and attention there. I do plan to follow up a bit further as time allows, but I'm already satisfied with the discussions and clarifications that have ensued thus far. Like I said toward the end of the video, I was prepared for any outcome and won't stand in the way should the team decide to go with this proposal as is. Godspeed!

[rodvar]

THANKS to you @cbeams, looking forward to your next follow-ups!

[ripcurlx]

Really appreciate the thoughtful discussions about the mobile app's direction! @cbeams, your communication continues to be excellent and helps drive these conversations forward 👏

Regarding the Android release readiness:

androidNode app should be ready for Google Play Store deployment, including app listing preparation and staged rollout

@rodvar - Could you clarify the planned approach for app store publishing? Specifically:

• Will you be creating and managing the developer accounts for both Google Play and iOS App Store?
• Will the apps be published under your credentials?

On the thin- vs full-node client discussion:
I strongly align with @HenrikJannsen's vision for Bisq's values and their extension to the mobile experience. A few key points to consider from my perspective:

1. User experience (UX) will be critical for adoption (responsiveness, file size, network requirements)
2. Cross-platform compatibility with a full-node implementation presents significant challenges for delivering a quality mobile UX

For resource allocation, I would suggest:

• Initial focus: Develop robust thin clients
• Future phase: Evaluate full-node implementation based on community needs and technical feasibility

The priority should be delivering a reliable, user-friendly experience that maintains Bisq's core values while being practical for mobile users.

[HenrikJannsen]

Cross-platform compatibility with a full-node implementation presents significant challenges for delivering a quality mobile UX

We dropped that as it was considered unfeasible. Full node will be only used for Android.

For resource allocation, I would suggest:

* Initial focus: Develop robust thin clients

* Future phase: Evaluate full-node implementation based on community needs and technical feasibility

Full node for Android is already implemented as POC with all major use-cases and connection to the live network via a relay node (simply a node running clearnet+tor). See https://github.com/HenrikJannsen/andorid_only_poc/. @rodvar is currently working on the gradle adjustments to publish all libraries from Bisq 2 and use those as dependencies in mobile.

[rodvar]

Really appreciate the thoughtful discussions about the mobile app's direction! @cbeams, your communication continues to be excellent and helps drive these conversations forward 👏

Regarding the Android release readiness:

androidNode app should be ready for Google Play Store deployment, including app listing preparation and staged rollout

@rodvar - Could you clarify the planned approach for app store publishing? Specifically:

• Will you be creating and managing the developer accounts for both Google Play and iOS App Store?
• Will the apps be published under your credentials?

On the thin- vs full-node client discussion: I strongly align with @HenrikJannsen's vision for Bisq's values and their extension to the mobile experience. A few key points to consider from my perspective:

1. User experience (UX) will be critical for adoption (responsiveness, file size, network requirements)
2. Cross-platform compatibility with a full-node implementation presents significant challenges for delivering a quality mobile UX

For resource allocation, I would suggest:

• Initial focus: Develop robust thin clients
• Future phase: Evaluate full-node implementation based on community needs and technical feasibility

The priority should be delivering a reliable, user-friendly experience that maintains Bisq's core values while being practical for mobile users.

Hey @ripcurlx thanks to you for jumping in the conversation and taking time to review this.

To add up to @HenrikJannsen response and make it 100% clear, the proposal on both platforms is only for the thin client - this means, only for an app that connects to a trusted node that is configurable through settings.

The node solution is only in android - if you see our codebase it's very clear even in the modules name: androidNode , iosClient & androidClient (3 apps in total)

Thanks for the questions on deployment as well, this is still undefined and also an uncharted terrain for a DAO, what I can tell you so far from my perspective is:

1. I would be willing to do this
2. I could also be doing this, maybe not individually but through an organisation.

I'm kind of the main dev / PM for bisq mobile project and will do everything I can to ensure it gets to the other side of the river if that makes sense.
Please keep questions coming if you have more, cheers!

PS: I'm a huge fan of chris videos too haha

[suddenwhipvapor]

Closing as approved by DAO vote