Bisq Easy Mobile #2665
Replies: 4 comments 4 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.
-
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.
-
Look no further, I am already 75% done creating a Bisq app. |
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.
-
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
ConfidentialMessage
to the relay. ThereceiverKeyId
is 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
. ThereceiverKeyId
is 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 differentreceiverKeyIds
the 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
receiverKeyId
was 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