joinmarket-webui / jam Goto Github PK
View Code? Open in Web Editor NEWYour sats. Your privacy. Your profit.
Home Page: https://jamapp.org
License: MIT License
Your sats. Your privacy. Your profit.
Home Page: https://jamapp.org
License: MIT License
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? 🤷♂️
See Figma.
The current screen is fine and works well. The UI in Figma does look a bit better though.
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.
Follow-up to and extension of #12
See the Configuration page in the wiki.
At some point, far far off in the future. Maybe.
Some resources:
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:
joinmarket.cfg
All of the above should serve as a base for implementing #12
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 the current design in Figma:
In short:
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.
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
?
No designs or mockups of this screen yet, but it could contain something like:
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.
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, 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?
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 /unlock
API endpoint, see JoinMarket-Org/joinmarket-clientserver#1136
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 "flow" is already there but we could improve the UI a bit. (I really like the Figma version.)
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/
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.
Will probably go live with Raspiblitz 1.8.
See the following issues in the raspiblitz repo:
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.
Make the JoinMarket Web UI available as an app in the Umbrel app store.
Timeline
v0.9.5
is releasedv0.0.3
is releasedstandalone
image of server v0.9.5
and client v0.0.3
Draft
status of Pull Request in Umbrel RepoI 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.
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!
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.
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:
Examples that I like from the Bitcoin and Lightning world:
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!
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.
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
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".
English only is probably fine for a long while, but at some point having the UI available in multiple languages would be good.
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.
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:
npm version
)npm version
)master
is protected we'll need to pull-request the version bump and changelog to master.If that is correct, my question would be: Where should we add the tag? We can either:
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?
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.
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.
/session
immediately after starting taker(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.)
@secondl1ght reached out to the myNode team already, see mynodebtc/mynode#628
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. 😅
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:
/
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.
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.
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.