Is it bad to require a public HTTPS endpoint to receive money?

Applications and Use Cases
,
1

The main way to send payments over Interledger today is SPSP, which requires the receiver to have a publicly accessible HTTPS endpoint. Is this okay or does it impose too much of a burden on some users or eliminate important use cases?

This is no problem for hosted accounts or if we assume power users will host infrastructure on a server. However, it means that you cannot run a “full” Interledger wallet on a phone or as a self-contained desktop app. Are those setups we should be building for too?

2

Well right now the solution is to use localtunnel or ngrok for any of these p2p-like clients so the question boils down to what’s the way around this other than that?

Perhaps we could bundle a light version of the Interledger client for mobile or self-contained (connects to a service, realistically this would be a wallet) and have a self hosted variant for the enthusiast/infra provider? It doesn’t make sense for every single person to run a full-fledged connector, but everyone should have the option to, provided they have publicly accessible endpoint.

It’d be pretty neat if you could control fate of your funds without having to fully trust a connector and remain online all the time. I’m not sure there’s a way to perform that, but looking at pull payments with macaroons could lead somewhere.

3

The issue with using that type of service is that that entity (or a hacker if they take over the server) can redirect any money that would be coming your way to their own account. It might be slightly better if an Interledger service provider offered this service, because at least they’d be aware of the seriousness of that getting tampered with. I doubt localtunnel pays that much attention to securing that server since it’s not meant for production use cases.

Aside from a hosted SPSP server, the other options are either to:

  • build an alternative application layer protocol in which the sender starts with the receiver’s public key and uses Diffie-Hellman through ILP to generate the shared secret for STREAM
  • integrate with a decentralized identity solution that would resolve to a public key and follow similar steps as the previous bullet point
  • build an alternative transport protocol that uses hashing and a secret that only the receiver knows instead of the shared secret approach of STREAM (I’ll let @danrobinson expand on this)
4

I don’t think it really matters, because I think we’re vastly overstating the usefulness of SPSP.

I asked myself this question: of all the payments I make, how many of those require me to manually enter a unique identifier, and why is that? I would posit there are very few scenarios where manual entry/human readable identifiers are required which don’t have an alternative with better UX. Here’s some examples of Interledger use cases and/or real world use cases where a publicly accessible endpoint either isn’t necessary or is a moot point:

  • Trading: sender and receiver are in the same process, so no need to exchange the Stream secret
  • Web monetization / payments: requires hosting a publicly accessible endpoint anyways, right?
  • Point of sale: likely QR codes or NFC -based
  • Peer to peer, from mobile (e.g. Venmo): sure, I could enter their username, but often I find a QR code is easier and less error prone! (typically when I’m paying someone in person)
  • Peer to peer, from desktop: the UX of manually typing a payment pointer is bad, and if I’m copy-pasting the payment pointer from some other app into my wallet, copy-pasting gibberish with the Stream secret isn’t much different (a lot of Lightning services seem to require copy-pasting of BOLT11 invoices, for example). Ideally we’d want some kind of URI format with invoice-related information in it, so that you could click an interledger:// link or something of that sort, and it’d automatically open and populate the wallet on your computer with the payment information.

(Also of note: human readable identifiers in general open up other attack vectors, such as phishing, or attackers registering similar payment pointers for when they’re inevitably misspelled).

3 Likes
5

Even if you ran an Interledger wallet on your phone without acting as a server, you’d still have to be online at all times.

Phones are moving away from allowing background processes so it’s very possible that in a year this won’t work on mobile regardless. And on a laptop it would stop accepting packets once you close the lid.

Better to offer good tools for users to self-host SPSP servers in the cloud than fight the uphill battle of running what is logically a server on a device that isn’t always online.

Personally, I would rather trust someone to host my wallet but I understand why it’s important we offer an alternative to that.

Those are all good examples, and it makes me think that introducing end-users to the concept of payment pointers might be a waste of time in the long run.

All of those flows still benefit from the exchange of an identifier which is not the raw address+secret, though, so SPSP could still have value even if the URL itself isn’t entered by hand. Even in the case where a phone communicates payment details over NFC, it’ll still be hitting a server to fetch payment details unless the phone itself is connected to ILP.

2 Likes
6

I built a prototype for a mobile web application that requires users to create and provide a SPSP Payment Pointer in order to receive a proportion of the donations received by the app from Coil via a Revshare Pointer Server.

I’ve started to talk to prospective users over the past week. These prospective users are not technology savvy. However, in directing them to my app’s FAQ where they can find an explanation for Payment Pointers (copied from the Interledger website, pasted below), they seem to get it. I believe the email address analogy helps these individuals to quickly grasp the concept of Payment Pointers. Just like how you need an email address to receive mail online, you need a Payment Pointer to receive money online. It just makes sense to the layman (like me!). Also, I believe the short and comprehensible syntax of the Payment Pointer helps too.

