Static invoice server #621
Conversation
|
👋 Hi! I see this is a draft PR. |
src/config.rs
Outdated
|
|
||
| /// The [`BlindedMessagePath`]s that we will use as an async recipient to interactively build [`Offer`]s with a | ||
| /// static invoice server, so the server can serve [`StaticInvoice`]s to payers on our behalf when we're offline. | ||
| pub static_invoice_server_paths: Option<Vec<BlindedMessagePath>>, |
There was a problem hiding this comment.
Hmm, assuming this might not end up being the only config option regarding async payments, we should probably move this to an AsyncPaymentConfig sub-config, similar to what we do for anchor channels, for example.
Also note that we'll need to expose all of these values in Uniffi, too, so we'll need to see whether BlindedMessagePath is easy enough to expose, or if we need a simpler local type or bindings-compatible type wrapper.
There was a problem hiding this comment.
Can we not expose this to Uniffi initially? To keep scope down.
There was a problem hiding this comment.
Can we not expose this to Uniffi initially? To keep scope down.
No, especially since this is meant to be client-side API and it's part of the Config now, we need to expose it in Uniffi.
There was a problem hiding this comment.
Can't we conditionally disable that? I mean for MVP we don't need to go full out on bindings.
There was a problem hiding this comment.
Not sure what you mean by "full out on", given it's not that much work?
We generally aim to keep up feature parity for bindings use, also as a) it otherwise will get hard to follow which feature is available where and b) people tend to never get back to such things once PRs are merged.
There was a problem hiding this comment.
My thinking is that extra work (mapping / simplifying types) specifically for binding may not be worth it for the MVP.
src/builder.rs
Outdated
| @@ -544,6 +550,15 @@ impl NodeBuilder { | |||
| Ok(self) | |||
| } | |||
|
|
|||
| /// Sets the [`BlindedMessagePath`]s that we will use as an async recipient to interactively build [`Offer`]s with a | |||
| /// static invoice server, so the server can serve [`StaticInvoice`]s to payers on our behalf when we're offline. | |||
| pub fn set_paths_to_static_invoice_server( | |||
There was a problem hiding this comment.
Note this will also need to be added on the uniffi variant of the builder.
src/lib.rs
Outdated
| /// [`StaticInvoice`] with the static invoice server. | ||
| /// | ||
| /// Useful for posting offers to receive payments later, such as posting an offer on a website. | ||
| pub fn get_async_receive_offer(&self) -> Result<Offer, ()> { |
There was a problem hiding this comment.
We def. wouldn't want to add this here. Rather, it either should be part of the Bolt12Payment API, or even would need to be a separate, parallel AsyncPayment API module.
As part of the version v0.3 release we switched to the upstreamed `OutputSweeper` which slightly changed our serialization format, having us run a migration step on startup for backwards compatibility ever since. Here we drop the migration code running on startup, for simplicity's sake, but also because it's going to be async going forward and we currently don't have a runtime available on startup (which might change soon, but still). As the v0.3 release now well over a year ago, it's very unlikely that there are any v0.2 (or even v0.3) users left. If there are any affected users left, they'll first have to upgrade to any version pre-v0.7, startup, and then upgrade to v0.7 or later.
.. as having them in two places doesn't make sense
.. we now apply the LSPS2 client-side overrides on a per-counterparty basis, not as soon as we act as an LSP client
.. we implement the `async` version of `ChangeDestinationSource`, and, to make all involved objects `Send`, we drop the `Deref` generics for concrete `Arc`s everywhere.
We switch to use `rustls-ring` everywhere, which is necessary for Swift builds, but also generally makes our lives easier.
joostjager
force-pushed
the
static-invoice-server
branch
from
a6fc7f2 to
4bcdc95
Compare
joostjager
force-pushed
the
static-invoice-server
branch
from
4bcdc95 to
e2f293b
Compare
| min_interval: Duration, | ||
| } | ||
|
|
||
| impl RateLimiter { |
There was a problem hiding this comment.
Keeping it simple here
src/static_invoice_store.rs
Outdated
|
|
||
| pub(crate) struct StaticInvoiceStore { | ||
| kv_store: Arc<DynStore>, | ||
| rate_limiter: Mutex<RateLimiter>, |
There was a problem hiding this comment.
Needed to add Mutex here even though I don't think it is used concurrently. Otherwise handle_event needed to be made mutable, the Arc higher up no longer working, etc.
| } | ||
| } | ||
|
|
||
| pub(crate) async fn handle_static_invoice_requested( |
There was a problem hiding this comment.
Async, prepare for async kv store.
No description provided.