Closed devinbileck closed 2 years ago
devinbileck
commented
3 years ago I have ammended this proposal to be for a fully featured cross-platform graphical user interface to the Bisq network supporting mobile, desktop, and web clients. Feedback welcome!
yoshimo
commented
3 years ago How would a Web based application work in terms of storing and processing payment related data? For me that feels weird when we care about being de central and secure.
devinbileck
commented
3 years ago It is just an interface to your own Bisq node, potentially running on a different machine (for example on an Umbrel device). Instead of using the Bisq desktop client, you would use your web browser.
ripcurlx
commented
3 years ago @devinbileck Thanks for bootstrapping this investigation phase for a mobile app! I think the first prototype could/should be a simple rewrite of the current mobile notification app. This would already allow us to test the whole pipeline including additional notarization steps. Based on my experience you are not able to fully judge which toolset to use until you have an app downloaded from an app store on your phone.
Regarding toolsets I'm against any toolset that is just using a webview as a shell and the whole app is a pure website. This will always feel subpar compared with a native app. I personally have in-depth experience using Cordova for hybrid apps - so I wouldn't use Cordova. I played around with Meteor a bit some time ago and the seemingles/easy server/client development and communication was great. The native app development looks like as it is just using Cordova, so it would also be no option for me. Framework7 is using Electron which is also just a wrapper without native UI components afaik. Ionic is also a Hybrid-Web toolkit without native UI components. For Xamarin I think .NET or C# development is required, so I would rule that out as to not reduce our potential developer base. NativeScript looks like too much a in-progress framework IMO.
So in my opinion this leaves us with ReactNative and Flutter. Unfortunately with both I don't have personal experience so it would great to get feedback of someone who already has in-depth experience using this toolkits. ReactNative only supports Android and iOS apps, but I'm quite sure you can leverage most of your business logic in a web React app as well. Of course the UI representation would need to be implemented again. But IMO you can't implement a good cross-platform, cross-resolution UI anyways. You'll always end with a compromise. So I think we should focus first on mobile and move from there to other platforms.
m52go
commented
3 years ago Thanks for a detailed and well-thought proposal. Such an app would provide a HUGE usability boost for existing users.
Beyond that, I'm skeptical that a mobile app that needs to connect to the desktop software (as it is now) can expand the user base. What's needed is:
I realize you mention that such an app could address some of these issues over time, but this assumes the right tools are developed in parallel.
Is there a way we can have some kind of assurance that at least some of these tools will be developed to a usable state at the same time? This is more meant as a question for Bisq the project as a whole, not specifically you @devinbileck...otherwise I'm afraid we will be stuck risking many development resources for little practical gain.
chimp1984
commented
3 years ago Probably worth to look at some mobile Bitcoin/LN/Liquid wallets or apps to see what they use. They did for sure some research regarding security as well.
Blocksteam Green (BTC and Liquid wallet) use Java/Kotlin and Swift. It is based on https://github.com/blockstream/gdk a C++ lib with native bindings to Java and Swift.
Aqua (Blocksteam BTC and Liquid wallet) uses Swift (is iOS only). Uses gdk.
Muun (the best BTC/LN wallet from UX IMO) use Java and Swift and Go for library code.
Breez uses Java for Android and Flutter/Dart for library code and Swift for iOS (iOS not publicly released yet)
BlueWallet (BTC and LN wallet) use React Native
Zap (LN remote control for LN node) use Java and Swift but iOS is not maintained anymore.
Sphinx (Messaging over LN) use Kotlin and Swift https://github.com/stakwork/sphinx-kotlin https://github.com/stakwork/sphinx-ios/blob/master/sphinx/Managers/Tor/SphinxOnionConnector.swift
Zeus is built on TypeScript and React-Native. It runs on both iOS and Android. No experience with it, seems more under development. https://github.com/ZeusLN/zeus
Any other relevant wallets/btc related apps which are cross platform? From my collection it seems Java/Kotlin and Swift are the most used solutions. For shared library code Dart/Flutter, Go, C++ are used.
cbeams
commented
3 years ago Acinq’s Phoenix uses a single Kotlin Multiplatform Mobile (KMM) codebase across their iOS and Android apps.
On Sep 14, 2021, at 5:59 PM, chimp1984 @.***> wrote:
Probably worth to look at some mobile Bitcoin/LN/Liquid wallets or apps to see what they use. They did for sure some research regarding security as well.
Blocksteam Green (BTC and Liquid wallet) use Java and Swift. It is based on https://github.com/blockstream/gdk a C++ lib with native bindings to Java and Swift. and https://github.com/blockstream/gdk
Aqua (Blocksteam BTC and Liquid wallet) uses Swift (is iOS only). Uses gdk.
Muun (the best BTC/LN wallet from UX IMO) use Java and Swift and Go for library code.
Breez uses Java for Android and Flutter/Dart for library code and Swift for iOS (iOS not publicly released yet)
BlueWallet (BTC and LN wallet) use React Native
Zap (LN remote control for LN node) use Java and Swift but iOS is not maintained anymore.
Sphinx (Messaging over LN) use Kotlin and Swift https://github.com/stakwork/sphinx-kotlin https://github.com/stakwork/sphinx-ios/blob/master/sphinx/Managers/Tor/SphinxOnionConnector.swift
Zeus is built on TypeScript and React-Native. It runs on both iOS and Android. No experience with it, seems more under development. https://github.com/ZeusLN/zeus
Any other relevant wallets/btc related apps which are cross platform? From my collection it seems Java/Kotlin and Swift are the most used solutions. For shared library code Dart/Flutter, Go, C++ are used.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
devinbileck
commented
3 years ago The choice of framework/language is tricky as we either utilize native languages to develop apps for each platform - which gives the best performance/UX but increases the amount of work, or we implement a hybrid approach - which reduces the amount of work but potentially at the cost of reduced performance/UX. With our limited development resources, I don't think it is feasible to maintain separate code bases for each platform and is vital that we reuse as much code as we can. Also, I think it is important to consider how easy it will be to attract contributors to the project based on the framework/language - which is why a common Javascript base would likely make the most sense as it is well known and allow us to support all platforms.
@ripcurlx:
I think the first prototype could/should be a simple rewrite of the current mobile notification app.
Good suggestion. It will be a good learning experience and allow us to see if the chosen framework will work for us. I can simplify milestone 1 to just implement push notifications.
I'm against any toolset that is just using a webview as a shell and the whole app is a pure website.
Fair enough, I trust your experience and judgement. I think your suggestion regarding a React/ReactNative approach sounds like a good compromise.
So I think we should focus first on mobile and move from there to other platforms.
I agree. We need to ensure that we are capable of supporting all platforms from the beginning though.
@m52go:
I'm skeptical that a mobile app that needs to connect to the desktop software (as it is now) can expand the user base
- ability to run bisq on rpi / umbrel / etc (enable growth in established markets)
As far as I know, we currently have a headless app which can be used with the API. Though I am not sure it currently runs on an rpi, we could focus effort to get it running and that would address these points.
- ability to run bisq on mobile in some self-contained way (enable growth in emerging markets)
This potentially could be done on Android using the existing Bisq code base. However is not possible on iOS without a rewrite into a supporting language - like was started with the Risq (Rust) project.
chimp1984
commented
3 years ago Acinq’s Phoenix uses a single Kotlin Multiplatform Mobile (KMM) codebase across their iOS and Android apps.
Thanks for sharing! Will try it out now... Here their blog post with background: https://medium.com/@ACINQ/when-ios-cdf798d5f8ef They use Swift also on iOS for the UI part.
chimp1984
commented
3 years ago we reuse as much code as we can
Yes, reusable code base for library code is absolutely needed. But I think that native implementations for the UI have emerged as standard for most mobile wallets. And doing the pure UI is not that of a hack as well IMO. Also comes with the question which type of developers we want to attract. As seen in the above wallet examples, only one wallet was using a javascript based approach. For other apps it might be different as security has less priority.
Though I am not sure it currently runs on an rpi
In the past some folks got the GUI Bisq running on rpi. But no idea if those build scripts still work....
- ability to run bisq on mobile in some self-contained way (enable growth in emerging markets)
This potentially could be done on Android using the existing Bisq code base. However is not possible on iOS without a rewrite into a supporting language - like was started with the Risq (Rust) project.
I doubt that the fully featured Bisq use case on mobile is feasible from a resource usage point of view. Having multiple connections to the BTC and P2P networks is just too expensive and keeping it running for longer drains your batteries. Stopping the connections when the app is inactive will cause delays when starting it up again (you re-bootstrap) leading to bad UX and instability. The only approach which could work IMO is to convert those P2P connections to client/server model connections where dedicated P2P nodes act as servers. On the BTC side I think it should work by just reducing the connections to 1 peer like with localhost (but not sure how stable it will be, localhost != remote via HS). The P2P network server can be chosen randomly and as its a hidden service connection there should not be much privacy issues. When trading its anyway an end to end connection to the trader not using the P2P/gossip model.
But beside that, iOS support will be tricky. Maybe multiplatform Kotlin allows to convert the java code base to Kotlin and make it then reusable in iOS using Swift for the UI. Still a huge enterprise not recommended to start if there are not a team of several experienced and committed fulltime devs for it. Introducing multiple implementations need to be avoided IMO as that would be a can of worms and we saw that already back then with the Risq prototype which caused an unintended dos attack on Seednodes by not implementing the complete feature set of the P2P network. Ah and Tor hidden service support on iOS was always an open problem. Don't know how current state is, but I am pretty sure that the Bisq model to run the Tor binary as external process will not work on iOS. So it will require a iOS library for Tor hidden services.
chimp1984
commented
3 years ago Read more about Kotlin Multiplatform. It sounds pretty powerful and Acinq’s Phoenix is using that approach. Tried out their Phoenix wallet and its next to Muun the best LN IMO.
Beside JVM and native targets KMP also support javascript as target.
Would be interesting to see memory and performance difference if Bisq would be compiled as native app with KMP instead running in the JVM - but KMP does not support java code base, so it cannot be tested. With Graal there was much faster startup and lower memory footprint but not much difference with performance. But Graal seems to early still. Phoenix tried it out but was too buggy
Here is a good overview as well for KMP: https://www.baeldung.com/kotlin/multiplatform-programming
Update: Seems performance for Kotlin Native is pretty poor unfortunately: https://discuss.kotlinlang.org/t/kotlin-native-vs-graalvm/14801/8
chimp1984
commented
3 years ago Has anyone experience with multi-os-engine (MEO)?
Seems an interesting approach. https://doc.multi-os-engine.org/multi-os-engine/2_Introduction/Introduction.html
Benefit over KMM:
Thesis about KMM vs. MOE vs. Flutter: https://www.theseus.fi/bitstream/handle/10024/148975/thesis_Jakhongir_Fayzullaev.pdf?sequence=1&isAllowed=y
Main difference of Flutter to MOE/KMM: "Flutter has a new architecture that includes widgets that look and feel good, are customizable, fast and extensible. As can be seen in Figure 43, Flutter does not use the platform widgets, but provides its own widgets and rendering mechanics."
React Native: "React Native uses JavaScript and instead of using slow WebView it uses a so- called bridge to accesses the native platform widgets (Figure 44). Widgets are typically accessed quite frequently, as for consistent 60 fps behavior it can be accessed for up to 60 times per second. And this is a big problem and bottleneck as it can cause performance problems"
So Flutter and React Native are similar by providing shared UI code. MEO/KMM require platform native UI implementation. It could thought use Flutter for that part but I think native UI code is a better model and I think just doing the dumb UI is not the huge dev effort.
chimp1984
commented
3 years ago Unfortunately MOE seems to be based on Java 7 and they work atm to use substrate vm instead of ART. https://www.noisyfox.io/substratevm-on-ios.html
Its really a shame that after so many years there is not solid cross platform solution out there as well for mobile development.
devinbileck
commented
3 years ago Thanks for the info. I had not heard of KMM but it sounds pretty promising and should be able to meet our needs. I think implementing a PoC would allow us to determine if it is the right approach for us.
chimp1984
commented
3 years ago Thanks for the info. I had not heard of KMM but it sounds pretty promising and should be able to meet our needs. I think implementing a PoC would allow us to determine if it is the right approach for us.
The main downside is that you cannot use java libraries, which adds quite some limitation if one consider a longer term goal for a more complex application (e.g. like bringing more Bisq features into it). So all code need to be in Kotlin.
I guess long term GraalVM could become the major option as there Oracle puts lot of effort into it, but hard to say when that will become usable for real world apps. MOE is also now targeting SubstrateVM (used by GraalVM) and have given up on their approach to use Android ART.
A completely different approach could be to keep the client really super thin (UI) and find a way to deploy on demand dedicated server apps. Blockstreams Greenlight is going in that direction (Lightning node service which gets on demand deployed when the user needs it, designed in a way to give max. privacy and security in the given constraints).
Or to hope that Apple give up some day their shitty politics and allow VMs to run on iOS. Otherwise they risk that powerful mobile devices get degraded back to dumb terminals. To maintain 2 different code bases for larger, complex applications is just too cumbersome, risky and expensive for most.
ripcurlx
commented
3 years ago The main downside is that you cannot use java libraries, which adds quite some limitation if one consider a longer term goal for a more complex application (e.g. like bringing more Bisq features into it). So all code need to be in Kotlin.
Are you sure about that? To me it sounds more like there is a 100% compatibility between Kotlin and Java libraries. https://kotlinlang.org/docs/java-interop.html
chimp1984
commented
3 years ago Yes Kotlin itself is compatible if run in the JVM, but for iOS its Kotlin/Native and there as far I saw is no support for java (libraries). For the Android target I guess you can use Java as it is not using Kotlin/Native for that.
https://stackoverflow.com/questions/59572289/using-java-library-with-kotlin-multiplatform
ripcurlx
commented
3 years ago Yes Kotlin itself is compatible if run in the JVM, but for iOS its Kotlin/Native and there as far I saw is no support for java (libraries). For the Android target I guess you can use Java as it is not using Kotlin/Native for that.
https://stackoverflow.com/questions/59572289/using-java-library-with-kotlin-multiplatform
True - missed that part: https://kotlinlang.org/docs/multiplatform-library.html#native
thunderbiscuit
commented
3 years ago Hello everyone.
It's my first time commenting on a Bisq repository and I'm just getting familiar with the project so take my thoughts with a grain of salt. I just saw the call on twitter to provide feedback and thought I might contribute with some of my expertise/experience with mobile.
I think Kotlin Multiplatform is becoming more and more a valid option for production, but it's still fairly early (relative to say React Native) in terms of maturity of the libraries, particularly if you want to target desktop with Kotlin Native (although I assume in this case desktop is covered), so you can expect a few bumps in the road. That being said, I do think it is growing at neck-breaking speeds and it's going to take away major market share for cross-platform development from React Native over the coming years (and certainly make Flutter/Dart look like a not-so-hot option in comparison). Kotlin is straight fire, and the only additional requirement for mobile is that a team builds a thin UI layer for iOS. This is not so different from React Native, where more often than not teams end up having to play with the native code of each platform to make required optimisations on all but the most basic of apps. Kotlin also can target JS/web, although I do not have experience with that and don't know how much of the code you could reuse from the mobile side of things.
As noted above, the ACINQ team uses KMM and has a full bitcoin library for KMM. I have not used it but it looks like it would cover all your bases bitcoin-wise. Given how integrated with the JVM and BitcoinJ Bisq is, however, I assume there would be growing pains associated with using a different library. But of course this is not mitigated by developing using React Native either, so if you want cross-platform you're stuck with using something else anyway.
React Native is a mature project, and many apps are built using it. It might not be purely native but I do think that in most cases it would be hard to tell from the user point of view. I also assume you could find more devs that know RN than Kotlin Multiplatform at this point. You also won't need to find someone to write the UI layer in Swift if you go the RN route. But it's a full departure from the JVM and I see that the Bisq ecosystem is built around that, so that should be taken into consideration.
My overall very humble take on this would be:
Finally, I would echo what has been said above and say that the amount of work required for this sort of thing should not be underestimated.
chimp1984
commented
3 years ago Great thanks for the input!
if you want to target desktop with Kotlin Native
As far I understand we can still use the jvm for desktop. Kotlin Native is only required for the iOS target as far I see.
The biggest issue I see is that java libraries cannot be used when Kotlin Native is used. The good thing is it helps to reduce dependencies to the absolute minimum and some low level stuff like crypto libs could be used via native bindings and we get much better performance as a plus. I just checked Protobuf and there seems to be a Kotlin code generator.
The project would start anyway with lower requirements and just enhance the current notification app a bit. In that stage I think it should be not too hard to get all requirements fulfilled and help to get hands on experience.
For the long term goal to get a full Bisq node on mobile I guess Bisq v2 will become hopefully ready in the meantime and development on that should consider the mobile use case as requirement from the start.
yshwanth
commented
3 years ago React Native should be better option compared to kotlin as it has more developer community and active.
nodejsjs
commented
3 years ago Jetbrains is working on a multiplatform UI toolkit called Compose, originally developed by Google for android. Compose by Jetbrains targets desktop and web https://www.jetbrains.com/lp/compose-mpp
Compose for Desktop targets the JVM, and supports high-performance, hardware-accelerated UI rendering on all major desktop platforms (macOS, Windows, and Linux) by leveraging the powerful native Skia graphics library. Native application distributions can be created with a single click.
I've tried out Compose for desktop and it works super great. Copy-pasting android compose UI code into desktop project worked flawlessly. Building targets for different desktop platforms is literally just one line of code and works fine. Maybe in the future jetbrains might port Compose to ios as well.
One way would be to build a cross-platform (android, linux, mac, web, windows) UI using compose. Have the business logic in kotlin multiplatform (no dependencies on java libs). Use shared c libraries for bitcoin/lightning stuff across platforms including ios. For ios, build the UI in swiftUI and reuse as much of the business logic from shared kotlin multiplatform code.
OR, do the entire thing (ui + business logic) in flutter. Flutter can target mobile, desktop and web too.
The problem with either approach is that we can't use any jvm libraries. If ios wasn't a concern, then I'd have suggested to go full jvm (android + desktop platforms) using google/jetbrains compose for ui and regular kotlin with jvm libs for business logic. Honestly, the current bisq project can slowly be refactored to reach this state. As for ios, the ui could be built with swift and use shared c libs for bitcoin stuff.
chimp1984
commented
3 years ago Thanks for the input! Sounds very promising! Who knows what the future with Apple brings, they have kicked out all BTC apps back in 2013 where there was no legal pressure. Now with likely upcoming hostile regulations Apple might become a no-goal for Bitcoin apps anyway. But until that is the case I think its still better to keep the iOS target as a requirement.
pazza83
commented
2 years ago Marking as approved but will leave open for ongoing discussion.
@devinbileck please consider if opening a project would be beneficial.
devinbileck
commented
2 years ago As this is a seperate application from the Bisq core code base, I have created a new repository and started defining tasks and milestones within. So a dedicated project should not be necessary.
Summary
As discussed in a recent dev call, improving and expanding the capabilities of the mobile app is a high priority.
The current mobile app is very simple and designed to only receive push notifications about important events from a running Bisq desktop app (see specification here). It has no means of communicating with the Bisq instance, and therefore is unable to perform any type of interaction with the Bisq network (i.e. managing open trades, placing/taking offers, etc). As a result, an architectural redesign will be necessary that will allow the app to communicate with a running Bisq instance (potentially headless) via the new API.
Another accepted proposal (currently stalled) exists to implement a fully native Android app. However, it is quite ambitious in scope and focused exclusively on Android.
This proposal suggests starting a new project to develop a fully featured cross-platform graphical user interface to the Bisq network supporting mobile, desktop, and web clients. Ideally incorporating the UI designs provided by Pedro, as shown in this proposal. Not only will this allow us to improve the mobile app, but it potentially could increase Bisq's user base by supporting more platforms and potentially addressing the biggest issues with the existing UI - namely UX and performance. It should also open up other possibilities such as potentially integrating a Bisq client into common Bitcoin node-in-a-box implementations such as Umbrel.
Goals
Project Plan
The project plan is to provide incremental releases towards a fully featured cross-platform app with an initial MVP release that should be achievable within a relatively short period of time, given sufficient development resources.
Although the ultimate goal is for the mobile app to integrate a Bisq instance natively and not require connecting to an external instance, that is a major undertaking and beyond the scope of this proposal. However, design considerations shall be made to hopefully support that in the future.
Considerations
A preliminary technical analysis has been done to evaluate various options and answer any potential concerns.
Requirements
Risks
Budget
As with all other contributions, compensation will be made for “delivered” work based on the value it provides to users, while staying within a reasonable budget - potentially splitting up compensation over multiple cycles if necessary. The exact amount per cycle is hard to estimate at this point with unknown available development resources.