Bisq remote about proposals HOT 13 CLOSED

Here is an update of the development of the notification app

• iOS app is in the finishing state. Unfortunately iphone 6 or below does not support well notifications.
• Android app is in development
• Relay server is done (https://github.com/ManfredKarrer/bisq-relay)
• Desktop UI is done in most parts (https://github.com/ManfredKarrer/bisq-desktop/tree/notifications and other projects):
  • Trades, open offer taken, dispute messages
  • Price alerts
  • Market alerts domain (not UI)

Here are some screenshots:

from proposals.

Thanks @joachimneumann for the proposal!

I think the notification server should be a Bisq node with both the P2P network layer as a normal Bisq node and a HTTP server interface as the price node.
The bi-directional communication between the Bisq node and the notification node would be pure Tor hidden service traffic.
The communication to the Apple server would be HTTP.
The communication from the mobile app back to the notification node would be HTTP as well (encrypted payload).
With that model the Bisq user do not need any setup for port forwarding or the like as his Bisq node is accessible via Tor. The notification node would run anyway as server and is operated by Bisq contributors so the user don't need to care about that.
The model would work the same if a user wants to runs his Bisq app on a cloud service (though there are other security constraints - e.g. wallet should be always encrypted).

I am working atm on integration for the APIs and we planned to support a HTTP API and a gRPC API. I think it would make sense to add another API layer which is Tor hidden service based only for supporting the communication between the notification node and the Bisq App.

from proposals.

I would propose that I start out with a very lean Bisq notification node.

Later, we can decide between

• Option 1: The user keeps Bisq running on his computer, in which case a Bisq notification node could route bidirectional encrypted message between the phone and Bisq on the computer.
• Option 2: The user can opt for a cloud-based Bisq node and does not need to keep Bisq running on his computer. He might even not need to run Bisq on his computer at all - a the cloud node and a Bisq App on his phone could suffice.

I think that Option 1 makes more sense, because

1. The use cases for the mobile app can be limited to the functionalities that are most useful while being on the move. This makes the App clean and easy to use.
2. A cloud-based Bisq node would require the mobile apps to support the complete set of functionalities - including all settings and the wallet. This is a lot of work to implement and would be beyond what I plan to contribute.
3. Option 2 would add additional burden for new Bisq features, because each new feature would need to be supported on the desktop and in the all mobile apps. Otherwise, the mobile Apps would render the cloud-based Bisq node incomplete. I am not sure that the mobile development resources would be available for each new Bisq feature.
4. In Option 2 complications might arise for users that have a Bisq node on their computer and a could-based Bisq node

from proposals.

For bidirectional mobile app - Bisq Desktop the server model used in the price node is not sufficient as the server cannot contact the Bisq Desktop. For that a P2P node would be required. It would combine a Bisq node like the Seed node or monitor node with the HTTP server functionality of the price node.

from proposals.

@ManfredKarrer You are right, we need a P2P Bisq notification node not a Bisq notification Server. I will update the spec accordingly. I also update my previous comment in which I argue for lean mobile remote functionality.

from proposals.

Just an update from our last discussion:
For the notification only version we can use a simple relay node which has the same structure like the price node. A Http server over Tor to the Bisq nodes and it is calling the Apple notification server.
The Apple ID of the mobile should be exchanged via QR code with the Bisq app directly. That require that the computer where Bisq is running has a camera. If not the user need to send the data via email to his computer and copy / paste it or type in manually the (long) Apple ID.
The Bisq app sends then the encrypted message and the Apple ID over Tor to the Proxy node with a http request. The proxy node relays that message to the Apple notification server. That way the proxy does not learn about a mapping of the Bisq node (as it receives the messages over Tor) to the mobile ID and there is no need to register anything at the proxy node.

In the version 2 with bidirectional messaging between Bisq and mobile we should try first to get Tor hidden services support for mobile. On Android it should be not a big issue (Bernhard did that 2-3 years ago). For iOS we need to check out if there is a native Tor app (there is no official Tor browser). It seems that on iOS you cannot create a sub process which makes the model we use in Bisq impossible (start native Tor and communicate over TCP). So it might be that the challenge to get Tor working on iOS will be too hard. Then we have to decide if we support Android only, or if we use the above discussed solution to communicate over a proxy node which has a Tor API between Bisq and the node and a http API to the mobile.

from proposals.

It's the unavailability of a Tor implementation on iOS that makes me wonder why not start with Android here? Would be a shame to have to switch platforms just when things are getting going. And a working Android app would set a clear mark for what needs to be possible on iOS, making it all the easier for someone to step up and fill exactly that gap.

from proposals.

Exciting stuff, @joachimneumann. I've read through the proposal and all comments and have reacted 👍.

In my experience, it's a good idea to start thinking and talking about compensation and inclusion in the @bisq-network GitHub organization fairly early in the process. I'll put a few "menu items" on the table you can choose from:

1. Such a project could be developed and managed completely by you with as much or as little engagement with existing Bisq contributors as you like; you can ship it, you can charge money for it, you can do essentially whatever you like (though we should discuss appropriate use of the Bisq brand), and you can do it all permissionlessly.

2. You can develop the project in an "incubating mode" like several other projects are right now. You can do work in your own GitHub repository, use our Slack workspace, add documentation for your app to https://docs.bisq.network site, and otherwise make full use of our collaboration infrastructure. You could decide to make the app free, and to earn only BSQ for your efforts through compensation requests. And when you've got an initial release out, some users and some feedback, you can submit your first compensation request and get the repository transferred into the @bisq-network GH org, and become a first-class member of the set of Bisq components.

3. You could also fund the work via BSQ compensation requests and never decide to bring the app into the @bisq-network organization.

We don't have strong best practices yet as to how to manage this kind of process. Maybe you see other options than the three listed above, feel free to share ideas. What we do know so far is that when somebody is building a brand-new component for Bisq, we want the burden and risk to be on them to propose the project well (as you have done here, thanks), and then to execute the project in a way that makes it obvious to everyone that valuable work has been produced. I recommend reading through this recent proposal in which we agreed that contributors will request compensation only for delivered work.

No need to make hard decisions on any of this just now, but I do recommend thinking on it and updating your proposal to indicate which approach you plan to take (even if you change it later), and to lay out some specific criteria for what a "delivered" Bisq Remote app will look like.

from proposals.

Chris and Manfred, you are both technically right of course. However, I happen mainly to be an iOS developer and therefore feel more comfortable to iterate on the design of the mobile app and the architecture (without tor) in iOS.

I also think that the iOS app would still be useful for less privacy-concerned users that want to get push notifications without making sure that the app always runs in background in their phone.

I fear that a Tor-based solution — both on Android and on iOS — would not be able to offer push notifications, which reduces the usability.

Ideally I would like offer the user a choice between good usability (push) and privacy (pull, tor), but I need to start somewhere and the Tor-based solution might later be nicely motivated by a working, but imperfect iOS app.

from proposals.

I would see for the version 1 (notification only) both platforms iOS and Android supported. Version 2 with more features and bidirectional communication could still have all version 1 features but adds the tor implementation. That depends then if it is feasible to implement on iOS if we can deliver if for both platforms, otherwise a Android only version 2 app might be a way to go. Alternatively we could try the approach with the proxy server which acts as gateway between the iOS app and the Bisq app.

from proposals.

I would like to just maker here a quick note what is needed beside the iOS app:

• Notification relay server: similar structure like Pricenodes
• Integration of setup code in Bisq app (from https://github.com/joachimneumann/bisqremote)
• UI for setting up which types of notification the user wants (e.g. offer taken, trade steps, price alert, remote wipe-out in case mobile gets stolen,...)

Beside that an Android app would be good to have as well.

If any dev has time and skills to work on that would be great! Experience with UI work in JavaFx is required for that task as most effort will be on the UI side.

from proposals.

Here are some screenshots of the current app:

from proposals.

Closing as approved. Development has been underway for a quite a while now, and Development updates like those above should probably happen somewhere other than than the proposal itself. I'll leave it to the developers (@joachimneumann, @ManfredKarrer) to share where they'd like people to follow updates from here out. Note that I created a #bisq-remote channel in Slack if folks would like to use it.

from proposals.