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.

@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 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.

@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.

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.

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.

@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.

@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.

@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.

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 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.

@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? 😅

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

Here is a memory profile from the headless app running with JProfiler (250 MB):

And that is with the UI app (350 MB):

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...

@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?

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 😁

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.

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)?

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...

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 😅

One thing to be aware of with Android, not all Java will compile to Android's platform. I had this problem in 2018 with 1M5 as I'm using Neo4J and it would not work on Android. Definitely recommend a quick check to see if it can be compiled into an APK and installed on Android.

This proposal was approved by DAO voting in Cycle 7. However, since the GRPC API is still not ready after 6 months of waiting, I will close this proposal as "stalled" for now. Hopefully we can still do the Android app someday if the GRPC API is completed.