Replies: 1 comment 1 reply
-
|
I am an iOS native developer and have always been interested in a mobile client for Bisq. Been discussing about the direction of mobile in regards to Bisq with various people on Matrix. What have been laid out in the OP makes sense. A few points I want to add.
I am happy to help if there is buy-in for a Semi-full, take-only version of the Bisq library written in Kotlin Multi-platform. Mostly in terms of project scoping and iOS UI development however. Would probably be more efficient if someone more familiar with Bisq P2P/relay, along with Kotlin, to drive the library portion of things. |
Beta Was this translation helpful? Give feedback.
-
|
Are you still interested in contributing for the mobile app? Bisq2 desktop is very close for release and I think we are better equipped now to fine-tune concepts for a mobile app if a developer with the right skill set is available for taking the lead for such a rather large project. |
Beta Was this translation helpful? Give feedback.
-
This is an overview about the rough ideas/plans for a Bisq 2 mobile application.
Platform targets
Android
Our primary target is Android as we can reuse the Java code base and as Tor and I2P are supported.
iOS
On iOS I2P cannot be used as I2P is written in Java and there is no stable non-Java I2P router available (as far I am aware). There is also no official Tor application for iOS available and the existing implementations are based on some hacks which can be eliminated by Apple at any new version. Also its not possible to start another process for Tor so it would require an integrated approach which would add more effort, risks and complexity. Beside all those technical issues the walled-garden policy of Apple has to be considered a major risk for the investment. Apple had kicked out Bitcoin apps in the past and there is no guarantee that this would not happen again.
For all those reasons we do not consider iOS as a primary target. For a limited light version it might be still an option later as that will not require a P2P network and the effort and with it the investment risk will be much lower.
Other
We do not plan to support other mobile platforms. Some Linux based platforms could be targeted though if not too much effort.
Versions
Full node version
This version implements all the features which are supported on the Desktop version as far it is technical possible.
The core infratructure like the P2P network using Tor and I2P are fully supported. Add-on functionality like protocol specific wallet or node integration will depend on the feasibility of the actual implementations.
One has to consider that the real user base for that full version might be rather limited as it likely will be very resource heavy running the P2P gossip protocol on a mobile device and battery drain might be a serious issue.
We should support it as long it does not cause too much effort on the technical side and keep in mind that the user base might not be worth larger investments.
Semi-full version
Here we delegate the P2P gossip network part to relay nodes. The mobile app operates only normal nodes which connect to a semi trusted relay node to get connected to the P2P network. As data is either public or signed/encrypted there is very limited risks. The main risk as far I can see is that the relay node hides data (e.g. holds back offers or mailbox messages).
The user can run their own relay node or use their desktop application as relay, thus eliminating those risks. If they do not want to run their own node Bisq contributors (bonded roles) can provide nodes similar as we do it with Bitcoin SPV nodes.
By avoiding the need to run the gossip protocol we limit the resource requirements and bandwidth requirements and it becomes much more feasible to run it on a constrained device.
The integration of wallets and other protocol specific infrastructure will depend on the feasibility to support that for mobile.
Remote-control version
A pure user interface based version where all the core features are on a user provided full node using a REST API for connecting to that node is also possible to get supported with iOS.
Obvious drawback is that the user need to run either a node on a server or use their desktop application with the API enabled.
Non-custodial version
Depending on the wallet integration there might be an option where the wallet keys are on the mobile application but all the rest is on a remote node which can be outsources to a service provider. It will come with privacy risks and likely also some security risks. It is a similar model used for many LN mobile apps where keys are controlled by the user but privacy is lost to the node provider. This likely adds also some risks regarding liability for the service provider. With all those drawbacks I do not consider that a taget to get implemented by Bisq.
The semi-full version is the primary goal as it provides the best cost/benefit ratio.
Scope
Due the limitations in display size and capabilities we should try to find the optimal scope for the mobile application.
With the current roadmap we plan to deploy the chat-based trade protocol (Satoshi Square) with the first release. This does not require a wallet integration and is basically a messaging/chat application.
This is a prime candidate for mobile and I do not see any technical hurdles so far. We can limit initially to Tor support as we know that this works, but we do not have yet experience with I2P on mobile.
When more trade protocols get added we need to evaluate the feasibility and options to add those to the mobile version as well.
It is possible that the mobile app stays at the scope level of the chat based version and users who want to use more sophisticated trade protocols are forwarded to the desktop application. As those protocols come with some integration requirements (e.g. run Elements wallet for Liquid swaps, run farcaster node and XMR+BTC full nodes for atomic cross chain swaps,...) the requirement for installing a desktop is the least of the hurdle, thus a major benefit of the mobile app to not need to install anything or not requiring a desktop computer is eliminated already. The remaining benefits to add more accessibility might not justify the effort... but has to be seen once we get there.
At the current state there is no work done on specifying any details or designs.
A new Bisq contributor signalled interest to work on that and they are very welcome to work on further specifications.
Non-goal
There is no intent to support Bisq 1 for that mobile application. It could be seen as a separate project but as Bisq 2 will replace Bisq 1 once its supporting the MultiSig protocol I do not think its worth the effort. A Bisq 1 mobile app would mostly make sense as a remote control version, thus requireing the user to run a Bisq full node.
Beta Was this translation helpful? Give feedback.
All reactions