define a proper way to embed this project into `sv2-apps`

[GitGab19]

We need to figure out a proper way to add this project into sv2-apps.

It could be through a git submodule or similars.

[warioishere]

maybe do it the same way as I did on my gui implementation? We would jst need to remove the tp and do some little adjustments. Core and Testnet container already included, everythings works already quiet well:

Maybe we can use some stuff from there, i also have build a Monitoring for clients connecting the jd-client

https://github.com/warioishere/sv2-apps/tree/experimental/jd-gui-full-stack/miner-apps/jd-client

js place everything inside a jd-gui dir

[GitGab19]

I would prefer to keep the UI project in a different repo as it is now, to keep development workflows well distinct.

But if we end-up prioritizing the docker deployment of this UI, we could also think about simply publish this UI as docker image, and simply use it in the docker sub-directory at https://github.com/stratum-mining/sv2-apps/tree/main/docker.

Wdyt?

cc @lucasbalieiro

[warioishere]

sure thats reasonable, I will check your project the next days, maybe we can coordinate something. Need to get to fiat mining work now.

[lucasbalieiro]

I would prefer to keep the UI project in a different repo as it is now, to keep development workflows well distinct.

But if we end-up prioritizing the docker deployment of this UI, we could also think about simply publish this UI as docker image, and simply use it in the docker sub-directory at https://github.com/stratum-mining/sv2-apps/tree/main/docker.

Wdyt?

cc @lucasbalieiro

Agree with keeping a separate repository.

An alternative to using a submodule is a CI pipeline that publishes the output of npm run build (the generated dist folder) as an artifact. If sv2-apps wants to expose the UI, we could:

• add a CLI flag such as --show-ui to the apps.

  • when enabled, the command downloads the minified artifacts and, since axum is already included, starts a server that serves the static HTML

This avoids maintaining a submodule. We could invert the dependency: this repo monitors sv2-apps for new releases, triggers a build here, and uploads a zip containing the dist folder. It also removes the requirement for end users to install Node or build the frontend themselves.

This is just a brainstorming proposal and not a fully evaluated design.

For the Docker image, the same approach applies: download the dist artifact during the build. Alternatively, we can publish a separate image to the stratrumv2 Docker Hub account and add it as another service in the sv2-apps docker-compose.yml file.

[GitGab19]

add a CLI flag such as --show-ui to the apps.
when enabled, the command downloads the minified artifacts and, since axum is already included, starts a server that serves the static HTML

I think that here we could hit a problem: how can we have a good UX in the case where the user runs both JDC and tProxy as binaries? Are we gonna have duplicated UIs? Are we gonna indicate the user to enable UI only when launching JDC and not when launching tProxy?

I'm trying to clarify all these doubts right now, but I think it could make sense to start focusing on the docker deployment first, prioritizing the work related to that.

When considering binaries, the UX challenge arises in the moment we ask the user to run two different binaries (in case of JD), so adding the UI there is just gonna add additional complexity.

The best thing about the binary deployment is to have a single binary to launch, which has the UI embedded into it.

But we have some work to do to get there, eventually.

[warioishere]

Been looking into this more closely and here's what I think makes the most sense:

The UI talks to both jdc and tproxy, so embedding it into either binary is tricky — if that binary goes down, you lose visibility into the other one. And having --show-ui on both creates the duplicate UI problem @GitGab19 mentioned.

I'd treat the UI as its own standalone thing since it's really just an observer sitting on top of both services.

Short term: Docker image

• Add a simple Dockerfile to this repo (multi-stage: node build → nginx serve static files)
• CI publishes it to Docker Hub as stratumv2/sv2-ui
• Add one service entry to the sv2-apps docker-compose — done

Users running the docker setup get the UI for free, zero changes to the Rust code, repos stay fully decoupled.

Later: standalone binary for non-Docker users

• CI here publishes the built dist/ as a release artifact
• A small Rust crate in sv2-apps (axum is already a dependency) embeds those static files and serves them, with --jdc-url and --translator-url flags
• No Node needed on the user's machine, no submodule headaches

This way we avoid coupling release cycles, keep dev workflows separate, and the UI stays architecturally independent from both services. Docker first since that's already the recommended way to run things anyway.

This also plays nicely with platforms like Umbrel and Start9 which are Docker-based under the hood — having a published image makes it straightforward to package for their app stores down the line.

[warioishere]

To add to this — the vision shouldn't stop at monitoring. The UI should also be able to configure and control jdc and tproxy (start, stop, restart), not just observe them.

I've been experimenting with this in my jd-gui branch — it has a config form (tabbed: network, encryption, mining, upstreams, template provider), live TOML preview, and a setup wizard that auto-detects Bitcoin Core IPC. Bit of a mess but the idea is there.

To get there we'd need a few things on the sv2-apps side:

• Config endpoints on jdc and tproxy — GET/POST /api/config to read and update their TOMLs at runtime
• Lifecycle endpoints — POST /api/restart, /api/stop so the UI can control services without needing Docker socket access or process-level hacks
• Config reload support — ideally services can pick up config changes without a full restart (hot reload), but a restart endpoint works as a first step

In the Docker setup, some of this could be shortcut by exposing the Docker socket to the UI container, but proper API endpoints on the services themselves is the cleaner path and works for both Docker and binary deployments.

Something to build towards incrementally — start with read-only monitoring (what we have now), then add config management and controls as the services expose these endpoints.

[GitGab19]

@warioishere we're perfectly aligned on the strategy here, it's very cool to see that!

I'm currently working on a doc which can be used as a reference for the roadmap, which includes every point you made here.

I'll share it here once it's ready, and if we're all aligned on the plan, I'll start creating specific issues, and I'll transfer the roadmap in a github project on this repo.

[GitGab19]

Alright guys, here the doc I was mentioning, which tries to define a possible roadmap for what we're discussing here: https://docs.google.com/document/d/1hzxH1Fktq-tk9bwBO1GoxJyXKpASsg51IYStK9xXk0c/edit?usp=sharing

Feedback appreciated by everyone here @lucasbalieiro @warioishere @pavlenex

PS: if we are all aligned on the proposal, I'll start opening specific issues on this repo.

[warioishere]

I am good with that and I would be glad if I can be a part of it and help here and there

[warioishere]

If you want, I can start with Step1 merging the wizard into this repo:

Step 1: Merge Wizard into sv2-ui
Port sv2-wizard components (a customized version of it)
Add /setup route with mode selection (tProxy-only vs JDC+tProxy)
Detect configured state → redirect to /setup or dashboard

PS:

Actually I could do Steps 1-3 because I have did this already on my jd-gui which I showed you. Would it be okay if I integrate a bitcoincore setup for those that want to run this completly standallone? I would go pruned 550 here because we dont need a fully synchronized bitcoin core node for the templates.

I could present some working solution by the mid of this week.

[GitGab19]

Sure, feel free to open a PR with your proposal for that.

IMO the wizard components should be part of this project here, and trying to use the sv2-wizard package could simply add too much complexity without a clear benefit.

The UI should automatically take the user to /setup if it's the first time, to properly configure and launch the underlying applications needed based on the initial configuration.

But after that, the user needs to have a way to change mode (JD or not), modify pools, etc.

[warioishere]

Thats part of work in progress :) I'll add tabs for jd-client and tproxy settings so power users can do more advanced settings, change pool, change basic and adcanced configs, change mode after deploying a basic setup with the wizard.