“Payment pointers are a standardized identifier for accounts that are able to receive payments. In the same way that an email address provides an identifier for a mailbox in the email ecosystem a payment pointer is used by an account holder to share the details of their account with anyone that wishes to make a payment to them. It looks like this: $thisisanexample.com/bob”

In short, my prototype uses Payment Pointers. And so far, prospective users that I’ve talked to are grasping the concept of Payment Pointers and are willing to take the steps to create one (i.e., it does not seem to be imposing too much of a burden). Granted I am speaking based off of a small sample set at the moment.

You can find my prototype here: https://intense-journey-50822.herokuapp.com/home

1 Like
7

I would restate the above as:
"The main way to get STREAM connection credentials today is SPSP "

I 100% agree with @sharafian though that it is impossible to receive ILP payments (irrespective of the transport layer protocol you use) without an always online receiver that can fulfil the packets.

And I’d go one step further and say that if a receiver is sometimes offline and wants to give a 3rd party the ability to fulfil payments addressed to them, it is NOT possible to delegate this ability to the 3rd party without also allowing that 3rd party to steal the receiver’s money.

While this sounds appealing it will still require the user to delegate to some third party that is online to be able to perform the DH protocol with the sender to establish the shared key. In this case, you might as well just let that 3rd party host your SPSP Server for you…

I believe that the only way to solve this would be to support an alternative condition/fulfilment format which used signatures instead of hashes

2 Likes
8

Good points!

The value prop of SPSP for a remote/hosted STREAM receiver makes sense to me.

The only thing I’d say is, while certainly it’d be much better to be able to accept payments 24/7, I don’t feel it’s imperative.

For most clients, sending outgoing payments may be much more common than receiving them. And for the receiving peer to peer use case, being online is a limitation, but might not be a huge one (if using a QR code to exchange the PP or SPSP invoice anyways, you’re likely already online and a “waiting for incoming payment” screen could be built into the UX). But yeah, supporting “spontaneous” P2P payments wouldn’t be possible.

1 Like
9

Without going too much into practical implementation I would refer to the long time goals of Interledger

  • If Interledger is intended mainly to be used by banks, institutions, companies, then running almost anything shouldn’t be a big issue.

  • If also most of the end-users including lay mens - the “average Joe” should be able to comfortably use Interledger in casual life situations like paying for parking or at the Supermarket, then, usability-wise, it makes sense to simplify everything as much as possible (of course trying to keep it as secure as possible in the same time).

Going this branch, what is the level of control the users should have over their assets?

When I think about Interledger, sometimes I make analogies and references to classic banking. My money are in banks. The banks keep them - they are “the Ledger”. But they also operate them, they send and receive payments on my behalf. At least in practice, I fully trust the bank, which can in theory also freeze and/or confiscate my money on government or police orders, in case of a financial crisis, etc. The advantage is that I don’t care about operating anything but at most an app on the phone, which I start and stop anytime I want. The app is secure and easy to use by an “average Joe”.

As such, if the intent is that average people and casual situations should become a significant chunk of Interledger’s user pool, then, in my opinion, simplicity, user experience, comfort, ergonomy would be a relevant concern, besides security

People like simplicity and mobility, in my opinion many would be reluctant to starting computers, installing and configuring Moneyd, SPSP or equivalent, keeping them online, etc. Although we can imagine a phone app connecting to a system running at home, use cases would still be more limited in my opinion.

Perhaps pre-packaging everything and offering an (almost) automated deployment in some secure authenticated (cloud) environment with minimal setup would be a way to go? In my opinion, the casual user doesn’t need to know almost anything about the tech behind, unless they want to; My feeling is that it would be preferable for them just to subscribe, enter some initial minimal config and be ready to go on their phone or some minimal thing as a PC browser. Like subscribing to email or to a bank. Such a cloud environment could be ran/managed/supervised by Ripple, possibly? The same way Google manages the servers hosting the user email accounts; a company can have an email server, but casual users just have a light phone app or use a PC browser. These are money not emails, so possibly extra guarantees might need to be added, up to backing up and ensuring, globally or individually the cases where users would place extra trust in a third party (cloud hosting for example).

If everything would run somewhere else, a user could only run a light app with minimal config on his phone/PC (browser) from where he could authenticate, check and submit transactions in different forms - NFC, QR, manual, etc. I think this kind of simplicity and lightness in everyday usage would truly make ILP useful in casual life situations like paying a bill online or at gas station, restaurant, supermarket; and consequently, penetrate all market segments/regions and become global.

Indeed Interledger is about Money so this is not so easy. These are just some random thoughts maybe out of place, maybe said or thought before,. I just felt it might worth sharing, though