Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bounty for a fully native Bisq app for Android #139

Open
wiz opened this issue Nov 11, 2019 · 20 comments
Open

Bounty for a fully native Bisq app for Android #139

wiz opened this issue Nov 11, 2019 · 20 comments
Assignees

Comments

@wiz
Copy link
Member

@wiz wiz commented Nov 11, 2019

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

EDIT: Proposal amended to use Bisq GRPC instead of Risq on this comment

Background

Over the past month I’ve been working with @bodymindarts on The Risq Project, a feasibility study on creating an alternative implementation of Bisq in rust language. Since rust compiles to native code, we could achieve much better performance than Java, which opens up many new potential use cases for Bisq. I'm very proud that Risq is quickly making progress and we're already using Risq in production for the Bisq Markets API service and my infrastructure alerts system to monitor Bisq seednodes.

But the coolest breakthrough in our feasibility study was when I had the crazy idea to ask @bodymindarts to try using Android's Native Development Kit to package Risq and Tor into a Proof of Concept native Android app, and he successfully got it working in only a few days! After that, we started using the PoC Android app to study how well we can directly connect to the Bisq P2P network from an Android device, and observe what the CPU, RAM, battery, and network usage would look like.

The Proof of Concept

Screenshot 2019-11-10 at 15 25 46

After some testing, we realized it's totally possible to create a native Bisq for Android app using Risq and Tor, without the need for a desktop computer or even a Raspberry Pi at home. You could even be at a bar or Bitcoin meetup and have someone to install Bisq on their phone and instantly start trading with them on Bisq!

The Dream

I asked @pedromvpg to design some UI mockups of what Bisq might look like on Android, and he quickly sent over the following beautiful work

The Estimate

To implement basic trading functionality (specs below), our rough estimate is that it will take 3 people working full-time about 6 months to implement all of the low-level functionality required, together with a nice UI / UX that average users would be able to use. We could then publish the Bisq for Android app on the Google Play store, and also allow direct APK installations from the Bisq website for censorship resistance.

The Proposal

Since the Bisq DAO's compensation system only pays for contributions after they are completed and delivered, it's not well suited for long-term projects like a full-blown Android app which would take 6+ months to complete. For large projects like this, it's necessary to have a team leader fund the development of the project out of their own pocket, until the project is completed and request compensation to reimburse the expenses. If this proposal is accepted, I will fund our development fully and only request compensation after the Android app is completed to the satisfaction of the Bisq DAO.

The Specifications

  • Single Android APK bundling TOR + Risq + Native android UI
  • Bitcoin support for the trade wallet via BIP 158 / 157 (aka Neutrino protocol)
  • Minimal trade functionality using external Bitcoin wallet app installed on Android device
  • Minimal trade dispute resolution
  • No BSQ wallet or DAO / Governance (will be added in a later update and not part of this proposal)

The Bounty

Upon acceptance by the Bisq DAO, I will begin funding the project and take all the risk myself, and only after completion I will request the bounty be paid out to reimburse the cost of development for the project. The bounty amount will be $180K USD to compensate 3 people working full-time for 6 months at an average rate of $10K/month/person.

If the project is not completed or does not work for some reason, the Bisq DAO will not compensate us, so this is a no-risk proposal for Bisq.

Try it out yourself

Please download and install the Proof of Concept Bisq for Android app to see how far we've gotten. Give it a minute to start up (no loading screen yet!) and imagine how cool a fully functional Bisq app for Android would be to easily onboard new users 😁

@niyid

This comment has been minimized.

Copy link

@niyid niyid commented Nov 11, 2019

Good work @wiz, @bodymindarts

Maybe you can create a Slack channel (if not done yet) on this as this is a project of highest priority and I will be glad to join. I have long been looking at the fastest route to get Bisq on Android and other Mobile devices.

@bodymindarts

This comment has been minimized.

Copy link

@bodymindarts bodymindarts commented Nov 11, 2019

@niyid we talk on the #risq channel on bisq org in keybase. Slack is too vulnerable to impersonation. You're welcome to join us there.

@niyid

This comment has been minimized.

Copy link

@niyid niyid commented Nov 11, 2019

@niyid we talk on the #risq channel on bisq org in keybase. Slack is too vulnerable to impersonation. You're welcome to join us there.

Great. Thanks.

@chimp1984

This comment has been minimized.

Copy link

@chimp1984 chimp1984 commented Nov 13, 2019

@wiz
I highly appreciate the initiative to push the project to get an Android app developed and your commitment to pre-fund such a project!

My only concern with that particular proposal is the dependency on the Rust (risq project) implementation. I expressed my concerns regarding risq here: #125 (comment).

