Pull Payments

pull-payments
spsp
application-layer
pre-rfc
#27

Tangent: It might be overkill for what we need, but I found this recurrence rules spec while looking at the Google Calendar API:
https://tools.ietf.org/html/rfc5545#section-3.8.5

There’s also a JavaScript library

#28

@wilsonianb Thanks for sharing that. However, I agree with you assessment.

I found using ISO 8601 durations in combination with cycles to be very slim, understandable, and easy to implement.

#29

This is great! I like the idea of supporting both the “use it or lose it” style and the constantly accumulating one.

I don’t think this is necessary. If you set it up with cap = true and an interval of 1 second, you might have some strange behavior but we can just put a recommendation in the spec that you may not want to do this rather than actually restricting it.

Originally I didn’t like this idea that much but thinking about it more, it does sound useful and not that difficult to implement. I was thinking we would need this to be calculated through the Interledger network, requiring landmarks and something along the lines of ilp-price. However, since this is just guidance for the provider, they can use whatever method they want to get the price (such as a simple external API).

The one thing to consider is how to handle the exchange rate changing over the interval period. Maybe you would just use the average exchange rate over the period since the last time you updated the pullable amount.

Overall, nice work @sabinebertram and @wilsonianb!

@sabinebertram are you working on an implementation of this already?

#30

Fair enough.

This means that we have to keep track of when the last pull was made as well as exchange rates. It feels like overhead to me. The client can pull whenever she wants within the interval so she can pull when she likes the exchange rate. I would just use the spot rate at the moment of the pull. I guess you can argue that this is a disadvantage for the server but this incentivizes her to make good decisions about her currency as well as the pull agreement currency.

Yes I am. Here is the latest version, already including offline token generation support: ilp-spsp-pull-payment-server. I also updated ilp-protocol-spsp and ilp-spsp accordingly. I’m working on an implementation that allows the client to pull less than the full amount per interval now and wanted to tackle the exchange rate topic next.
I have also already worked on an integration of pull payments within codius, however, this is still based on older versions of pull payment parameters.

One thing that is still not clear to me. What does the query of the token endpoint return? Only destination_account and shared_secret or also some information about the pull agreement that can be used to display it in e.g. the customers wallet? And if so, what do we want to include?

1 Like
#31

I’m ambivalent about including pull agreement details. They definitely shouldn’t be required (it should work with just destination_account and shared_secret) but could probably just be optional (like the push payment detail).

#32

I agree. I would make them optional but include them to have a description of the parameters we discussed over the course of this forum thread.

On that point, do we want a different spec for the token negotiation and creation phase that makes the parameters we discussed mandatory? Or is that part of this spec?

#33

A couple variations to consider:

  • Replace cycles with an expiration time
  • Make start, interval, cycles/expiration, and cap optional

Together, that would let you provide just an amount (and optionally expiration) for a one-off payment. An expiration (vs cycles) also seems advantageous for shorter (ex. 1 second) intervals.

edit: actually, cycles and expiration are probably distinct things. cycles could be used to specify when to stop increasing the available balance, whereas expiration would be used to set the available balance to zero / invalidate the endpoint.

#34

I would argue against that. A time makes it way more complicated because what happens when the intervals do not fit exactly in the period between start time and expiration time?

We can still make start, interval, cycles, and cap optional, i.e. if only the amount is given, set the start to now, the interval to default (let’s say 1 day) and cap to false. This way, the amount is pullable forever.

This sounds reasonable. It also crossed my mind today that there is no clean-up functionality for payment pointers that are out of money yet.

edit: However, adding that for out-of-the-money pointer should be easy to get. The question is whether we want an expiry time for payment pointers that are still in the money.

#35

I vote yes to that being an option

#36

I don’t object. I’m sure that will be useful in some cases. I’ll add it to the spec as an optional field.

#37

There is a new PR only containing the new pull payment spec ready for review: https://github.com/interledger/rfcs/pull/514

#38

… would any of you be interested in helping me put this to a “test case” with a site that is dedicated to xrp, is a membership site and the service can work with 1xrp/day?

#39

Hi Jason, Welcome to the thread!

I am not sure how practical such an implementation is at the moment because all of the members of your site would have to run their own pull payment SPSP server (plus moneyd). This is a lot of effort.
I have been talking to some wallet providers who are interested and willing to add the possibility to create pull pointers to their services. This would make pull payments 100 times more feasible. However, there is no provider yet that has that feature, at least not that I know of.
If you nevertheless want to give it a go, have a look at my ILP SPSP Pull Payment Server. This (or something similar) is what each of your members has to have running for you to pull 1xrp/day.

#40

Ms. Sabine … thnx for getting back to me so quickly. =) … I know all about how difficult it is for ‘recurring payments’ with xrpl and ilp, as I have been chatting with multiple people like Wietse Wind from XRPL Labs about the project for many months now.

Since there are no wallet providers that are interested, I would think that the next best thing is to create the platform. I can attest to many people out in the cryptosphere (is that a word?) that would love the ability to have ‘recurring payments’ on their membership sites for premium content.

Is there a place where we can chat about this further without destroying this awesome thread you have put together here?

#41

I can start a channel in the Interledger slack workspace.

1 Like
#42

awesome idea. I’ll have to dust off my slack credentials

#43

@JasonArmbruster let’s chat…

We’re working to enable something like this for Coil subscriptions and are keen to extend this to be more generally useful.

Created the Slack channel:
https://interledger.slack.com/archives/CJRSD0NQY/p1558029719000300

#44

Im on my way over … Adrian, I follow you on Twitter, follow back?

#45

@adrianhopebailie it does seem that you must invite me. my email is fxjason at gmail dot com

#46