Standard proposal draft (2nd iteration, Stef & Luka)

[lknix]

This is a second iteration of the proposal. Interface has been divided into:

1. Read interface
2. Write interface
3. Metadata interface
4. Interface for processor support

Changelog:

• support for arbitrary payment assets
• support for arbitrary large number of subscriptions (provider's side)
• support all commonly used subscription models (pre-paid, post-paid, limited lifetime, fixed/varying payment amounts, discounted/trial periods)
• creating a subscription is now out of scope of the standard
• added rationale section to explain reasons behind design decisions
• etc.

[kosecki123]

What's actually the definition for the provider? Is that the destination address for the payment?

[StefanSimec]

Yes. I agree. A broader term like "destination address" would be better.

[lknix]

Yes, we identify providers by their destination address.

[kosecki123]

What's the purpose of having this function? Can be easily done using getUserSubscriptionProviders.

[StefanSimec]

This interface takes into account not only a "contract-per-subscription" model but also a model where one smart contract serves all subscriptions. Additional functions are necessary for such model to be scalable enough to handle millions of subscribers/providers/subscriptions...

Subscription query would then look something like this:

1. Get number of all subscriptions (needed for pagination)
2. Get subscription IDs using pagination
3. Get subscription info

[lknix]

As @StefanSimec said - we need to enable arbitrary number of subscriptions per provider. Thus e.g. getProviderSubscriptionIds which returns an array of subscription ids is not scalable. Yes, it can handle tens of thousand of elements, maybe even hundred thousand. But at some point the response becomes too large. So the idea here is:

1. Get the number of provider subscriptions.
2. Get a subset of provider subscriptions by passing index and number to the get function. Index is index in the subscription array and number is number of elements starting from the index.

This allows SDKs to easily implement pagination and it solves the scalability problem. And again, we're just building on the shoulders of 721, which has similar requirement.

[kosecki123]

I think from the user perspective does not really matter who is executing the payment hence this part doesn't seem to be necessary. The only reason (maybe) to have it is to solve the coordination problem by assigning the processor for the payment.

[StefanSimec]

This is not part of the main standard but an extension aimed towards subscription providers who might want to delegate some of the responsibility.