Bisq Easy Mobile #2665
Replies: 14 comments 29 replies
-
|
We could also consider an alternative approach: We support to run both clearnet and tor (or i2p), so the relay node could run both clearnet and tor and will be accessed via clearnet from the mobile clients. The mobile client need to run then the Bisq p2p network code but it is not a "full" node as it does not accept incoming connections. This distinction would require some extra work in the p2p network layer to treat those 2 classes of nodes differently (might be its not needed as any connection to such a non-full node would just fail). The benefit from such an approach would be that it perfectly matches the existing p2p network design and multiple relays would share the load of the mobile clients. There is still the leaking of IP addresses, but the other concerns should be disarmed to a large extent (still some issues as a small number of full nodes would represent some centralization). The downside is that it requires to run the network module code (and more), thus require to use bisq2 as dependency to the mobile apps. For Android that should not be a major issue as its JVM based. For iOS we would require Kotlin Multiplatform and then it has to be investigated how much extra effort is required to get all working there. Any OS specific part (like sockets) needs its own implementation for iOS. I still estimate it is not that much of an effort as we don't use much of specialized OS specific stuff, but still an effort to be considered. The core difference from that model to the REST-API based, is that here the tradeoffs are limited to a smaller number of peers (>=1) and leaking the IP address to all those full-node peers. Furthermore anyone could run such a full node and without added restrictions that would add some risks to the users to end up a spy-agency node. As the trade-offs and potentially required extra effort for clearnet are a concern we also could investigate the options of Tor for iOS. It might turn out to be not much more effort. |
Beta Was this translation helpful? Give feedback.
-
|
I think this is a much better idea. All in all to add up on this my 2 cents:
|
Beta Was this translation helpful? Give feedback.
-
|
One area where we might need changes is the way how we manage data. Atm we use our custom file-based persistence framework. We load at startup all data in memory, which is also for desktop already a bit heavy (I guess 80% of the RAM consumption comes from that data) and this will grow over time with more users. We might need to re-consider to use a DB solution and see how we deal with the issue that we don't want to do queries to the DB all the time as it would be too slow for most use cases. All in all I think efforts in the REST API path would lead in the wrong direction to centralized and trusted services and as no code exist for that yet, it would be considerable effort anyway. Furthermore as it would be an alternative code path not used in the desktop app we add risk for missing updates and changes (Bisq1 is suffering from that as well when new changes are not applied and tested at the API). Going the P2P path we reuse our existing code base, maybe it needs some improvements (DB, network) which benefits the desktop as well. We know that tor support on Android works, so the privacy trade-offs can be avoided in that case or be left to the user (with tor startup and re-connections will be slower). For Apple it seems feasible that we can support with KMP and implementation of the required system interfaces like sockets the clearnet p2p version. For Tor it would be some extra effort which need to be considered if worth the costs/risks (no official Tor impl., Apple might block the app at any time and there is no alternative to the App Store). I would suggest we kickstart a POC where we create an android project adding the main dependencies from Bisq2 (network) and try to get just a network node running on clearnet/localhost as a first milestone. After that we can add the remaining dependencies needed for Bisq Easy use cases. If we achieve that, we can extend it to clearnet - remote node running Tor+clearnet and get the real p2p data via that node. Once that is achieved we can get Tor integrated and get the Tor-remote node model working. Next would be to transform that into a KMP project (could be also done initially if not too complicate) and adding iOS integration. After setup is done for iOS we need to get the native implementations for the missing OS specific interfaces (e.g. sockets,...). Get the network with clearnet/localhost working. Then get the cleanet/remote node working. If we arrived at that stage the POC can be considered successful and we can start implementing a minimal viable version of Bisq Easy for mobile. Further tasks:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks @HenrikJannsen . I read your comments carefully. I can help with Data management in Bisq as well.
and we go from there? |
Beta Was this translation helpful? Give feedback.
-
|
Look no further, I am already 75% done creating a Bisq app. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @KewbitXMR that's great news, let me know if you want some early review or collaborations more than happy to have a look! |
Beta Was this translation helpful? Give feedback.
-
|
just leaving it here for anybody following this discussion to review - @KewbitXMR approach is a flutter package --> https://pub.dev/packages/bisq - haven't looked into it yet but will soon |
Beta Was this translation helpful? Give feedback.
-
|
@KewbitXMR hey Kewbit, thanks again for your proactive approach to kickstart a solution for this initiative. I took some time yesterday to review your work. Below you have my own logs, but just a headsup, I couldn't find any docs to your work and the repository has no code shared yet (is it the right one? https://github.com/KewbitXMR/flutter_bisq) so it was not an easy job, I used VSC to check the code of the lib as I was testing it. My question to you is, how did you calculate the 75% done estimation you claimed above? it seems like quite raw yet. Initial review for flutter lib bisq: ^0.0.2
|
Beta Was this translation helpful? Give feedback.
-
|
The only reason I downvoted this is because the topic did not start with a problem, if there is no problem what is there to solve? Making a less complex, easier to attack, more manageable to the average developer all sounds like a great bandwagon to ride, and I won’t argue that Bisq 2 looks better and is more intuitive but all that means nothing if the protocol is trash. So my question is what is wrong with the current Bisq, if there is something wrong, why can’t a solution be implemented fix it rather than rebuild entirely. I would expect to at least see someone take an attempt to tackle the infamous trilemma on any new developments.
Especially if the community it expected to fund them throughout, sometimes the community are excited about an idea but don’t understand the real technical backing.
It’s feasible, there is not too much data to handle if it’s dealt with appropriately, storing protobuffers (as proto3Json) in an SQLite database indexed only by the important keys will be sufficent, even keeping the file system as is. To address the RAM issues I’m sure that mostly from the wallet syncing as they jump back on again, please let me know if that’s not the case because we were having the same problems on the other side of the playpen.
What metrics do you have to support this as being a problem?
I can give you some feedback on this and it’s not great, but it can work. On iOS you get about 1 APi call every 15 minute max, and no background process can stay open. Additionally, that request is only allowed to last between 15-30 seconds. If we consider that it might take that amount of time to bootstrap to Tor or I2P for that message, then by the time a connection is established we may have enough time to important notifications like new trade offers and chat messages. The alternatively is to implement various ways for the end user to receive notifications, none of this would be centralised, if they wanted to recieve email on a new trade or chat message they’d supply their own SMTP servers as part of their node config, or they could supply a matrix and simplex account to receive the notifications. I will actually update this who are interested in this once I’m confirmed done with the iOS side of things but I’m focusing on the privacy devices / OS currently as requested by the XMR community. Finally, you say you have a PoC, are you willing to share it? |
Beta Was this translation helpful? Give feedback.
-
|
After further discussions I think it is required to lay out more in details the specifics of different models as well as constraints and goals. GoalsMust have features:Offer a full trade experience in the most minimal formThis includes:
Clearnet connectivityEven if we have Tor support the fact that establishing a Tor connection can take considerable time it will hurt the user experience. It has to been seen if keeping Tor connections open when the app is in background is feasible from a resource management point of view. Mobile notifications for relevant trade eventsThis need to be further investigated but as it is a new feature not present in Desktop yet, it is less relevant to our main objective of the current investigation to see what is the best path to bring Bisq Easy from Desktop to mobile. Good to have features:Tor supportTechnically feasible on Android. But will require adjustments on our tor code and build infrastructure. iOS supportiOS support would be good to have, though we need to consider the costs and risks and if those pay off. Support for other mobile OSWe should check out also the distribution rate for alternative systems. Linux based systems or Huawai's mobile OS might become more relevant in future as the US controlled duopoly might have overextended their power position and more users are looking out for less invasive and totalitarian systems. The geopolitical developments require that the Global South develop more of their independent IT infrastructure. Building up reputationIt would be good that the mobile user can build up reputation using their profile ID. As this use case requires to run Bisq 1 we can assume that those users also have Bisq2 installed. Thus the easiest option would be to add a UI feature to Bisq 2 to use an external profile ID (from the mobile app) in the UI for building reputation. The messaging to the oracle node can be then done inside Bisq 2. On the mobile side we only need to export or copy the profile ID (maybe also the private key if needed for sending the data to the oracle). Not supported featuresAt least for a first version we do not plan to support that Desktop users can reuse their profile on mobile and go back and forth between Desktop and mobile. This would require a synchronization mechanism for the private data as well as a lock mechanism to avoid both models are used in parallel. So far I don't see any feasible solution for that beside a server side hosting of the data directory). ConstraintsWe have to keep in mind our limited dev resources when selecting the most feasible model. In case the mobile app cannot re-use a large part of the existing code base we have to keep in mind that maintenance costs and risks from compatibility issues when developing parallel implementations of core features. ModelsFull node modelThis model requires that we can re-use most of the existing Java code base. It is driven by a full P2P network node with Tor support at least for Android but with adjusted configurations in terms of number of connections and other network specific metrics. Using TorIf the mobile node use Tor the privacy and security model is basically the same as with the Desktop version. The main difference will be the lower number of connections for limiting resource costs. Using clearnet (we call that model now Light node model)For clearnet support we need to have some clearnet enabled nodes (any node can run on multiple transports, e.g. clearnet and tor, but for clearnet it must be reachable from outside, which is usually not the case in home environments without manual setup for port-forwarding, but on VPN servers). This requirement will add a bit of burden to Bisq to provide clearnet enabled headless nodes (technically the same as seed nodes). Those have less privacy protection for the operator than Tor-only nodes. The outbound connection to other clearnet nodes is fully functional, just the inbound connection will not work as the mobile node is not accessible by its IP address. This should not cause any problem. It only requires a custom configuration of the peer management as by default it seeks a balanced level of inbound and outbound connections. If another peer sends a direct message as it is the case in the trade process, the send message attempt will fail, but then the message gets encrypted and distributed as mailbox message and broadcasted to the network. By that it reaches the mobile node via their outbound connections and the message gets decrypted and applied. It is the same model as if the peer is offline (not reachable via direct message). Security and privacy risks when using clearnetA malicious clearnet node could hold back messages to the mobile node, which could lead to failures in the trade process and in the worst case to a ban and loss of investment in reputation in case of a seller. Though, this is unlikely as there are other communication channels where a seller could reach out to support. From my POV the privacy and security risks are rather low and do not require a BSQ bond for node operators. Though Bisq need to provide at least the min. number of nodes for sufficient network resilience (I would estimate at least 4 nodes). PersistenceThe persistence model used in Bisq 2 is likely not appropriate to mobile and we need to build some abstractions around that. I don't expect that this is a major roadblock. Candidates for implementing that modelFrom preliminary research it seems Gluon is the most promising candidate to make that model feasible. Kotlin Multiplatform cannot use dependencies in form of jar files, but would require to port the Bisq 2 code base to Kotlin and to use specific libraries (e.g. for networking and concurrency) to enable compilation to the iOS target. There would be for sure more issues on the path with 3rd party libraries we use as well with crypto libraries. The effort and associated risk with such a huge change is from my POV outside our possibilities. In case we drop iOS support we have more options to go just Android only. In that case a plain Android project might be the most feasible option. Delegated node model (we used before "Light node model" but that is better suited to the full node model with clearnet)In that model we would delegate the networking part to a relay node and use a REST API between the mobile client and the relay node. It still will require to re-implement a considerable part of the code base (crytpography, proof or work, offer domain, trade process, payment methods, persistence). If that model is chosen we cannot just reuse Bisq 2 code for those areas as those will have further dependencies, but rather we need to re-implement a minimal version of all the required features. This is considerable effort and lead to a parallel code base with future costs for maintenance and compatibility risks. Relay nodeA relay node would be a headless Bisq node with a REST API exposed via clearnet and Tor. Security and privacy concernsThe public data can be accessed without privacy issues beside that the relay node learns about the mobile node's IP address in case of clearnet. Similar as in the full node model, I do not see severe security risks and the privacy risk can be lowered by using Tor. Candidates for implementing that modelKMP might be a good candidate here, as it makes it easier to copy Java code from Bisq 2, convert it to Kotlin and reduce it to the minimal needed as a strategy to re-implement a big part of the code base. As that code base does not contain the P2P network part one hurdle is removed, but still a lot remain and I would assume we only learn by doing it how much effort it really will be. I estimate its considerable effort. For sure there is high risk of uncertainty of the overall effort. Thin client modelThat model consists of a full node with a server offering a REST API (headless or Desktop) and the mobile client as thin UI client. Candidates for implementing that modelThe mobile client can be implemented in any technology. KMP might be a good candidate here as well. There is no requirement to re-use or re-implement Bisq 2 code. Use casesThat model could to be used in a "friends and family" context for on-boarding newbies. An experienced Bisq user provides that full node/server and the newbie connects to that, fully trusting that provided node (as its for friends and family that should not be a concern). The other model would be that users run their own private server and use it for themself, thus rendering the privacy and security issues obsolete (beside the secure connection to the API). QuestionsThe main question here is the usefulness and size of potential market (in case of friends and family use case). So this option seems to me mostly a "nice to have" add-on, without much potential to extend to new markets or users. I would also assume users would be disappointed that Bisq Easy has not brought the full trade experience without the need to run a full node to mobile. ConclusionMy personal conclusion is that the Full node model offers the most benefits with least costs. It is as close we can get to have the same user experience, level of privacy, security and decentralization as the Desktop version. It enables us to reach to new users and markets where Desktop computers are not much used. The main hurdle here is, if there is a feasible technical solution possible. Our first hope for KMP failed unfortunately and it has to be seen if the remaining candidates which allow reuse of java based source code in mobile environment can hold their promise. The Light node model, is for me a bad compromise on all levels and to introduce a parallel implementation is for me basically a no-go. The Thin client model is technically the easiest and most feasible but does not provide the mobile experience one would expect (you dont want to run your Whatsapp Desktop client when using it on mobile). I consider the added value and options to reach new users and markets as rather limited and to me it is questionable if the costs justify the gains in that model. |
Beta Was this translation helpful? Give feedback.
-
|
Here are a couple resources arguing the case for the "thin-client model" as it's called above.
A ChatGPT-generated summary of the transcript of (2) follows. It's not great and is in a couple places wrong or nonsensical, but it does give at least a general impression of the position I'm taking and what topics get covered in the video. chatgpt transcript summary of video (2)1. IntroductionThe speaker acknowledges being late in responding to Henrik's original post but explains the use of video due to time constraints. They plan to respond to the key points Henrik raised and focus on arguing for the thin client model for Bisq Mobile. The speaker clarifies they won't address every point, only those relevant to their argument. 2. Must-Have FeaturesThe speaker agrees with Henrik's list of must-have features, particularly the importance of modern notifications for trade events on Bisq Mobile. They argue that the Bisq backend should handle notifications efficiently, making them a reasonable assumption for a thin client setup. The speaker takes it for granted that Bisq Mobile will include opt-in and configurable notifications for all relevant trade events. 3. Clear Net ConnectivityThe speaker finds clear net connectivity less important due to their confidence in Bisq’s vision for connectivity. They argue that issues like slow Tor times and heavy Tor overhead aren't concerns under the thin client model because Bisq will manage the necessary connectivity in the backend. 4. Good-to-Have FeaturesHenrik's list of good-to-have features, such as Tor support, is mostly left aside by the speaker, as they don’t see Tor support as necessary for the mobile client. However, the speaker considers iOS support absolutely essential, arguing that excluding iOS would alienate a significant portion of the user base. They also mention that Android and privacy-focused distributions like F-Droid are implicit, given the nature of the mobile platform. 5. Support for Other Mobile Operating SystemsThe speaker brushes aside the need for support for operating systems beyond iOS and Android, assuming that privacy-focused Android distributions are already covered. 6. Desktop-to-Mobile Profile SyncHenrik mentioned that desktop users won’t be able to reuse their profiles on mobile in the first version. The speaker explains that this wouldn’t be an issue under the thin client model since all devices would connect to the same Bisq node, eliminating the need for data replication or synchronization. 7. The Full Node vs. Thin Client ModelHenrik's discussion of a full node model is countered by the speaker’s preference for the thin client approach. They emphasize that with the thin client model, users will remotely connect to a Bisq node (either their own or a trusted node), bypassing the need to run a full node on a mobile device. This is presented as simpler and more feasible than the full node approach, which comes with heavy performance, networking, and synchronization issues on mobile devices. 8. Friends and Family Use CaseThe speaker agrees that the thin client model is particularly useful for onboarding new users in a "friends and family" context. Experienced Bisq users could host their own full node and allow less technical users to connect to it. This offers a practical, small-scale centralization approach that enables newcomers to trust a known Bisq node operator. 9. Market Size and PotentialHenrik raised concerns about the limited potential market for the friends and family use case. The speaker responds by admitting that while they don’t have hard data, their intuition suggests a solid opportunity. They argue that users often don’t know what they want until they see it in action, so clearly articulating and demonstrating the value of this model could sway opinions. 10. Managing User ExpectationsHenrik expressed concerns that users might be disappointed by the thin client model, expecting a full trading experience without needing to run a node. The speaker acknowledges that if Bisq marketed the app to general users, it might indeed be disappointing. However, they clarify that the intended audience for Bisq Mobile is existing users and experienced Bitcoiners, who understand the need for a backend node and won’t be deterred by this requirement. 11. Privacy and Security in a Thin Client SetupHenrik highlighted privacy and security concerns if users rely on trusted third-party nodes. The speaker counters that this is a reasonable trade-off in the friends and family context, where trust is inherent. They also argue that users who value privacy and security could run their own nodes on a VPS, personal server, or other setup, maintaining full control over their Bisq environment. 12. Technical Challenges of the Full Node ModelHenrik argued that the full node model provides the most benefits with the least costs. The speaker disagrees, arguing that building a full node mobile experience is fraught with technical challenges—especially when trying to make it cross-platform and performant. They predict that pursuing the full node model would be a "fool’s errand," resulting in numerous hurdles with little return, based on their own experience. 13. Benefits of the Thin Client ModelThe speaker reiterates the advantages of the thin client model, highlighting its simplicity and practicality. With this model, Bisq would work similarly to Bitcoin wallets, where mobile users connect to a backend server. They compare this to well-known wallet apps like BlueWallet or Sparrow, where users connect to a server rather than running a full node on their phone. 14. API Development for BisqThe speaker stresses the importance of building out a robust API for Bisq, which would open up new possibilities, such as bots, web UIs, and better desktop and mobile integration. They acknowledge that this is a significant technical effort but argue that it’s worth the investment to make Bisq more versatile and accessible across platforms. 15. Final Thoughts on the WhatsApp AnalogyHenrik used the analogy that people wouldn’t want to run WhatsApp Desktop to use WhatsApp Mobile, hinting that requiring a full node for Bisq Mobile could disappoint users. The speaker pushes back on this, pointing out that the better comparison is with Bitcoin wallets or Lightning clients, which also require backend infrastructure. They argue that the need to connect to a node isn’t a deal-breaker for the intended Bisq audience, as long as the communication and expectations are managed properly. ConclusionThe speaker concludes by reinforcing their stance that the thin client model is the best approach for Bisq Mobile. While it might not meet the expectations of non-technical users or those unfamiliar with Bitcoin infrastructure, it serves the needs of Bisq’s current users and aligns with the broader Bitcoin ecosystem. They caution against wasting too much time pursuing the full node model, which they see as impractical, and advocate for investing in the thin client approach, including the necessary API development, to unlock Bisq’s full potential. |
Beta Was this translation helpful? Give feedback.
-
|
Following up further on this point:
I addressed it originally in the video here, but failed to mention perhaps the most important counterpoint. I agree that the thin client model risks entirely-new-to-Bisq users being disappointed when they download the app, open it and realize it won't be functional unless and until they have a backend Bisq node to connect to. That's what I already discussed in the video. What I didn't say is that I think the far greater risk is that actual and longtime Bisq users will be disappointed when they open Bisq Mobile for the first time and realize that it creates a completely separate node with no way to connect to and control their existing node. I (as a Bisq user) do not want to set up a separate Bisq client on my phone. I want to access my existing node remotely. Which is to say that we run the risk of disappointing users either way we go. I'd rather make sure that our existing user base regards Bisq Mobile as immediately useful to them and as a way to get more value out of their existing Bisq node. I'd rather get them in a place where they're using Bisq Mobile all the time as a more convenient way to do all the stuff they would have had to be sitting at their laptop for in the past. If they're actually using the app on a regular basis and loving it, then we'll have the opportunity of taking them on a journey of using the app for new and different use cases, like "becoming uncle jim" for their friends and family. If they dismiss the app out of the gate as "not useful for me because I don't want to run a second node", we'll have lost that opportunity. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, to not be able to switch between desktop and mobile would be not great. But other as initially assumed it is actually not that difficult to solve. Here an idea how it could work: When shutting down the app we zip the relevant data, encrypt it, assign a version and pub key and send it to one or more storage services. This happens after the p2p network has been shut down, so it is guaranteed that no new data would alter the persisted data. The version gets incremented with each shutdown and is persisted locally. This storage services could be a dedicated node operated by Bisq, could be an extension of existing nodes (seed, oracle, monitor,...) or just a small headless node running on the users computer if he can assure that the computer is always online. The storage node is a very simple http server behind tor with a simple API for accepting a storage request, pruning outdated data and removing data (if signature is valid). Very similar as network storage nodes. But more simple as not a p2p node but just a http server. When the mobile app starts up, it requests from the storage node(s) the latest version and compare it to its local to see if sync is needed. If so, it decrypts it using its private key and send a remove request (with the signature attached to proof ownership). It updates the local version and replace the local storage files with those from the server. Only after that is completed it continues to bootstrap to the network. This ensures that no network messages would interfere with the sync process. At shutdown it follows the same process as above. If there are repeated shutdown/start at the same platform, it sees that the local version is the same, thus no need to sync, but it sends the remove request to the server to prune the unneeded file. It is not supported though to run both in parallel. If both are running, both apps would use the same onion service, which would lead to indeterministic behavior (I guess tor acts like a random load balancer in that case, some messages might arrive at one node and others on the other node). Details would need to be worked out, but I think that's a feasible solution and not overly complicate and requires only a very light weight infrastructure node (or additional feature to existing nodes). |
Beta Was this translation helpful? Give feedback.
-
|
@HenrikJannsen thanks for summarizing the options discussed so deeply, bringing also the knowledge from Bisq infrastructure in. I'm still digesting this big post, for now I'm just gonna drop some small contribs:
|
Beta Was this translation helpful? Give feedback.
-
|
If it turns out Gluom or CodenameOne is a feasible option it can be used for the full node options and brings back support for iOS. For the Light node model, my main concern is the re-implementation of large parts. Its hard to me estimate how much that is but a very rough guts estimation might be 40% network code and 60% rest (using lines of code might give more insight but we need to consider that mobile would not impl. all of Bisq 2 code). So we do not gain that much by outsourcing the P2P network part. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure how feasible they are yet, people that used it say depending on what you are trying to port to mobile from Java the build times can become a nightmare, and the result very poor performance why. But definitely worth a POC Gluon
CodenameOne
|
Beta Was this translation helpful? Give feedback.
-
|
hi @cbeams, thanks for your feedback and videos. Here my response: Multiple aspectsI think we are dealing with multiple aspect and best to tackle them separately.
APIThe benefit and need for an API is undisputed. The only question is the priority and when it really is needed. So far we had not sufficient use cases for it beside the existing API for oracle node and monitoring. Full node model@Rodave got some results with CodenameOne but it would require Java 11 (now we use Java 22), which is probably a prohibitive requirement. To limit the full node model to Android is a very feasible option. It requires Java 17 which was until recently the target version for Bisq 2. To revert the Java 22 feature changes is not that much work (I assume a couple of hours). There will be for sure some more issues (persistence for instance) but I think those are all feasible to resolve and I do not see any real critical showstopper so far. Note, that this model allows the user to use tor or clearnet. The clearnet option requires that Bisq (or the user) runs a headless node with clearnet + tor enabled. This should be a minor dev effort and also an acceptable cost for providing that infrastructure. Details need to be worked out but my estimation is that this does not cause any showstopper. Thin client modelAs it seems that for iOS the full node model is unfeasible, the only 2 options are to either drop iOS or to use the thin client model. The Thin client model can be then also added as optional mode for Android, giving the user more flexibility. Onboarding friends and familyI would consider that as a new product based on Bisq Easy and the mobile Thin client model as well as some additional features (relay/proxy node, hierarchical user management, xPub key support,...). Bisq Easy was itself an experiment and for some features like the Learn section the market-fit test is still pending. Mobile UIFor sharing code we could use KMM. I am not familiar enough to estimate the extra effort/complexity to enable KMM UI for a pure Android project as well as on the iOS side. I suspect that make things and build process at least more complex. Potential next stepsI think first we should figure out if we want to continue to investigate the feasibility of the cross platform options. Maybe @rodvar could give his conclusion from what he learned so far. In case we drop that effort, I think next thing is to verify the assumption that a pure Android project is feasible for re-using Bisq 2 code base in a time-boxed POC trial. Once (and if) that is confirmed, we can look into the best solution for the UI code (KMM or native or other). For the Thin client model the precondition is the API. So we should start to find a dev/team who are committed to that task. Once the API is sufficiently implemented for some mobile use cases one of the mobile devs could take on the integration. Once the Thin client model is in place we can move towards the Onboarding friends and family product. Of course we can do stuff in parallel as far we can afford it. |
Beta Was this translation helpful? Give feedback.
-
|
My 2 satoshis in all of this: TL/DR;
Some other notes worth mentioningIt is not correct that Marketshare for iOS its 50/50 with Android. That was the case many years ago but in recent years the Android has eaten the apple in 70%+. However, its worth mentioning that in developed countries it's still 50/50 or slightly inclined towards Apple. (more data on this) Once again I would like to back @cbeams in terms of his overall idea and big picture of why, for whom and what are we building. His videos are full of a lot of spot on phrases too long to write down. At the same time, I would like to back @HenrikJannsen in the sense that compromising the security & privacy of Bisq is a no-go by all means So it all beg the question, can we build a secure API/infra that allows us to just focus on thin shared code mobile solution which is obviously the most cost-efficient/effective solution in terms of time and money? If the answer is yes which looks like it is from recent convs that it is, then I would just focus on:
And leave the full node Android project out of the "Bisq Easy Mobile" discussion if that makes sense? And then see if we can do both in parallel or if we need to choose, then I would definitely solve "Bisq Easy Mobile" first in words of @cbeams (hope I remember properly from the video) Cheers! |
Beta Was this translation helpful? Give feedback.
-
|
@rodvar wrote:
Yes, that makes sense to me, and here's what I would roughly suggest in terms of order of operations:
I believe the work described above is a significant, substantial effort and deserves full focus by the mobile dev team. I think trying to also implement a full node client on android at the same time, or in parallel, or with top priority and giving the effort I've described above lower priority are all recipes for failure. I believe the effort required to port Bisq 2's core to an Android (and only Android) environment is a massive distraction from the effort described above and will end up bastardizing the Bisq 2 codebase in the process. I can't emphasize enough how much I think attempting to do this is the wrong direction. If we want to (try to) support a full-node mode on Android, why not do that after we've implemented the API as described above, and after we've built out a Mobile GUI that can talk to it? Then "all we'd need to do" would be to actually run a headless node in-process with the Android Bisq Mobile app and have that local node serve as the backend Bisq node. I still imagine this won't work well, but if it does, then we'd have the best of both worlds, and we'd only have needed to implement one GUI that always talks to a Bisq node via its API client libraries—even if that Bisq node is running locally right there on the phone. In any case, this would imo clearly be a risky experiment to try after we've gotten the stuff we know we can do done with regard to building out the API and implementing some MVP use cases. @rodvar wrote:
Thanks, @rodvar, for the fact check. I was very interested to look into the resource you shared. This is what I found there: Worldwide, you're right, it's a dramatic difference with Android at 72% and iOS at just 28%, but indeed the picture can be quite different in different regions:
In Europe and especially in North America, it's much closer to parity between the two platforms. And while we might have aspirations of reaching the whole world with Bisq, I think it's roughly correct to say that most of our users today are in the European and North American regions. (A marked exception to this would be Brazil). In any case, this just emphasizes the importance of being clear about who we're (at least initially) building this for. I believe that across Bisq's user base of experienced bitcoiners in the "developed world", a great many of them would report that their friends and families overwhelmingly use iOS devices over Android devices. I know in my own circle of friends and family—the people I would want to onboard to Bisq—it's at least a 10:1 ratio of iOS to Android users. And furthermore, it's the less-technical among them—the ones who'd benefit most from assisted onboarding—that are the iOS users. I don't think I'm alone in this experience. I think many, and perhaps a majority of Bisq's most engaged users would report something similar in their own lives, and that's why I think we should build tools for them first. |
Beta Was this translation helpful? Give feedback.
-
@HenrikJannsen I enlarged on this on matrix, but just to leave a public note on it. I'm referring to what @cbeams described as “practically/pragmatically not doable.” Even if we manage to overcome the technical hurdles of adapting the Java 22-based Bisq2 core, which was originally built for a desktop app, to fit within the constraints of an Android APK (limited to Java 17), we then face a whole new set of challenges that are specific to mobile runtime environments. These include:
These runtime challenges introduce new complexities that make it a very difficult and resource-intensive project to undertake. Makes sense? |
Beta Was this translation helpful? Give feedback.
-
I agree with this generally speaking for the reasons stated in my previous comment. When I said before "leave full-node project out of Bisq Mobile discussion" I meant exactly that, create a new discussion and see how many people engage with it. If we have a lot of enthusiasts on the idea jumping in then great, we might be able to do it in parallel. If we don't, then it will have to wait (at least for us to jump in :) ) till we get at least the core of Bisq Mobile to a beta phase. Maybe we should bring this to a more general matrix discussion to see what involved Bisq people think about it? Henrik suggested doing a poll above. We obviously want the people involved in the our DAO to support us with whatever path we end up taking. |
Beta Was this translation helpful? Give feedback.
-
There are several options between 100% full node and reduced p2p node.I think we can even leave it to the user how far they want to go:
|
Beta Was this translation helpful? Give feedback.
-
|
@HenrikJannsen with those simplifications it place it becomes much more appealing. I guess I'm concerned about the performance of our current Bisq2 modules in the app. But with those things in mind we could definitely kickstart a pure Android POC, I would be happy to take that, Maybe I could be the first line for it and do tech barrier removal and support for Buddha to kickstart the KMP thin client. |
Beta Was this translation helpful? Give feedback.
-
|
It is a bit frustrating to me how quickly the model which mirrors best the essence of Bisq gets dropped. Bisq never went the easy or proven/industry way. And managed to invent new solutions and overcome challenges. I don't think that the mobile app is as challenging as many other things we achieved like the DAO,... I suggest we make a survey to learn more about our users and contributors preferences. And just to make clear, those 2 models are not exclusive but a matter of priorities and cost/benefit ratio. I totally support that we do both. But I totally disagree to drop the full node model before we have even tried. I think I have explained sufficiently about technical backgrounds and laid out my arguments. I leave if from here and log off from that discussion and focus on other areas or if I find time give myself a shot for the Android full node model. |
Beta Was this translation helpful? Give feedback.
-
|
Getting the headless node running is the same as getting the complete app running. |
Beta Was this translation helpful? Give feedback.
-
|
Hey guys @cbeams @HenrikJannsen , I'm hoping that we can try to arrive to some consensus here so that we start focusing our efforts collaboratively cause at the end of the day we are all trying to contribute to get Bisq in mobile. Things we can say we all agreeFull / Light node mobile
Conclusion/next lines of dev: Make an Android Native POC incorporating bisq core modules till we can get clearnet p2p bisq connectivity Node-less Thin client + Bisq API (bisqd)
And finally, some of us only are ok with working with one but no the other option and that's ok. It all contributes to the same good cause. As of myself, I would like to contribute in both options with the simplifications we have decided in this conversations starting today. Do you guys subscribe to this? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for summarizing and helping to find consensus.
I dont agree on that. Even the 8 connections over Tor model is possible. But the options to reduce connections (4 is sufficient) and to use clearnet makes it even more feasible to run on mobile. Bisq 2 is quite lightweight and the main CPU consumer is the JavaFX UI. We also do not need lot of stuff from desktop like the normal chat rooms which contains much more messages as the offerbook.
I think you mean with "light node" that full mode with reduced options, not the "Light node model" I described in the model overview ("In that model we would delegate the networking part to a relay node and use a REST API between the mobile client and the relay node."). I refer to the downgraded full model as full model as it still follows the same p2p architecture and the user can scale up as he wish. The clearnet option adds a bit for differences as described in the model overview. But I still consider that a full P2P model and multi-network support (clearnet+tor) is a core-feature in Bisq2 and was mainly intended for seed nodes to syn among them via clearnet. For normal users tor+i2p will be the default once we have i2p running. For mobile clearnet only can work as well in the constraints described in the overview.
If you refer to me by that, I don't mean that we should work only on one model. To work in parallel on the API+thin client model and on the Android only full model is what I have in mind. Priorities can be set by devs and if some devs to prefer to work only on one model, that's ok. The only think I am strictly opposed to is to drop the full model without having found evidence that it cannot work. |
Beta Was this translation helpful? Give feedback.
-
|
Actually to avoid the confusion with Full-node model, clearnet-based full node and light node, maybe we should rename the earlier light node model to something like Delegated node model (p2p got delegated to a node and accessed via rest api). |
Beta Was this translation helpful? Give feedback.
-
|
Just posting here what we just chatted on matrix that clarifies the above. I found that we could have one codebase to rule them all, in KMP. The structure would look something like this: ** please note that the last 3 folders correspond one to each of the apps this project can generate. One codebase, 3 apps.** re the |
Beta Was this translation helpful? Give feedback.
-
|
I just tried out to get Bisq 2 common code base (copy/paste src code, not as jars yet) complied in Android Studio. Was not hard. There have been few classes which use not supported APIs and 2 where we used features not supported in Java 17. I also got all gradle dependencies and protobuf compilation running. Of course nothing tested for functionality but just wanted to see how difficult it is to get stuff compiled. Sure lot more stuff to do (e.g. proto lite,...), but I am confident I can get up to the network module in the next days. For the not supported classes we can move those to a new module in Bisq 2 which will not be used. |
Beta Was this translation helpful? Give feedback.
-
|
That's great @HenrikJannsen , would you like to upload it here , maybe in a |
Beta Was this translation helpful? Give feedback.
-
|
Once I have something reaonsable I will share... |
Beta Was this translation helpful? Give feedback.
-
|
Here my WIP POC... https://github.com/HenrikJannsen/bisq2/tree/adjustments-for-andorid-support Current state:
TODO on Java side:
TODO on Android side:
|
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone, new here!! Well I read some bits of the convo above, and I could agree on using KMP either with composeUI or combine swiftUI + ComposeUI accordingly. I don't have much clue on running full node so wouldn't know about it. If everything has been decided, could we make issues? |
Beta Was this translation helpful? Give feedback.
-
|
hey @nis-ship-it thanks for joining the conversation! That's great to hear, we can't wait to start full-on dev on this. Issues will start to be created at some point this week along with completing a bit more on the README docs aiming to help people joining the project as much as possible to contribute valuable work, so stay tuned! The Issue creation (or Work Breakdown) will be useful to have a rough estimation of how much time is needed to get to a beta stage for the 3 apps, we want to make sure to run this through the DAO voting so that the most staked in people in Bisq validate the general idea. What can you do at this stage? Please check the project README, download the bisqapps KMP code and follow the get started guide and let us know of any issues that you 'll find (along with the details of the hardware you are using). Stay tuned! 💪 |
Beta Was this translation helpful? Give feedback.
-
|
@nis-ship-it as you probably seen, we ended up scheming a rough WBS on the MVP proposal and creating the bare minimum tasks we need for now. Just reaching out to you since you've shown interest, would you be up for taking some work? maybe starting up with something small like adding Koin for DI to the project? or please just reply to this comment with your views on how you see yourself participating, or reach out to me directly on matrix. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
@rodvar thanks for reaching out, don't mind taking tasks |
Beta Was this translation helpful? Give feedback.
-
|
Update for the work on the full node model: Completed:
Next steps:
Open discussion:
|
Beta Was this translation helpful? Give feedback.
-
Potential future protocol supportThe scope for Bisq Mobile is currently limited to Bisq Easy. As we saw in recent discussions this was not obvious to others and the question about support for potential future trade protocols should be discussed here more in details. To make clear why Bisq Easy is "easy" to support on mobile there are the 2 main factors:
Those factors are not present with other protocols. As details about other protocols beside MuSig are less clear at that stage, lets focus on MuSig only. Though it can be expected that other protocols like Bisq Lightning come with even more challenging requirements. MuSig (conceptually similar to Bisq 1 multiSig)The trade protocol requires integration of a wallet, and due requirements for MuSig a custom wallet implementation which will likely be done in Rust. For the blockchain date retrieval it can be that we use a Java based implementation and it might even utilize our P2P network. Full node mode on AndroidFor a standalone mobile app those requirements come with severe challenges.
From my POV the cost/benefit ratio is not justified to implement that. Thin client modeHere we have to separate between the self-hosted model and the "Uncle Jim" model. Thin client mode connected to self-hosted full nodeIn that model the mobile app is a pure remote control to the full node. Thus the Bitcoin wallet is part of the full node and the requirements for the mobile app are just UI and API calls, thus not representing any technical or conceptual challenge. The only challenge is on the UX side, as the MuSig protocol is much more complex and comes with extra required features like arbitration and payment account management. But I consider those as solvable challenges. Thus I consider for that model it would be feasible to support other future protocols. Thin client mode connected to full node hosted by a trusted party ("Uncle Jim")In that model it is assumed that the wallet is on the mobile app side for limiting security risks and liability to the full node provider. As the thin client model is intended for both Android and iOS the integration effort for the wallet would be required for both the Android and iOS environment, which pose a significant effort and challenge. From my POV bases on assumptions for the wallet tech stack I consider that a prohibitive cost for the gained results. Reconsider the mobile deployment optionsSo far we had in mind that one mobile app will come on Android with the option to run as full node or as thin client. For iOS only as thin client. The thin client mode connected to full node hosted by a trusted party ("Uncle Jim") requires 2 extra features:
The thin client mode connected to self-hosted full node does not need those features. Considering the different scopes we could see the mobile apps as 3 different apps in fact:
This does not mean that we should deploy 3 apps, but to be aware that those are kind of 3 different apps and we might model it in the app, so the user can switch between those 3 flavors. |
Beta Was this translation helpful? Give feedback.
-
|
Appreciate this thinking and believe it's headed in the right direction. I think the key here is how we are framing Bisq Mobile, even if only in our own minds for right now. There's a world of difference between flatly saying "Bisq Mobile is only about Bisq Easy" and saying that "while Bisq Mobile's initial release / MVP is scoped only to Bisq Easy for the good reasons detailed above, that we see it as the vehicle through which we can bring most or all Bisq trading protocols to mobile in the future, along with the several node access models discussed (local, remote, uncle jim / friends & family), and that we're going to do it step by well-scoped step". The former framing is imo a downer; the latter ambitious and exciting. I think it's important we keep the latter's "bigger future" in mind, even as we intentionally build out something more modest in the near term. First, because it is imo just way more motivating; second because it actually makes us think differently and make better decisions now that can facilitate that bigger future actually getting realized. |
Beta Was this translation helpful? Give feedback.
-
Ideas about options for a Bisq 2 mobile app has been discussed in #298 while Bisq 2 was still in development.
This new discussion should focus now on the concrete and more limited scope of providing a minimal version of Bisq Easy as mobile application for both Android and iOS and discuss it more in details.
Feature scope for phase 1
Feature scope for phase 2
Relay node
Network interface
Public data
BisqEasyOfferbookMessage)UserProfile)AuthorizedMarketPriceData): Alternatively we could ping the price nodes, but it would open an additional privacy leak if clearnet is used, thus delegating it to the relay node seems the better approach.AuthorizedProofOfBurnData,AuthorizedBondedReputationData,AuthorizedAccountAgeData,AuthorizedSignedWitnessData): As this data has comes with some complexity how the resulting reputation score is calculated we delegate that probably to the relay which provides aggregated reputation score data.Private data
If the mobile user use clearnet, private messages are delivered as follows:
A private message sent from the mobile client to a desktop user is sent as
ConfidentialMessageto the relay. ThereceiverKeyIdis the relevant pointer to the receiver. This is an ID only known to the receiver. The relay sends it to the gossip network as mailbox message not as direct message to the receiver. The relay acts as publisher of that data. The receiver will get the mailbox message if they are online from the gossip network, decrypts and processes it.A private message sent from a desktop user to the mobile client is sent to the mobile users onion address (even if the mobile user use clearnet). As the mobile user is not using Tor it fails (fast) and the message gets send as mailbox message via the gossip network. The relay node receives that and forwards it to all their mobile clients. The mobile client checks if the mailbox messages has their key ID and if so decrypt and process the message. At some point the mobile client sends the remove message to the relay so that the mailbox message gets removed. We need to add some random delay here to avoid privacy issues.
Privacy implications
If the Tor mode is used, I think the privacy implications for the mobile user are very limited. For http requests to the relay the relay node does not learn about the mobile users onion address. The hidden service connection can be used only for data sent from the relay to the mobile client.
If clearnet is used and the mobile user is not using their own releay node, the relay node learns about the IP address of the user.
Pubic data are sent to all users the same way, thus there is nothing extra the user reveals. For received private messages it is the same ,as mailbox messages are just public data everyone gets delivered.
Only when sending a private message, the relay learns about the communication between the mobile user and some unknown Bisq Easy user with a certain
receiverKeyId. ThereceiverKeyIdis not publicly know and associated to any onion address or user profile. But from repeated messages the replay can learn that a trade happens (obvious anyway as that is the use case). With observing differentreceiverKeyIdsthe number of trades can be derived. The mobile user could distort that by publishing fake messages with non existing ids, but that would harm the network as mailbox messages without real receiver would stay until the TTL is triggered in the network and need to be loaded by any node.We could though add a new model to create new IDs after each message (or a pool when communication starts), thus each message will have a new ID and only the 2 parties know how about it. We have to be careful though that a missing message would not fatally interrupt the chain and making further communication impossible. But I guess there are ways how to achieve that with sufficient resilience. With such a solution the issue that the relay can learn about the number of trade is mitigated.
Another issue is the removal of a received mailbox message of the mobile user. The relay node would learn that a certain mailbox message (which contains the
receiverKeyIdwas successfully decrypted by the mobile user and therefor knows theirreceiverKeyId. To avoid that the mobile user can randomly delay the remove message so that this correlation is broken.Those mitigations will not provide the same privacy protection as the Tor mode, but beside that the relay learns about the IP address the privacy implications are rather small.
Security
The mobile user need to trust to some extent the relay node.
A malicious relay node could:
Conclusion
I think Bisq Easy can be implemented as a mobile version even with the clearnet option with a privacy/security to convenience trade-off acceptable for many users. For the more privacy focused users there is the option to run their own relay node (less convenient) or if they are Android users to use the Tor mode. If that is not enough or possible its best to stick with the desktop version.
Beta Was this translation helpful? Give feedback.
All reactions