I would suggest an alternative approach:

  • Build on top of the upcoming Bisq API (either GRPC or HTTP API)
  • Use the same architecture of a headless server app and a UI client with flexible setup so the mobile user can run the full Bisq app on their phone if the headless Bisq app is running there or they can run the headless app on any server/cloud service or they connect to their Desktop app which is configured to run in server mode.

For reducing resource requirements the user can deactivate the DAO by an option key. Ram usage is roughly 40% lower as a quick test has shown.
Improving performance is on our top prio list anyway, so expect lower resource requirements soon. BitcoinJ is currently our main resource consumer but as soon we have enough dev resources that will likely be replaced by Electrum which will result in much lower resource requirements and faster startup time.

I think using the existing headless Bisq app as basis comes with many benefits:

  • You can use it soon and dont need to wait 6-12 months for a ”risqy" re-implementation
  • No extra costs for building on top of Bisq by using the API instead of reimplementing Bisq
  • It is the same code base as the desktop App so maintenance is much easier
  • The DAO can be enabled or disabled by a flag
  • No risk of consensus or compatibility issues
  • Any improvements on the Java implementation will flow directly into the headless app as well (same code base)
  • New featues will require only updates in the UI not in the business domain code.

I am not much familiar with Android development but if the packaging of the Bisq headless app into Android is a challenge maybe we should start with a bounty task to see if that is feasible. I expect and hope that this should not be a major problem.

Alternatively to pre-fund the full project you could consider to provide a roadmap with clearly defined acceptance criteria which once they are met get compensated. We should discuss in the context of the incubator idea how we can deal with such situations.

Please note, that I will reject the current proposal in the DAO voting as I interpret it as being based on the risq project which I do not support. But I highly appreciate the initiative to get a mobile app out using the Bisq API approach and would fully support work on that.

@bodymindarts

This comment has been minimized.

Copy link

@bodymindarts bodymindarts commented Nov 13, 2019

My only concern with that particular proposal is the dependency on the Rust (risq project) implementation. I expressed my concerns regarding risq here: #125 (comment).

@chimp1984 many of your concerns you bring up in your comment on that proposal are not actually relevant for V2. They are however relevant for this proposal as this implies at least a partial re-implementation of V1.x. I think it would be very helpful if we could keep those discussions separate.

@bodymindarts

This comment has been minimized.

Copy link

@bodymindarts bodymindarts commented Nov 13, 2019

I am not much familiar with Android development but if the packaging of the Bisq headless app into Android is a challenge maybe we should start with a bounty task to see if that is feasible. I expect and hope that this should not be a major problem.

I would consider running Bisq standalone on Android unfeasible until proven otherwise. The resource requirements of risq are almost an order of magnitude less than Bisq in every dimension. In some cases the gain is >200% (eg RAM usage is constant @ ~100mb of RAM vs 1.7GB after start up which grows to > 2GB after 4hours on my 2015 MBP running latest OSX).
Integrating the code base to get called from an APK is perhaps possible but likely non-trivial.

@chimp1984

This comment has been minimized.

Copy link

@chimp1984 chimp1984 commented Nov 13, 2019

@bodymindarts Bisq can run with about 200 MB of RAM. I had about 30-40 instances running of my machine for testing purposes and memory went down to about 200 MB per instance. Java is greedy and use what the OS has available on RAM... Your risq app cannot be compared with Bisq yet as it has implemented only a tiny part of it yet.

@trigger67

This comment has been minimized.

Copy link

@trigger67 trigger67 commented Nov 13, 2019

@wiz I discovered Bisq very recently, but I like your idea and think that a mobile app would be amazing. There is just one thing that I dislike: it would require a lot of work, just for Android platform...
Have you considered using web technologies instead of developing a native android app ?

I am no expert, but I think developing a Progressive Web App would be the best option (if possible). It would work just like a native app on any OS. All that with one single code base... (I will elaborate later if this is considered.)

Is it possible ?
I know that rust can be compiled to web assembly, so you can use Risq in a PWA.
For connecting to Tor network and protecting privacy I have no clue... But could try to find the information, or help to develop a PoC.

@niyid

This comment has been minimized.

Copy link

@niyid niyid commented Nov 13, 2019

@chimp1984 @bodymindarts

I will find a memory performance/footprint report comparing both Java and Rust implementations interesting. Maybe creating a stripped down version of Bisq comparable to the Risq version will help.

@yoshimo

This comment has been minimized.

Copy link

@yoshimo yoshimo commented Nov 13, 2019

i partially agree with @chimp1984 , we should have a set of intermediate goals that can be compensated but i think moving away from java to a secure language with rust is still a goal that should be reached for all platforms.

Having to front the money for people is quite a burden for a person and i think if we split it across multiple people in the community we might be able to reach the goal faster depending on how many people are intrested in this.

@bodymindarts

This comment has been minimized.

Copy link

@bodymindarts bodymindarts commented Nov 13, 2019

@bodymindarts Bisq can run with about 200 MB of RAM. I had about 30-40 instances running of my machine for testing purposes and memory went down to about 200 MB per instance. Java is greedy and use what the OS has available on RAM...

Thats very interesting. If that is the case its probably worth trying! My intention with risq is an investigation into implementing V2 anyhow. For V1.x on android running headless bisq is probably preferable - if it is possible.

@wiz

This comment has been minimized.

Copy link
Member Author

@wiz wiz commented Nov 13, 2019

@chimp1984 Since we weren't aware of your work on the Bisq java app's headless GRPC API implementation when we started the Android app PoC using risq, we didn't consider this option. You have a lot of very good points, and I discussed your suggestions with @bodymindarts and we agreed to accept your suggestions 😁

I propose that we amend this DAO proposal as follows:

  • we put the risq project on hold
  • we develop the Android app using Bisq java headless GRPC API (technical feasibility TBD)
  • we publish updates to the Android app every week or so and request normal compensation requests each cycle on the DAO like normal, instead of doing the pre-payment thing

Of course we still have to define some milestones and figure out how this is going to work technically, but putting the details aside for now can we have your "concept ACK" to start working on the Android app with Bisq java GPRC as above? 😅

@chimp1984

This comment has been minimized.

Copy link

@chimp1984 chimp1984 commented Nov 13, 2019

@wiz
Thanks for reconsidering that approach.
Here is my concept ACK ;-)

@chimp1984

This comment has been minimized.

Copy link

@chimp1984 chimp1984 commented Nov 13, 2019

Here is a memory profile from the headless app running with JProfiler (250 MB):
Screen Shot 2019-11-13 at 18 18 30

And that is with the UI app (350 MB):
Screen Shot 2019-11-13 at 18 20 23

As mentioned to improve performance/resource consumption is on our high prio todo list anyway. There are for sure a few low hanging fruits to pick...

@chimp1984

This comment has been minimized.

Copy link

@chimp1984 chimp1984 commented Nov 14, 2019

@wiz

I propose that we amend this DAO proposal as follows:

Could you include a link to that post in the initial first post so it is clear to readers and not get lost in the thread?

@wiz

This comment has been minimized.

Copy link
Member Author

@wiz wiz commented Nov 14, 2019

Could you include a link to that post in the initial first post so it is clear to readers and not get lost in the thread?

Okay done.

As for the integration work, it was more straightforward to package the risq daemon inside the Android app because it was a native linux binary. Packing the Bisq Java app inside the Android app would be a little tricky because of the JVM, so instead I think we might try to run the headless Bisq entrypoint method inside a separate Android background service thread - obviously Java will compile for Android fine out of the box, we just gotta hack it to work with Android app lifecycle. After we figure that out we can begin the work of working to add the missing API methods, etc. and integrate the UI 😁

@cbeams

This comment has been minimized.

Copy link
Member

@cbeams cbeams commented Nov 15, 2019

Exciting stuff, glad to see this effort coming together!

Regarding building the Android app on top of a new BIsq gRPC API, please take a look at the high-level plan for building that out at #136 (comment). Feedback welcome.

@cbeams

This comment has been minimized.

Copy link
Member

@cbeams cbeams commented Nov 15, 2019

Packing the Bisq Java app inside the Android app would be a little tricky because of the JVM, so instead I think we might try to run the headless Bisq entrypoint method inside a separate Android background service thread

As a first cut, how about assuming that the user has a dedicated Bisq node running somewhere, and making RPC calls to it (possibly/probably over Tor)?

@wiz

This comment has been minimized.

Copy link
Member Author

@wiz wiz commented Nov 15, 2019

As a first cut, how about assuming that the user has a dedicated Bisq node running somewhere, and making RPC calls to it (possibly/probably over Tor)?

We've been thinking about how to do the integration of Bisq Java codebase into the Android app. There are basically 2 ways to do it:

  1. Run the headless Bisq daemon and connect over GRPC API using a localhost socket or over Tor to the desktop computer or Raspberry PI at home - this would allows either running Bisq locally or remotely.

  2. Run the Bisq headless entrypoint inside an Android app's background service and post messages between the app thread and background service thread - this wouldn't work with remote nodes at home, but performance and UX of the Android app would likely be faster.

We need to do more research and testing into these architectures to figure out which one we will use, before we can answer the question...

@wiz

This comment has been minimized.

Copy link
Member Author

@wiz wiz commented Nov 15, 2019

Of course, maybe there is a hybrid solution where we can pass the GRPC messages between the background thread and the app thread, and have the option of sending the GRPC over a Tor socket to your computer at home... that would be the best of both worlds 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.