-
Notifications
You must be signed in to change notification settings - Fork 16
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
Develop a fully featured cross-platform graphical user interface to the Bisq network supporting mobile, desktop, and web clients #342
Comments
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! |
How would a Web based application work in terms of storing and processing payment related data? |
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. |
@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. |
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. |
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 Zeus is built on TypeScript and React-Native. It runs on both iOS and Android. No experience with it, seems more under development. Any other relevant wallets/btc related apps which are cross platform? |
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.
|
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.
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.
Fair enough, I trust your experience and judgement. I think your suggestion regarding a React/ReactNative approach sounds like a good compromise.
I agree. We need to ensure that we are capable of supporting all platforms from the beginning though.
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.
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. |
Thanks for sharing! Will try it out now... |
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.
In the past some folks got the GUI Bisq running on rpi. But no idea if those build scripts still work....
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. 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. |
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: Update: Seems performance for Kotlin Native is pretty poor unfortunately: https://discuss.kotlinlang.org/t/kotlin-native-vs-graalvm/14801/8 |
Has anyone experience with multi-os-engine (MEO)? Seems an interesting approach. Benefit over KMM:
Thesis about KMM vs. MOE vs. Flutter: Main difference of Flutter to MOE/KMM: React Native: So Flutter and React Native are similar by providing shared UI code. |
Unfortunately MOE seems to be based on Java 7 and they work atm to use substrate vm instead of ART. Its really a shame that after so many years there is not solid cross platform solution out there as well for mobile development. |
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. |
Are you sure about that? To me it sounds more like there is a 100% compatibility between Kotlin and Java libraries. |
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 |
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. Kotlin MultiplatformI 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. LibrariesAs 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 NativeReact 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. IMOMy 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. |
Great thanks for the input!
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. 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. |
React Native should be better option compared to kotlin as it has more developer community and active. |
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
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. |
Thanks for the input! Sounds very promising! |
Marking as approved but will leave open for ongoing discussion. @devinbileck please consider if opening a project would be beneficial. |
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.
The text was updated successfully, but these errors were encountered: