bisq-network / bisq-client

A client for the Bisq network supporting Android, iOS, desktop, and web platforms.

Bisq Client

A client for the Bisq network supporting Android, iOS, and Desktop platforms.

Note, a Web platform will be added at a later date when "Compose for Web" becomes more mature. The web version of SqlDelight (the most popular local database for Kotlin MultiPlatform) is also at a very early stage, as currently the database cannot even be saved persistently. It might take until the end of 2021 before it makes sense to start work on a proper Compose for Web app.

Project Status

This project is just getting started and we are looking for active contributors to help. Refer to the wiki for project information and take a look at open issues and milestones to see what needs to be done. Though do keep in mind that as per the project plan we have defined milestones with incremental functionality to be completed sequentially. If you are interested in contributing, please review CONTRIBUTING.md.

bisq-client's Issues

Mobile - view open trades

Implement a mobile view that allows the user to view active trades, following the designs specified here, and includes:

• Trade ID
• Date/Time
• Market
• Price
• Amount in BTC
• Amount
• Payment method
• My role
• Status
  • Waiting for blockchain confirmation
  • Start payment
  • Wait until payment arrived
  • Completed
• Deposit transaction ID with # of confirmations
• Max allowed trade period
• Remaining time
• Payment details

etc....

Receive native OS push notification alerts

The Bisq application is able to be configured to send native OS push notifications of important events to a paired mobile app. This is the only functionality of the existing mobile app and we should be able to implement the same behavior with minimal effort.

Note that this relies on Apple's APNS service for iOS and Google's FCM service for Android and will not work on some custom Android OS's that do not provide Google Play services such as CalyxOS or GrapheneOS. An alternative approach will need to be implemented to support those and is outside the scope of this task - see #7.

We should be able to utilize the existing mobile relay node to send iOS and Android push notifications without any changes required to the service.

Todo:

• Receive and display notifications of the following events:
  • price alert
  • new offer
  • offer taken
  • trade status changed
  • dispute message

Setup CI environment

Perhaps use Github actions.

Implement initial UI framework and views for Android

Bounty: $500 USD*

*To be compensated via the Bisq DAO in the USD equivalent of BSQ at the time of submitting a compensation request.

In order to claim the bounty, the following criteria must be satisfied:

• Written in native Kotlin using latest framework/libraries.
• Follows Android design guidelines.
• Follows Kotlin coding conventions and style guide.
• Integrates into the project structure, as setup by #1.
• Builds successfully without errors.
• Implements the legacy pairing process views following the designs specified here. The pairing process does not need to work, as the business logic will be implemented in #24; just need a click through prototype.
• Implements a notifications view following the designs specified here. This should be the primary/initial view. Dummy notifications can be generated for demonstration purposes as the actual implementation will be done in #6.
• Implements a settings view that has options to re-run the pairing process, delete all notifications, mark all as read following the designs specified here.

Create settings view

