-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated HTTP-ILP (Continuation of #149) #306
Conversation
0014-http-ilp/0014-http-ilp.md
Outdated
} | ||
``` | ||
|
||
The HTTP-ILP server module now knows the ILP address and caches it in memory for a certain period (depending on the cache header of the above request.) The reason we had Ankita enter the SPSP address and not the ILP address is because the ILP address may change over time as ILP providers change their routing structure. Note that ILP may support multihoming (this is still being debated as of this writing), so there may also be more than one ILP address. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that ILP may support multihoming (this is still being debated as of this writing), so there may also be more than one ILP address.
This can be removed
0014-http-ilp/0014-http-ilp.md
Outdated
|
||
### 2.2. Server rejects request, because token is new and unfunded | ||
|
||
The server returns an HTTP error of `402 Payment Required` and includes response headers showing the amount (how much the request would have cost), an ILP address and a condition seed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It says it will show the amount the request would have cost but the example doesn't show that
0014-http-ilp/0014-http-ilp.md
Outdated
|
||
The condition_seed is now a shared secret between the client and server, but will be unknown to any third-party connectors between them. | ||
|
||
That means that if the payment fails, the client can blame the server (assuming it considers itself honest and not compromised.) The client can't prove any wrongdoing to a third party, but since amounts are likely to be very low, this probably wouldn't be worth doing anyway. Also, proving wrongdoing would also involve proving that the server did not provide the agreed-upon service, which is probably near impossible in most cases anyway. However, since it can detect malicious behavior, the client can blacklist malicious hosts and not deal with them in the future. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need this explanation. It's more confusing than helpful
0014-http-ilp/0014-http-ilp.md
Outdated
|
||
The `fulfillment` is generated as: | ||
|
||
* Fulfillment: `HMAC(SHA256, condition_seed, destination_account || destination_amount)` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't it also include the pay_token
?
Is there a reason why this protocol doesn't use standard PSK?
0014-http-ilp/0014-http-ilp.md
Outdated
|
||
When the prepared payment reaches the receiving wallet, the webhook that is registered with the ankita+filepay@nexus.justmoon.com receiver is triggered. Note that the wallet does not fulfill the payment yet. | ||
|
||
### 2.4. Wallet POSTs a payment notification |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just have the server connect to the ILSP using something like BTP, rather than creating yet another encoding for ILP payment details? Websockets might not be ideal but I think it would be better if the server itself were a standard ILP receiver using some ledger protocol to talk to the ILSP.
This should describe what /~https://github.com/justmoon/koa-ilp does now. A lot of the contents seem dated |
In the updated version, the And that's also the header that koa-ilp produces. So that's probably the one we want to document in this RFC and use in the streaming payments tutorial |
ff6e28c
to
417388c
Compare
Updated the documentation to remove the webhooks stuff (koa-ilp now just uses a plugin). |
0014-http-ilp/0014-http-ilp.md
Outdated
|
||
### 1.1. Server admin installs an ILP payment module | ||
|
||
After deciding to use HTTP-ILP, Ankita searches the web on instructions on how to set this up. She finds an open-source HTTP-ILP server module which is compatible with the REST framework ([Koa](https://koajs.com)) that she is already using. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should include a link to the koa-ilp module too
0014-http-ilp/0014-http-ilp.md
Outdated
|
||
Next, Ankita logs back into her server and edits a config file of the HTTP-ILP server module to enter the plugin type and credentials she obtained: | ||
|
||
``` ini |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now this is configured through the environment, not an ini file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels weird that an rfc describes one specific implementation in such exact detail, but at the same time if the only current implementation uses env vars, then ok let's follow that example in the rfc too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed it to env vars, but not sure it now matches koa-ilp, because of interledgerjs/koa-ilp#4
0014-http-ilp/0014-http-ilp.md
Outdated
|
||
### 1.4. Paid HTTP server fetches receiver information | ||
|
||
When the HTTP-ILP server module loads up, it uses [plugin#getAccount](../0004-ledger-plugin-interface/0004-ledger-plugin-interface.md) to look up the Interledger address from the plugin. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The plugin also gets a subscription to its ledger in order to listen for incoming payments
0014-http-ilp/0014-http-ilp.md
Outdated
|
||
### 2.1. Client generates a server-specific token from the hostname and its local secret: | ||
|
||
The uploader tool contains an HTTP-ILP client module. This client module may for instance generate and locally save a `client_secret` using 256 bits of cryptographically secure randomness. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be worth mentioning the existing client tools, superagent-ilp
and ilp-curl
0014-http-ilp/0014-http-ilp.md
Outdated
|
||
### 2.2. Server responds with payment details | ||
|
||
The server returns an HTTP error of `402 Payment Required` and includes response headers showing the amount, an ILP address and a shared secret. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The server doesn't respond with 402
to an OPTIONS request; it uses a 204
. 402
is returned if the actual API call is attempted without payment.
Pay-Balance: 0 | ||
``` | ||
|
||
The client can now use the shared secret to create a condition to pay this host. The shared secret may for instance be generated by the server as follows: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should explain that the destinationAccount and sharedSecret are used as the parameters to PSK
0014-http-ilp/0014-http-ilp.md
Outdated
|
||
When the prepared payment reaches the server, it is fulfilled and the token's balance is increased. | ||
|
||
There is a chance that the HTTP-ILP server module will process the payment, but the fulfillment doesn't make it all te way back to the sender. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
te -> the
0014-http-ilp/sequence.mmd
Outdated
participant Payee | ||
activate Payer | ||
Payer->>+Payee: Attempt Request | ||
Payee-->>-Payer: 402 Payment Required |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is describing the OPTIONS
flow, it should begin with an OPTIONS request that ends with a 204, rather than a regular request that ends with a 402.
|
||
``` http | ||
HTTP/1.1 200 OK | ||
Pay: 10 us.nexus.ankita.~recv.filepay SkTcFTZCBKgP6A6QOUVcwWCCgYIP4rJPHlIzreavHdU |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unhash might make a better example application, because we know exactly what the API calls look like for it. For instance, an Unhash OPTIONS
request includes the Unhash-Content-Length
header to calculate the price.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I'll add Unhash-Content-Length
to the OPTIONS call and explain that other services would have other product descriptors which the client can add to help determine the price for a request.
0014-http-ilp/0014-http-ilp.md
Outdated
|
||
Notice how the 100 units credit from the payment was added to the balance and the 10 unit cost for the current request was subtracted. | ||
|
||
### 3. Streaming flow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the streaming flow is different enough that it should go in another proposal. The HTTP-ILP described here is pretty strictly request/response rather than streaming
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I'll move that to a separate PR.
Unfortunately, Github doesn't seem to link it correctly otherwise.
9caf6ca
to
58d8dcb
Compare
X-Pay
to justPay