[WiP] add loopback transport in discovery methods

[michielbdejong]

work in progress...

[michielbdejong]

Had an interesting chat with @adrianhopebailie about this, some things that still need to be fleshed out would be how the application layer negotiates currency code/scale. Another idea that came up was that you could do receiver-initiated loopback, and it would be like IPR.

[michielbdejong]

For payment setup, need to add a way to discover a loopback server in:

• (IL-RFC-14) http-ilp,
• (IL-RFC-28) web-monetization,
• (IL-RFC-26) payment-pointers, and with that, web-payments
• (maybe) ILP URL scheme
• (maybe) SPSP

[michielbdejong]

Hm, maybe it's easier to extend SPSP, and catch payment-pointers with that, and with that web-payments and web-monetization. And then instead of adding a http-ilp scheme, http-ilp could also just use a payment pointer.

[adrianhopebailie]

Think this should be an extension of SPSP rather.
Example: A client that is paying $10 to a receiver may get the following SPSP response:

{
  "destination_account": "example.ilpdemo.red.bob",
  "loopback": "wss+btp://token@example.com/",
  "balance": {
    "minimum": "0",
    "current": "-1000"
  },
  "asset_info": {
    "code": "USD",
    "scale": 2
  },
  "receiver_info": {
    "name": "Bob Dylan",
    "image_url": "https://red.ilpdemo.org/api/spsp/bob/profile_pic.jpg"
  }
}

The client would then establish a BTP connection to wss+btp://token@example.com/ and after sending an ILP Prepare packet to example.ilpdemo.red.bob would expect to receive that same packet (with adjusted amount and expiry) arrive over the loopback BTP connection.

I don't think it's necessary to put the protocol in as this should be determined from the loop back URI implicitly.

[adrianhopebailie]

The "destination_account" could be left out and established via ILDCP but having it in here is an optimization

[michielbdejong]

but wouldn't it be better to have the full loopback_address including the sender's account at the receiver, so 'example.ilpdemo.red.bob.alice'?

[michielbdejong]

Think this should be an extension of SPSP rather.

I could go either way with this, I kinda liked using the switch that we already have at the payment-pointer level

[adrianhopebailie]

I think it's too early to be fragmenting the system like that. SPSP v3 which supports more transport options seems better than a whole new setup protocol to me.

The ability to support other setup protocols via Payment Pointers is future proofing and loose coupling so that if someone has a better idea than SPSP we can still use Payment Pointers.

That shouldn't be an excuse to not use SPSP when it actually already delivers everything we need for loopback IMO

[michielbdejong]

Talked to @emschwartz about this, he argued that it should be the client, not the server, who picks the transport. So I'll keep it at the payment pointer switch for now!

[adrianhopebailie]

it should be the client, not the server, who picks the transport

That is not how most protocol negotiation works. Servers usually provide options and clients pick from those.

Payment Pointers is not a protocol for discovering a transport protocol, it's a protocol for discovering information about a receiver, including all the transport protocols it supports.

The protocol negotiation built into Payment Pointers is not for picking a transport protocol its for picking a setup protocol.

Unless loop-back is incompatible with SPSP I don't see why you'd invent a new setup protocol.

What prevents the SPSP response from providing multiple protocol options to the client?

{
  "destination_account": "example.ilpdemo.red.bob",
  "shared_secret": "vdytf65rdhgcioIYbuffGKItgRfg"
  "loopback": "wss+btp://token@example.com/",
  "balance": {
    "minimum": "0",
    "current": "-1000"
  },
  "asset_info": {
    "code": "USD",
    "scale": 2
  },
  "receiver_info": {
    "name": "Bob Dylan",
    "image_url": "https://red.ilpdemo.org/api/spsp/bob/profile_pic.jpg"
  }
}

[michielbdejong]

@adrianhopebailie you're making a valid point, so I'll split up this PR into one part which just describes the loopback transport (which I want to keep simple and finish quickly), and a second part (which can take longer and be a more fundamental cleanup) dealing with cleaning up our setup protocols so that they support multiple transports.

[michielbdejong]

@sharafian what do you think of this PR's approach where:

• we register two http-ilp payment methods (one for LT and one for PSK),
• a payment pointer can be dereferenced in two ways (LSD and SPSP)?

And what do you think about Adrian's point that we should not use the switch at the payment pointer level, but should switch at the SPSP level instead?

[sharafian]

I personally think one of these should be the go-to standard, so most implementations don't need both. For now, though, I like the idea of doing this at the discovery level. Payment pointers already have protocol negotiation (via the Accept header) while SPSP doesn't. If you created a new accept format (like application/spsplt+json, or something), then existing applications wouldn't get confused by your SPSP responses.

[michielbdejong]

If you created a new accept format (like application/spsplt+json, or something), then existing applications wouldn't get confused by your SPSP responses.

That's what i did (see https://github.com/interledger/rfcs/pull/413/files#diff-26073d3cbab98c2b76aeb396ea5ef212R103), and i think Evan also preferred doing the switch there, but Adrian said #413 (comment)

[michielbdejong]

ah wait, i see the nuance of calling it SPSPLT instead of LSD. I think my name is more fun, though ;)

[sharafian]

Groovy

[sharafian]

Adrian has some points about how the LSD and SPSP fields are pretty much the same, but we'd still be creating a breaking SPSP version to add that feature (because it's breaking to not always use PSK). So I don't see much of a compelling reason why we should do SPSPv4 over LSDv1

[michielbdejong]

I'm going to Backronym LSD from "Loopback Server Description" to "Loopback Server Discovery", because I keep getting it wrong myself :)

[michielbdejong]

Implemented in https://github.com/interledgerjs/ilp-protocol-lsd

[michielbdejong]

We decided not to add Loopback to the RFCs repo until at least one application uses Loopback Server Discovery to set up an Interledger loop, instead of using a payment-pointer/SPSP to exchange a STREAM shared secret.