Merge pull request #13 from dunxen/2294-offers-handling

Add PR2294 remaining notes

Author: dunxen

_posts/2023-05-23-#2294.md

@@ -1,32 +1,65 @@
 ---
 layout: pr
 date: 2023-05-23
-title: "Bolt 12 Offers message handling support"
+title: "BOLT 12 Offers message handling support"
 pr: 2294
 authors: [jkczyz]
-components: []
+components: ["offers", "onion messages"]
 host: dunxen
 status: upcoming
 commit:
 ---
 
 ## Notes
 
-BOLT 12 Offers essentially provide a way for a Lightning node to receive payments through the use of a static identifier (they can be long-lived).
-Offers do not replace BOLT 11 invoices, in fact, they work in tandem. Readers of an offer will be able to request invoices via [onion messages]
-using a [blinded path] to the creator of the offer.
+BOLT 12 offers essentially provide a way for a merchant to receive payments through the use of a static identifier (they can be long-lived).
+Offers do not replace the need for something like invoices, in fact, they work in tandem. Readers of an offer will be able to request invoices
+via [onion messages] using a [blinded path] to the merchant. This provides recipient privacy. In fact, any onion messages, not just for offers,
+can use a blinded path.
 
-PR [#2294] introduces message handling for offers, so that LDK and also adds support for actually replying to onion messages which is an essential
-part of the offer protocol.
+PR [#2294] introduces onion message handling for offers so that LDK can interpret offer payloads. It also adds support for actually replying to
+onion messages via reply paths in general which is an essential part of the offer protocol and other uses of onion messages. The reader of an
+offer would create an `InvoiceRequest` payload to send to the merchant (to a blinded path provided in the offer contents) who would then reply
+with an `Invoice` requesting payment or an `InvoiceError`. If an `Invoice` is received, the payer can then pay the invoice (also to a blinded path)
+or respond with an `InvoiceError`.
 
-_More notest to follow_
+```
+         A successful flow
+ ┌─────┐                   ┌─────┐
+ │     │  InvoiceRequest   │  M  │
+ │     ├───────────►(BP)──►│  E  │
+ │  P  │                   │  R  │
+ │  A  │     Invoice       │  C  │
+ │  Y  │◄─(BP)─────────────┤  H  │
+ │  E  │   (reply path)    │  A  │
+ │  R  │                   │  N  │
+ │     │     payment       │  T  │
+ │     ├──────────►(BP)───►│     │
+ └─────┘                   └─────┘
 
-## Questions
-1. Did you review the PR? [Concept ACK, approach ACK, tested ACK, or NACK](https://github.com/lightningdevkit/rust-lightning/blob/master/CONTRIBUTING.md#peer-review)?
+* BP: Blinded Path
+```
+
+The PR adds the `OffersMessageHandler` trait where implementors handle incoming `OnionMessage`s containing an offer message as payload.
+`ChannelManager` implements this trait, but it remains a stub for this PR.
 
-_More questions to follow_
+## Questions
+1. Did you review the PR? [Concept ACK, approach ACK, tested ACK, or NACK]?
+2. The PR introduces the `MessageRouter` trait for finding routes for onion messages. `MessageRoute::find_route` implementations must
+   return a `Vec<PublicKey>` when provided a sender `PublicKey` and a `Destination`. What is a `Destination` in the onion
+   messages context and which `PublicKey`s should an implementor be returning from `find_route`. Is `find_route` a good name? Any other
+   ideas for a name?
+3. To support replies, onion message handlers were modified to return an optional response message. How does a recipient know where a
+   reply should be sent? When replying do we ever know the original sender (the reply's recipient) node ID/pubkey?
+4. Currently a BOLT 11 invoice exposes the payee's node ID explicitly or via signature recovery. Without BOLT 12 (and blinded paths)
+   and currently doable on the Lightning Network, is there any possible way to gain any level of privacy in this regard, or would
+   the payer always know the payee's pubkey? How could we at the very least try make the effective payee not seem like the final
+   recipient of the payment?
+5. We've generally covered one kind of payment flow scenario up to now. What other payment flow does BOLT 12 enable and how does this
+   differ to the one we've discussed?
 
 [onion messages]: https://github.com/lightning/bolts/pull/759
 [offers]: https://github.com/lightning/bolts/pull/798
 [blinded path]: https://github.com/lightning/bolts/blob/aad959a297ff66946effb165518143be15777dd6/04-onion-routing.md#route-blinding
-[#2294](https://github.com/lightningdevkit/rust-lightning/pull/2294)
+[#2294]: https://github.com/lightningdevkit/rust-lightning/pull/2294
+[Concept ACK, approach ACK, tested ACK, or NACK]: https://github.com/lightningdevkit/rust-lightning/blob/master/CONTRIBUTING.md#peer-review