Create a settings view that has options to re-run the pairing process (as implemented by #29), delete all notifications and mark all notifications as read (as implemented by #1). Follow the designs specified here.

• iOS views
• Android views

Mobile - initiate and respond to peer messages

Implement initial UI framework and views for web

Criteria have not been defined yet.

Implement initial UI framework and views for iOS

Bounty: $500 USD*

*To be compensated via the Bisq DAO in the USD equivalent of BSQ at the time of submitting a compensation request.

In order to claim the bounty, the following criteria must be satisfied:

• Written in native Swift using latest framework/libraries.
• Follows iOS design guidelines.
• Follows Swift design guidelines and a consistent style such as Google's or raywenderlich.
• Integrates into the project structure, as setup by #1.
• Builds successfully without errors.
• Implements the legacy pairing process views following the designs specified here. The pairing process does not need to work, as the business logic will be implemented in #24; just need a click through prototype.
• Implements a notifications view following the designs specified here. This should be the primary/initial view. Dummy notifications can be generated for demonstration purposes as the actual implementation will be done in #6.
• Implements a settings view that has options to re-run the pairing process, delete all notifications, mark all as read following the designs specified here.

Mobile - view market offers

Follow the designs specified here.

Add support for communicating with the Bisq client via a local socket

In order to connect to a locally running Bisq instance for the desktop platform, we need to support communicating with the Bisq client via a local socket. We will not support non-localhost socket connections.

Implement pairing process

For the PoC, we need a pairing process that is similar to that of the existing mobile app. This is done by sending the device token and encryption key from the mobile app to the Bisq client either by scanning a QR code generated by the app into the Bisq client or by emailing it from the app and entering it into the Bisq client.

The design work will be done in #29, so this will just need the back-end logic to generate the device token and encryption key, and generate/display a QR code.

See Pairing Process for more information.

Change the process by which we pair the mobile app to the Bisq client

The current pairing process is done by sending the device token and encryption key from the mobile app to the Bisq client either by scanning a QR code generated by the app into the Bisq client or by emailing it from the app and entering it into the Bisq client.

This process is not ideal as it requires a web cam for the desktop application to scan the QR code, and the process of sending it by email is cumbersome. Not to mention that the webcam library is not currently supported by the desktop application so currently the only supported process is via email.

The better approach is to generate a QR code on the desktop application and scan it into the mobile app. In order to do this, the QR code should just contain information about connecting to the client via Tor (i.e. Tor address), and the user can then enter the password. Once a connection has been made, the app can send additional information via the GRCP API such as device token and encryption key for push notifications. Note that support for this will need to be added to the API.

Also, we should allow for manually inputting the Tor address in case the user does not want to (or not able to) use their camera to scan the QR code or if they are unable to generate a QR code such as when running a headless client. Though we should look into solutions for being able to generate a QR code when running a headless client such as using something like qrencode or some other library.

Follow the designs provided here.

Todo:

• Update Bisq desktop client to display a QR code consisting of its Tor address.
• Update Bisq API to be able to send mobile device information such as device token and encryption key used for push notifications.
• Add support for being able to communicate via Tor.
• Add support for the new GRPC method.
• Implement views/functionality for scanning the QR code and storing the client Tor address, or allowing the user to manually input the Tor address.
• Implement views/functionality for allowing the user to input the GRCP authentication password.
• Implement functionality of sending the mobile device information via Tor to the new API method.
• Implement a solution for being able to generate a QR code when running a headless client.

[UI Fix] Evergrowing date pickers

Description
The date boxes on the Wallet Seed page keep on growing. Please check the attached video.

Version
Bisq Desktop for Windows v1.9.5

To Reproduce
Steps to reproduce the behavior:

1. Go to Acccount/Wallet Seed.
2. You will see the growing date boxes.
3. They will never stop growing UNLESS you restart the application.

Expected behavior
The date boxes should not grow.

Screenshots
https://user-images.githubusercontent.com/46481195/193765232-be6d3dae-82c5-403b-83b9-e326cf01e9e3.mp4

System info (please complete the following information):

• Windows PC
• Windows 11 Version 21H2 (OS Build 22000.1042)
• Windows 11

Additional context or logs
The issue may not be limited to Windows 11.

Mobile - manage accounts

• Add account (fiat and altcoin)
• Remove account

Follow the designs specified here.

Implement initial UI framework and views for desktop

Criteria have not been defined yet.

Setup initial project

Implementing an initial project structure based on Architectural Design will serve as a base and example for future tasks/contributors. To make this worth while, a practical but basic initial view will need to be implemented that runs on each platform for demonstration purposes. For now, our focus will be on getting Android and iOS platforms working - we will add other platforms later.

• Create a basic project structure with shared, Android, and iOS components.
• Implement a simple notifications view that runs on each platform (Android and iOS). This should be the primary/initial (and only) view. Dummy notifications can be displayed/generated for demonstration purposes as the actual implementation will be done in #6. Since we don't yet have any UX designs for this view, it doesn't have to be fancy but should at least try to follow Android/iOS design guidelines if possible.
• Add unit tests at least for any shared code.

Mobile - receive funds

Follow the designs specified here.

Create native distributions (installers/packages) for all the supported systems

Reference:

• https://github.com/JetBrains/compose-jb/blob/master/tutorials/Native_distributions_and_local_execution/README.md
• https://github.com/JetBrains/compose-jb/tree/master/tutorials/Signing_and_notarization_on_macOS

Mobile - edit open offers

• Edit open offer
• Disable open offer
• Delete open offer

Follow the designs specified here

Configure dependency verification

https://docs.gradle.org/current/userguide/dependency_verification.html

Mobile - take market offer

Follow the designs specified here.

Design notifications view

Requirements:

• The notifications view lists received notifications (i.e. push notifications) such as price alert, new offer, offer taken, trade status changed, dispute message, etc.
• The received notifications must expand to show further details including notification type, notification message, notification occurred timestamp, notification received timestamp.
• Must be able to delete all notifications or mark all as read.

Mobile - send funds

Follow the designs specified here.

Mobile - manage open trades

• Confirm payment received
• Acknowledge payment sent

Follow the designs specified here.

Configure reproducible builds

Design legacy pairing process

For the proof-of-concept release (v0.1), we need a legacy pairing process that is similar to that of the existing mobile app. This will be different from the pairing process that we will need in our MVP release (v1.0).

Requirements:

• A wizard-like pairing process that walks the user through the steps of pairing the Bisq desktop client to the mobile app by showing a QR code on the mobile app that gets scanned from the desktop app.
• If the user is unable to scan the QR code, we need to allow the user to transfer the pairing code (e.g. by emailing it to themself) and manually enter it into the Bisq desktop client.

Mobile - request trade mediation/arbitration

Follow the designs specified here.

Implement push notifications that do not rely on Apple APNS or Google FCM services

The current push notifications rely on Apple's APNS service for iOS and Google's FCM service for Android and will not work on some custom Android OS's that do not provide Google Play services such as CalyxOS or GrapheneOS. An alternative approach will need to be implemented to support those.

We may be able to utilize something like UnifiedPush. Further investigation is required.

Note that support will need to be integrated into the app as well as the Bisq client.

Create pairing process views

Create the legacy pairing process views following the designs specified here. The pairing process does not need to work, as the business logic will be implemented in #24; just need a click through prototype that works on each platform.

• iOS views
• Android views

Mobile - make market offer

Follow the designs specified here.