joinmarket-webui / jam Goto Github PK

Follow-up to and extension of #12

See the Configuration page in the wiki.

Update from Figma, June 2022:

Make the JoinMarket Web UI available as an app in the Umbrel app store.

See Umbrel App Framework

Timeline

• Create Draft Pull Request in Umbrel Repo (getumbrel/umbrel#1216)
• JM server version v0.9.5 is released
• Web UI version v0.0.3 is released
• Release a standalone image of server v0.9.5 and client v0.0.3
• Remove Draft status of Pull Request in Umbrel Repo
• Pull Request is merged

Cover screen and onboarding flow to be shown upon first use.

See Figma for a rough sketch:

See the current design in Figma:

In short:

• Hide derivation paths and addresses from the user
• What is currently called "Account 0" is the lowest level, i.e. "one shield"

We can add the complexity that this will hide later on if we like, but the current view is all kinds of confusing, so this would be an improvement.

Note that this concept/design is by no means final, since we can't always map "privacy level" to "accounts" (mixdepths) in a truthful one-to-one manner. But again: it's a big improvement from the current UI and should be easier to understand than mixdepths.

See Figma. That'll make the screens blend in better with the rest of the fancy new UI.

This is also a good opportunity to think about wording on those screens. E.g. how should we deal with / call the concepts of "Accounts" on the send screen? See discussion here.

• Send. See #76.
• Receive See #85.
• Earn See #82.

As per discussion between @dennisreimann and @AdamISZ, an unlocked wallet should be locked again if the user closes the tab or the browser window.

We can use the /unlockAPI endpoint, see JoinMarket-Org/joinmarket-clientserver#1136

Related: JoinMarket-Org/joinmarket-clientserver#1121

I get the following error in the console when opening a wallet:

Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.
Wallet@http://localhost:3000/static/js/bundle.js:3859:7
Wallets@http://localhost:3000/static/js/bundle.js:4217:7

@secondl1ght reached out to the myNode team already, see mynodebtc/mynode#628

We currently have an "this is alpha software, be prepared to loose everything" disclaimer—but it's hidden somewhere in the onboarding reel so most users probably won't read it.

We should have a more dominant disclaimer that's visible in the app (at least on the send page but I would even show it on all pages). The disclaimer should make it clear that this is not "top-notch privacy for your bitcoin" (yet). We need to be careful not to make false promises in these early stages where we offer only limited features (e.g. no tumbler, only simple spend-joins) Especially, since we're targeting a less technical audience we need to be careful not to make them believe that a simple spend with 2 collaborators makes their coins perfectly private for example. See also the recent discussions in our group chat.

Adding this to the 0.0.3 release I think it's important to discuss before we release the first (alpha/beta) version.

A small list of things that stood out during testing and trial.

Please expand it according to your own assessment and let's talk about which are important before the first beta version is released.
Feel free to give an estimated priority as well.

• Inform user about coinjoin state immediately after coinjoin is initiated. Preferably via Websocket Fetch /session immediately after starting taker (otherwise user might wait up to 10 seconds to know what is going on) - #46
• #83
• #87
• From @AdamISZ : When the maker is started without coins it says "maker cannot start, no coins", but it's important that it should say "no confirmed coins". See #34 (comment) - PR opened JoinMarket-Org/joinmarket-clientserver#1190
• #157
• Improve wording of error message when trying to send to an "invalid" address: "Invalid request format." is not meaningful. (400 InvalidRequestFormat on all assertion errors.. see wallep_rpc.py#L548)
• Prevent user from starting taker with insufficient funds (?): #155
  • Might be that a taker operation is started and then aborted - either unconfirmed or too little funds available (takes 60s to be resolved)
• Balance shown on Send page might not be spendable (e.g. utxo is frozen) #78

(This list should not contain missing features (e.g. "display spendable funds" or "ability to sweep"), but rather just document odd behaviour or possible improvements for existing ones.)

After opening and closing the wallet a few times the service stops responding and no further interaction is possible (api stops responding).
This happens rather quickly and can be reproduced on my side after locking/unlocking the wallet four to five times.

In this state, when reloading the page, the app stops rendering completely.

Server logs do not give a strong hint about what might be wrong.

> root@edd0ae308a67:~/.joinmarket/logs# tail -f jmwalletd_stdout.log -n 200

<Request at 0x7f7e2d385b80 method=POST uri=/api/v1/wallet/t.jmdat/unlock clientproto=HTTP/1.1> [...]
2022-02-01 10:49:37,349 [DEBUG]  rpc: listaddressgroupings []
2022-02-01 10:49:37,353 [INFO]  Detected new wallet, performing initial import
2022-02-01 10:49:37,353 [DEBUG]  requesting detailed wallet history
2022-02-01 10:49:38,254 [DEBUG]  rpc: listlabels []
2022-02-01 10:49:38,255 [DEBUG]  rpc: getaddressesbylabel ['joinmarket-wallet-d4ef50']
2022-02-01 10:49:38,273 [DEBUG]  got used indices: {0: [0, 0, 0, 0], 1: [0, 0, 0, 0], 2: [0, 0, 0, 0], 3: [0, 0, 0, 0], 4: [0, 0, 0, 0]}
2022-02-01 10:49:38,352 [DEBUG]  rpc: listlabels []
2022-02-01 10:49:38,354 [DEBUG]  rpc: getaddressesbylabel ['joinmarket-wallet-d4ef50']
2022-02-01 10:49:38,362 [DEBUG]  Wallet successfully synced
2022-02-01 10:49:38,363 [DEBUG]  rpc: listunspent []
2022-02-01 10:49:38,371 [DEBUG]  bitcoind sync_unspent took 0.008394718170166016sec
2022-02-01 10:49:38,382 [INFO]  Starting transaction monitor in walletservice
<Request at 0x7f7e2d3f6c40 method=GET uri=/api/v1/wallet/t.jmdat/display clientproto=HTTP/1.1> [...]
<Request at 0x7f7e2d3f6df0 method=GET uri=/api/v1/wallet/t.jmdat/lock clientproto=HTTP/1.1> [...]
<Request at 0x7f7e2d396a00 method=POST uri=/api/v1/wallet/t.jmdat/unlock clientproto=HTTP/1.1> [...]
2022-02-01 10:49:44,289 [DEBUG]  rpc: listaddressgroupings []
2022-02-01 10:49:44,292 [INFO]  Detected new wallet, performing initial import
2022-02-01 10:49:44,292 [DEBUG]  requesting detailed wallet history
2022-02-01 10:49:45,208 [DEBUG]  rpc: listlabels []
2022-02-01 10:49:45,219 [DEBUG]  rpc: getaddressesbylabel ['joinmarket-wallet-d4ef50']
2022-02-01 10:49:45,239 [DEBUG]  got used indices: {0: [0, 0, 0, 0], 1: [0, 0, 0, 0], 2: [0, 0, 0, 0], 3: [0, 0, 0, 0], 4: [0, 0, 0, 0]}
2022-02-01 10:49:45,309 [DEBUG]  rpc: listlabels []
2022-02-01 10:49:45,311 [DEBUG]  rpc: getaddressesbylabel ['joinmarket-wallet-d4ef50']
2022-02-01 10:49:45,318 [DEBUG]  Wallet successfully synced
2022-02-01 10:49:45,319 [DEBUG]  rpc: listunspent []
2022-02-01 10:49:45,326 [DEBUG]  bitcoind sync_unspent took 0.00782322883605957sec
2022-02-01 10:49:45,342 [INFO]  Starting transaction monitor in walletservice

Maybe Starting transaction monitor in walletservice causes problems on the server, but this is just unfounded speculation.
Seems like there cannot be much done on the client side, except for better handling of the unresponsiveness of the server maybe.

See the Main V2 page in Figma:

Rough component outline:

• Header component (added in #29)
• Wallet name & balance (added in #29)
• Send / Receive / Earn (added in #29)
• Settings (gear icon) (added in #26)

See #51 (comment).

We could show loading placeholders like these (obviously adapted to fit the layout of our UI) while content is fetched to make loading seem faster and more smooth.

Currently we repeat the same layout container (<rb.Col md={10} lg={8} xl={6}>) in almost all pages. We should move this container to a higher level and then render pages as children inside this container. That way we don't have to repeat it on every page. See Layout Routes in React Router.

The full joinmarket.cfg config file contains many settings and multiple sections (daemon, blockchain, messaging, logging, timeout, policy, payjoin, yield generator), not all of which are immediately relevant to most users.

We should understand and document all settings, and break them down into two or three different sections, e.g. basic / advanced / expert.

Rough tasks list:

• Research joinmarket.cfg
• Rank-order by importance and/or use-case
• Write copy, find proper names and descriptions for settings (in cooperation with @GBKS)
• Update the JM docs upstream

All of the above should serve as a base for implementing #12

Multiple ways to do this, an easy one would be to show an additional screen, pick 3 words at random, force the user to enter these 3 words.

We could also do it a later point, as suggested in the bitcoin.design guide:

We recommend that the optimal phase to hint the user to perform the backup should be after the wallet has received funds for the first time. This way, we avoid overwhelming the user with an unnecessary task, as it makes more sense to backup a wallet with funds on it.

Source: https://bitcoin.design/guide/onboarding/backing-up-a-wallet/

Dark Mode support is basically required nowadays, otherwise the dark mode maximalists will rip us apart. A day/night toggle should be good for starters. We can also do day/night/dusk as seen in the Thunderhub UI:

No designs or mockups of this screen yet, but it could contain something like:

• Web UI settings (denomination, theme, sat symbol)
• JoinMarket settings (txFee, cjFee, cjSize, etc.)

We could think about breaking down the 2nd point—the JoinMarket settings—into three different views, e.g. basic / advanced / expert.

The full joinmarket.cfg config file contains many settings and multiple sections (daemon, blockchain, messaging, logging, timeout, policy, payjoin, yield generator), not all of which are immediately relevant to most users.

Clicking the gear icon in the top right will open up this screen.

Since we want to put this thing in all the nodes, and "JoinMarket Web UI" feels a bit clunky, we might want to use these early days to come up with a fancy name that is short and sweet and cool and all the rest of it.

The name should be:

• Easy to pronounce
• Unambiguous, both in writing and when you hear it spoken (not "muun with two u's")
• Short enough
• Distinct
• Related to JoinMarket or the concepts that we implement

Examples that I like from the Bitcoin and Lightning world:

• ThunderHub
• SatSale
• Nodl
• Zeus
• Voltage

Yesterday night "Jam" popped into my head, since I've been writing "JM" a lot, and it also works because it's kind of a liquid (which is a good metaphor for what is happening on a technical level, as in "Whirlpool"). You can also think of it as "jamming" the signal that chain analysis tries to decipher.

We could also lean into the "Raspi" theme or the "orange" theme.

I also like the "Fusion" concept that came up in call 4. But we might as well make jam 😜

If you have suggestions, drop them!

We talked about in the call today adding the shields to wherever the Accounts are referenced to create a visual link between the accounts and the privacy levels. I just wanted to check that this is what was decided before implementing anything.

Instead of writing "sat" use the sat symbol. There is also "the sat" in case we want to provide the user with more options.

Since JoinMarket-Org/joinmarket-clientserver#1122 has been merged (JoinMarket-Org/joinmarket-clientserver#1148), it is possible to show the yield generator activity to the user.

A simple view would already enhance the user experience by a lot.

See Figma.

The current screen is fine and works well. The UI in Figma does look a bit better though.

English only is probably fine for a long while, but at some point having the UI available in multiple languages would be good.

• Apply for Transifex open-source license (Done. Project created: joinmarket/jam)
• Integrate i18next (Done. See #153)
• Replace hard-coded language with translation strings (Done. See #174)

Just noticed a small issue: if an address contains an "x" between two numbers it will be rendered as a mathematical symbol:

An easy fix would be to render every address inside a <code> tag or something, like this: bcrt1q6wyvqnm2daajashl0jdl8l84ghwadsg4g37x30

We have a connection indicator already, but it only shows up if the UI can't connect to the API. It currently looks like this:

Once a connection is established, it will look like this:

I'd propose a connection indicator either in the header or the footer, something like a simple green/red dot and some text that says "Connected" or "Disconnected".

See Figma.

The "flow" is already there but we could improve the UI a bit. (I really like the Figma version.)

Currently, each API request is assembled and sent by every component itself. As a developer, it would be nice if this could happen clearly from a single service. This makes it easier to understand when, where and why requests are made.

See the Open API spec for jmwalletd.

I already tried to generate a client from the specification with openapi-generator. Namely used generator javascript,
javascript-flowtyped, typescript, typescript-axios, typescript-fetch. But these look very verbose and bloated, the easiest way is probably just to move all API accesses in one file for now.

What do you think? Any benefits of generating the client at this stage of development? Or is a simple, single file better for now?

When initiating a collaborative transaction the number of collaborators can be provided.
It seems, based on these comments, this value must not be less than what is specified in config variable minimum_makers. Default is 4.

A viable solution is to GET the value of this variable and use it as min value for the form on the Send page.

As a user with a balance of zero, when I start the Maker service it shows the error Maker could not start, no coins. (request results in 409 Conflict).
However, the service starts anyway. When subsequently clicking "stop", it will display a success message The service is stopping. (request is even resulting in 202 Accepted).
Nevertheless, the service is not stopped and will stay this way indefinitely.

I do not know if we can do anything on the client, as this seems to be a server issue.
Just want to keep it here as reference - I will investigate the server code and open an issue in their repo if needed.

thank you all for spending time and effort to build this. the webUI looks great and I'm excited to test!

I followed the installation instructions and webUI loads locally, however it cannot connect to backend.

No connection to backend: Gateway Timeout.

SSL certificate is created and API service is running
2022-02-12 22:19:48,932 [INFO] Starting jmwalletd on port: 28183
2022-02-12 22:19:48,946 [INFO] Joinmarket daemon listening on port 27183

Joinmarket version: v.0.9.4.-85-gfd5871b

In local terminal, two errors show up after
npm start

the second error is recurring

[HPM] Error occurred while proxying request localhost:3000/api/v1/wallet/all to https://localhost:28183/ [ECONNREFUSED] (https://nodejs.org/api/errors.html#errors_common_system_errors)

[HPM] Error occurred while proxying request localhost:3000/api/v1/session to https://localhost:28183/ [ECONNREFUSED] (https://nodejs.org/api/errors.html#errors_common_system_errors)

The error comes up no matter if API Service is running or not, and error occurs when requesting to to https://localhost:28183/ - however shouldn't the request be to raspiblitz 192.168.0.103:28183 ?

Make JoinMarket Web UI available as an app for Citadel.

Probably related to #17, as the underlying architecture should be the same.

I'd love to somehow document how we want to handle releases (mostly so that we can automate the process as much as possible).

Basically what we'll need to do for a release is:

1. Bump the version (npm version)
2. Update the changelog (see #103; we can automatically run this as a "post script" for npm version)
3. Since master is protected we'll need to pull-request the version bump and changelog to master.
4. Tag the release and create a GitHub release
5. Docker files will automatically update once we tag a release in the web-ui repo.

If that is correct, my question would be: Where should we add the tag? We can either:

1. Tag the "bump and changelog branch"
2. Tag master after the "bump and changelog" branch was pull-requested and merged (we could even do that automated via GitHub actions, i.e. "everytome a pull request with the release label gets merged, create a tag and a release").

I think I'd prefer option 2. since having tags on master feels clean to me and a pull-request before a release is probably not the worst thing to do.

Any thoughts? Did I forget anything important?

User opening the app for the first time will have no default config stored in local storage leading to display issues (e.g. when showing balances).

Reproduce: Delete local storage data and reload.
Fix: Always take default values into account when initializing the settings for the first time.

This is a small suggestion that I have, I think the icons on the right of the navbar (settings, wallets) should be reordered so that settings is on the right and wallets on the left. I think users will want to access the wallets page more often than the settings so it should be the first one.

One other observation is that the current wallets icon doesn't really let the user know that it links to the wallets page very well. I think it would be better to update this icon to be consistent with other references to the wallets by using the same wallet icon.

Let me know what you guys think about these ideas! Thanks

See discussion in #76 (comment).

The balance that's shown when selecting which account to send from, is currently hard coded to whatever is returned from the server. That means it is always shown in BTC and can't be changed to sats.

That's because the <option> element only allows text children so we can't use the <Balance> component.

Maybe there's a way to fix this though? 🤷‍♂️

Improve error message when server returns 500 Internal Server Error as text/html (e.g. when trying to send with too little funds ) - we display "JSON.parse: unexpected character at line 1 column 1 of the JSON data" as we try to parse json.

As discussed in Call 2, it would be interesting to do some automatic parsing of the orderbook to let the user choose sane defaults instead of fiddling with various fee settings.

Not sure if it's feasible or easily possible, so consider this an idea more than a feature that has to be implemented.

Listen to the call recording and have a look at the JM orderbook docs and an online orderbook to get an idea of what data is in the orderbook and what settings could be automatically set or hidden from the user.

• Improve mobile layout: #29 (comment) fixed in: #44
• Change mobile menu to offcanvas drawer: #29 (comment) fixed in: #44
• Show wallet name vertically centered when balance is not shown and animate the transition when the balance is eventually shown: #29 (comment)

When the wallet is locked, all paths except / will render an empty page.

This is true for paths that usually lead to something, such as /wallet, /send, /earn, /receive, /settings, but also for non-existent paths such as /this-is-a-path-that-leads-nowhere.

We should either:

• Show a 404 page, or
• Redirect the user to the wallets page, i.e. /

Screenshot:

I don't have much experience with testing react apps but I think we could at least do some basic UI tests now that we have a working regtest environment.

Not super urgent right now but once the UI is somewhat settled in this is something we could add.

Adding this to the last milestone, feel free to change that!

At some point, far far off in the future. Maybe.

Some resources:

• JoinMarket's SNICKER docs
• Basic explanation
• Blog post
• BIP draft

I am aware that we have the dev docs, which are great, but we should probably also add a CONTRIBUTING.md file for people who are new to tracking bugs and stuff like that.

Here is a very simple one that I like. In general, every template that is older than 5 years should be good as a guideline. Most newer templates are as long as they are woke, and I feel like we can do without adding additional wokeness to this world.

Issue raised by Mr. Kukks and briefly discussed in Call 8.

The Web UI endpoint might be exposed publicly, e.g. via Umbrel, since everything that runs on Umbrel might be exposed and accessible via <public-ip> - so anyone might go to <public-ip>/joinmarket and access the interface.

By default, all wallets are password protected and locked, so this might not be as critical as one might think at first, but some access control might be good in any case. See RTL, Thunderhub, et. al. They all have the same problem and solve it in a similar way.

This Umbrel announcement might be relevant: https://community.getumbrel.com/t/umbrel-0-4-8-is-out-with-cryptographically-secure-default-app-passwords/4696

Maybe also do a seed quiz. See discussion in #62.

Add support to lock up funds in a fidelity bond.

As per Adam's comment below, we can use the gettimelockaddress API call to create fidelity bonds.

• Display info on Send page if either taker or maker is running and disable "send as collaborative transaction" (#86)
• Display info on Earn page if taker is running and disable starting maker (#82)

Will probably go live with Raspiblitz 1.8.

See the following issues in the raspiblitz repo:

• raspiblitz/raspiblitz#2747
• raspiblitz/raspiblitz#2987
• raspiblitz/raspiblitz#2891

We could/should go over the whole app and double check wording as most of it was done ad hoc during development. At least I didn't really put a lot of thought into it while developing. 😅

Bring back the non-functional websocket connection, which got removed in #45.

When I converted the prototype I couldn't figure out whether it is a problem in the web server/proxy or in the API's web socket which makes it fail. However, making this web socket connection work would be great, so that we can receive event updates via the API.