Should the UI be an Electron app?

[stubbrn]

I'm not sure if the UI should be an Electron app, or a "browser UI" (opening http://localhost:PORT in a browser). Thinking about how to make the most user-friendly interface and setup:

• The most frictionless way for a new user to start using the protocol would be to open a hosted (remote) web UI in the browser and start to swap without any install/setup. It's probably not possible right now because it's not safe for multiple users to share the same node as it knows your private keys (maybe we could serve a WASM version of the node along with the UI, and use a remote monero node for a no-install setup, but it's not ideal and the added complexity may not be worth it).

• The next best thing would be for a new user to download/install the node and UI bundled in a single executable, similar to how the official monero wallet GUI can run a monero node. In this case, a desktop application (Electron app in our case) is much more standard than a browser UI, it would be much like bisq. However, an Electron app means that you can't integrate with a Metamask wallet, you either need to import your wallet via seed/private key or you need to fund a new wallet (I don't think it's a deal-breaker, but needs to be taken into account). It could also be a bundle while staying as a browser UI, the main con is that it's fairly unusual especially for less technical users.

Any thoughts or ideas?

[dimalinux]

Electron might be the best way to go. I think any integration, like metamask, that requires a user to do approvals for each transaction is a bad UI that will make swaps fail. We need the "set ready" transaction to be fully automatic, as the end-user can not be expected to sit and watch the swap for the 10 confirmations (~ 20 minutes) required before the Monero in the temporary swap wallet is fully unlocked.

Bisq is a java application. I'm guessing it is using JavaFX?

There is a Go framework named Fyne that may or may not be good solution. I wanted to play around with it, as it would be a way to keep the majority of the codebase in one language.

[stubbrn]

We need the "set ready" transaction to be fully automatic, as the end-user can not be expected to sit and watch the swap for the 10 confirmations (~ 20 minutes) required before the Monero in the temporary swap wallet is fully unlocked.

Indeed, that makes the decision much easier :)

There is a Go framework named Fyne that may or may not be good solution. I wanted to play around with it, as it would be a way to keep the majority of the codebase in one language.

Interesting, I didn't know about Fyne; I have nothing against it, but considering that there's already some work being done in Typescript and that I'm experienced with Electron, it might makes more sense to continue with what we got.

[stubbrn]

@dimalinux
I've made a first prototype version with wails.
I'll create a PR when the current ones are merged.

[shermand100]

Hi @stubbrn
A bit of copy/paste to start with for context as I don't see you in the Matrix room...

I run the PiNode-XMR project, which for people unfamiliar is a beginner friendly way to run a full Monero node on low power devices - such as Arm SBCs or old laptops - and it also comes with a suite of tools along-side it to pair with Monero, P2Pool, Blockexplorer, Dynamic DNS, OpenVPN, tor, I2P. All completely FOSS, all from their original GitHub repos. We're kind of like a Monero node compendium where everything auto installs via bash scripts, making it easier for the less tech savvy. ( https://github.com/monero-ecosystem/PiNode-XMR | https://pinode.co.uk/ ) I've had a bit of a play over the past week or so and this Swap tool builds fine on ARM and I can automate the install with a script for my project, it looks really promising and through PiNodeXMR I think it could bring quite a few more users to your platform that otherwise may not be able to operate via the CLI. I love that you have a browser based UI as that's how most common features are accessed for PiNodeXMR. (I don't track how many users I have but somewhere ~200 would be my estimate based on telegram, reddit and web traffic around the project).

The PiNodeXMR project runs entirely headless with interaction all through a Web UI, as does the Blockexplorer we host and a web terminal for ssh console menus. Based on this if we were to add these Atomic Swaps as a feature we could really do with a Web UI for this swap tool, if only for the offer searches and taking offers initially, (other aspects - display balance/QR etc- can be done from a CLI menu as we use that for other system management).

With what I've done this week building swapd and cli on PiNodeXMR, carrying out swaps and preparing install menus the only element I havn't yet got working is the Web UI, it doesn't seem to connect to swapd. Is it easily fixed?
I see you're working on the Wails based desktop app but is it possible to maintain the Web Ui too (to a basic level) to onboard users from PiNodeXMR?

I'm happy to help where I can.
Dan

[stubbrn]

Hi @shermand100
I'd recommend sticking with the CLI for now, the web UI is in very early stages and may contain bugs and missing features, it's not production-ready yet.

Yes it'd be possible (and desirable) to maintain a browser version along with a desktop version.

For the connection issue, it might be because the web UI connects to http://127.0.0.1:PORT where PORT is 5000 by default. This means that if the web UI is running on your low power device running PiNode-XMR and you are accessing it from your computer, it will try to connect to a swapd instance on http://127.0.0.1:PORT which is your computer, not the low power device running swapd. You'd need to use the raspberry pi's IP address or javascript's window.location.hostname (alternatively you can access the web UI directly on the low power device), for now there's no config or environment variable to do that, you'd need to change this line:

atomic-swap/ui/src/utils/rpcApi.ts

Line 17 in 13b7653

baseURL: `http://127.0.0.1:${getPort()}`,

[shermand100]

Started a new issue to keep my Web UI chat away from this Electrum conversation
#505