* feat(gui): add IntroductionModal component
* feat(gui): add interactivity to IntroductionModal
* feat(gui): create SlideTemplate component for IntroductionModal Slides
* feat(gui): add generic slides to IntroductionModal with images and content
* feat(gui): add Slide with SwapStatusAlert to IntroductionModal
* feat(gui): show the introduction only on the first app start
* feat(gui): make external links functional
* fix(gui): update github link to link to active repo
* feat(gui): replace old images with new mockups and update Slide05 content
* feat(gui): add CardSelectionGroup and CardSelectionOption components for improved card selection UI
* feat(gui): add FiatPricePreference slide to IntroductionModal
* feat(gui): save user preference regarding fiat prices
I set the initial store configuration for fetching fiat prices to false to avoid any calls to coingecko without user consent
* refactor(gui): remove old Slide05 component for improved codebase maintenance
* fix(gui): add UnstoppableSwap logo to FiatPricePreference slide
* refactor(gui): update image imports and improve slide content for introduction modal
* fix(gui): introduce ExternalLink component and update Slide05 to use it for external navigation
* fix(gui): replace webp images for introduction with svg mockups for improved quality
* fix(gui): change order of introduction slides, to asking for fiat price preference at the end
* refactor(gui): implement CardSelectionContext for managing card selection state
* refactor: texts in intro modakl
* fix(gui): update currency fetching SVG for improved design and clarity
* feat(gui): added changelog entry for introduction
---------
Co-authored-by: Binarybaron <binarybaron@protonmail.com>
* add comment to ConfirmationListener
* swap: always wrap monero::Wallet in tokio::sync::Mutex
Before, monero::Wallet wrapped a Mutex<Client>, and locked
the mutex on each operation. This meant releasing the
lock in between operations, even though we rely on the
operations being executed in order.
To remedy this race condition, we wrap monero::Wallet itself
in a mutex, requiring any caller to hold the lock for the duration
of the operation, including any suboperations.
* work on: releasing the lock while waiting for confirmations
Due to the newly introduced thread safety, we are currently holding
lock to the monero wallet while waiting for confirmations
-- since this takes a lot of time, it starves all other tasks
that do anything with the monero wallet.
In this commit I start implementing a change that enables us to release
the lock to the wallet while waiting for confirmations and only acquire it
when necessary.
This breaks with the current system of passing just a generic client
which implements the MoneroWalletRpc trait (which we use to pass a dummy
client for testing).
This commit is the first step towards a small refactor to that system.
* always pass Wallet instead of a MoneroWalletRpc client
By always passing Arc<Mutex<Wallet>> instead of MoneroWalletRpc clients
directly we can allow the wait_for_confirmations functions to lock the
Mutex and access the client when they need to, while releasing the lock
when waiting for the next tick. This stops the current starving of other
tasks waiting for the lock.
Since we use a dummy client for testing, this required adding a generic
parameter to the Wallet. However, since we specify a default type,
this doesn't actually require generic handling anywhere.
* add warning comment to monero::wallet::Wallet::from_dummy
* add timeout when waiting for monero lock during quote
This commit adds a timeout after 60 seconds when trying to acquire
the lock on the monero wallet while making a quote.
Should a timout occur, we return an error.
This makes sure that we get _some_ return value and that
starvation is noticed.
* fix lints, don't keep lock during loop body in wait_for_confirmations
* always immediately drop lock in wait_for_transfer
* fix clippy lints
* open wallet instead of failing when we can't create from keys
When we fail to create a monero wallet from keys, we will now try
to open it instead. I also renamed the method to be more consistent
with Wallet::open_or_create.
These changes are mostly taken from #260.
* improve documentation on monero::Wallet
* use Wallet::open instead of Wallet::Client::open
* use create_from_keys_and_sweep in bob's redeem_xmr
This commit deduplicates logic by using
create_from_keys_and_sweep_to in bob's redeem_xmr
and also adds the create_from_keys_and_sweep_to
method while making create_from_keys_and_sweep a
wrapper around it.
* add error context and improve logging
* fix deadlock in wait_for_confirmation_with, add timout to test
* re-add tor info box, show switch for toggling tor
* add use_tor to TauriSettings, only initialize tor client when it's true
* add warning log message when not using tor client
* change the label text of the switch, fail to align switch with SettingsBox icons
* move Tor settings to SettingsBox
This diff introduces a new "approvals" mechanism that alters the swap flow by requiring explicit user intervention before the Bitcoin lock transaction is broadcast. Previously, the Bitcoin lock was executed automatically without any user prompt. Now, the backend defines `ApprovalRequestType` (e.g. a `PreBtcLock` variant with details like `btc_lock_amount`, `btc_network_fee`, and `xmr_receive_amount`) and `ApprovalEvent` (with statuses such as `Pending`, `Resolved`, and `Rejected`). The method `request_approval()` in the `TauriHandle` struct uses a oneshot channel and concurrent timeout handling via `tokio::select!` to wait for the user's decision. Based on the outcome—explicit approval or timeout/rejection—the approval event is emitted through the `emit_approval()` helper, thereby gating the subsequent broadcast of the Bitcoin lock transaction.
On the UI side, changes have been made to reflect the new flow; the modal (for example, in `SwapSetupInflightPage.tsx`) now displays the swap details along with explicit action buttons that call `resolveApproval()` via RPC when clicked. The Redux store, selectors, and hooks like `usePendingPreBtcLockApproval()` have been updated to track and display these approval events. As a result, the overall functionality now requires the user to explicitly approve the swap offer before proceeding, ensuring they are aware of the swap's key parameters and that the locking of funds occurs only after their confirmation.
* cli: log the reason we can't find tx_cancel
When we can't find tx_cancel even though the cancel timelock
expired, we publish it ourselves.
However, some users had a problem where the tx_cancel wasn't
found even though it was already published.
This leads to the cli getting stuck in `CancelTimelockExpired`
when it should go to `BtcCancelled`.
This commit introduces an additional log statement that will
help us narrow down why that is.
* gui: update the documentation icon
Occasionally our ci jobs would fail due to network errors.
This is a known issue which is worked around by disabling
http multiplexing, for now. Hopefully.
There was an issue before we were falsely applying a default node to use and not actually iterating through our list and checking for availiability. This commit fixes this issue and removes a few dead nodes.
