Updates to PaymentRequest stuctures to align with the latest TSC spec.#69
Updates to PaymentRequest stuctures to align with the latest TSC spec.#69
PaymentRequest stuctures to align with the latest TSC spec.#69Conversation
c75950b to
0d29560
Compare
78b9d92 to
52bbdfb
Compare
…liance - Rename `PaymentRequest` -> `PaymentTerms` as `PaymentRequest` was the old BIP270 terminology for this struct - Update the payment.go:Validate() method for the new `Payment` struct
52bbdfb to
eb06553
Compare
payment_request.go
Outdated
| @@ -57,5 +104,5 @@ type PaymentRequestService interface { | |||
|
|
|||
| // PaymentRequestReader will return a new payment request. | |||
| type PaymentRequestReader interface { | |||
There was a problem hiding this comment.
shouldn't all places where we have PaymentRequest be PaymentTerms instead?
There was a problem hiding this comment.
Yes. I suppose it should. I have now updated all instances of PaymentRequest to PaymentTerms for go-dpp and the dpp-proxy.
This includes the websocket message types: paymentterms.create, paymentterms.response and paymentterms.error
For consistency.
jadwahab
left a comment
There was a problem hiding this comment.
I think we should have different folders/modules for different payment modes, what do you think? would be worth asking @theflyingcodr
87877c1 to
adee145
Compare
Seems like a good suggestion. I have refactored into a |
33a1dbc to
94bb7bf
Compare
…ing to place each of the three dpp message type structs in their own folders
94bb7bf to
246f1c1
Compare
|
This pull request looks stale. Feel free to reopen it if you think it's a mistake. |
|
Still discussing, sorry @AustEcon - early next week should have resolved the differences in opinion on this. |
…Envelope` wrapped `PaymentTerms` as the standard.
1d3f2db to
c0a49ee
Compare
c0a49ee to
330cf50
Compare
|
This pull request looks stale. Feel free to reopen it if you think it's a mistake. |
…hese fields do not feature in the TSC specification
|
This pull request looks stale. Feel free to reopen it if you think it's a mistake. |
|
This pull request looks stale. Feel free to reopen it if you think it's a mistake. |
|
This pull request looks stale. Feel free to reopen it if you think it's a mistake. |
As discussed with @jadwahab and @sirdeggen here is the PR for updating to the latest TSC spec: https://tsc.bitcoinassociation.net/standards/direct_payment_protocol/
Corresponding dual PR here: bitcoin-sv/dpp-proxy#57
So far this only updates the
PaymentRequeststructure which is enough for now to get ElectrumSV through the first part of the data flow for development...Still to do:
PaymentPaymentACKAdequate testing end-to-end against this codeUntil the
dpp-proxyis updated to the TSC spec, ElectrumSV will be building against this feature branch to avoid technical debt of the old message structures. So if you are not a fan of this implementation, that is no problem - it still unblocks Roger and I to keep progressing the ElectrumSV integration until the dpp-proxy master branch catches up. 😃