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


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?


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.


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)

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).


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.


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: $”

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:

1 Like