Subscriptions on the token interface

[true mason]

Following yesterday's conversation (#🔹｜developer-chat message), I forked the soroban-examples repo and added a quick change to the token example so it allows subscriptions. Now why do I think the token contract is the correct place? Because users are used to the idea of subscriptions with their cards/banks and we normally think about cards/banks as balances in a single bank/fintech (how much money do I have in my euro account? and how much in my dollar account? Is my X credit card with enough funds?) and a token contract in some way is also a balance on my account.

As an example I will take wise.com (but there are multiple options like this): One single account with multiple balances with their own denominations (eur, usd, gbp, etc) which it's like one stellar account with different tokens balances. By having simple subscriptions on the token interface we can emulate something similar for the vast majority of use cases that need a subscription without the risk of allowing third parties with huge allowances like people do on ERC-20 alike systems (and at the same time we teach devs because I always need to remove the allowance and create one again since devs there always asume people gave them infinite allowance).

Now, being honest even without this at the token interface we still can create subscriptions either by having a custom asset or by using allowances with a subscription contract but having it at the token interface remove the possible drawbacks of those two options

Here is the added coded: https://github.com/stellar/soroban-examples/compare/main...earrietadev:soroban-examples:feature/subscriptions

PS: This is not final code, it's more to show what I meant during that conversation and because of that it doesn't have events, checks nor testing is valid but if people like the idea I can improve it and add everything that is missing for a potential pull request

Posible use cases for this type of simple subscription:

• Regular subscriptions services: imagine paying netflix directly from your stellar account
• Investment apps: similar to what brokerages do when letting you buy certain assets on a monthly basis
• Automatic saving: Similar to the one above but this is offered by banks when you want to send funds to your savings account from your current account after you get your wage
• Automatic donations: Here in Chile we can set our bank accounts to donate to firefighters and other institutions a specific amount on a period of time, on other blockchains people try to emulate this with infinite allowance and an smart contract (third party risk of getting charge more than what you agreed to)

[fringe meadow]

I definitely see value for tokens to contain some subscription logic like you have detailed here.

However, I think I disagree that the standard token interface (is there a name for this yet?) should contain these types of functions. In my opinion, I think this is too constricting to a specific subscription implementation that all tokens will be required to implement.

At a high level it feels like the mechanics of the subscription should be up to the subscription service (Netflix), instead of a token (like USDC).

[pure trellis]

thanks for the proposal. this helps me to demonstrate why I think this is too specific to belong to the token interface, as this implementation is somewhat different from what I sketched myself when thinking about this. Here are a few requirements questions that I think aren't quite possible to answer in a general fashion:

• Can there be multiple subscriptions for the same pair of addresses?
• Should it be possible to charge the partial amount of subscription?
• Should it be possible to increase the subscription amount? How should we protect user from double-charges if the subscription is modified?
• Should the subscription period be tied to the time when it has been created or a certain 'absolute' period? (like 5th of every month)
  I don't think there is a 'right' answer to these because the requirements might be different for different scenarios. which is why I think this functionality is not generic enough to belong to the general token interface

if the account-based approach seems too hard to implement, it should still be possible to limit trust to 1 contract. e.g. you have a 'subscriber' contract and you give a big/unlimited allowance to it and setup your subscriptions with it. then instead of withdrawing subscriptions from you, another contracts would withdraw subscriptions from the 'subscriber' contract. this way the user only needs to trust the 'subscriber' contract and manage a single allowance. again, even that might seem like too much work, but I really don't think there is an answer that provides enough security while also being very simple to use

[true mason]

I have thought about those questions for a while and here is what I thought about them:

Can there be multiple subscriptions for the same pair of addresses?
No and that's because most people and services don't do that, for example if you sign up for Netflix/HBO/Uber/etc you don't have multiple subscriptions with the same service so most users will see their accounts as one address and the services they are using (the contract or another user charging the sub) as the other address

Should it be possible to charge the partial amount of subscription?
I don't think so because if is not constant then is not a subscription and not the price you agreed to... but this might be something that depends on each personal point of view. What I have seem from working with projects that handle subscriptions is that clients get confused when prices are not constant

Should it be possible to increase the subscription amount? How should we protect user from double-charges if the subscription is modified?
In my opinion it shouldn't, like with most subscriptions you first cancel your current plan and them you sign up for another plan. The double charged should be protected by the period you agreed to

Should the subscription period be tied to the time when it has been created or a certain 'absolute' period? (like 5th of every month)
Absolutes will require timezone, months and years distinction so in my opinion we could say is a different kind of subscription and is something businesses will need to deal with with their own solutions if they want to support something more complex

I understand subscriptions is something that is not fully generic because some businesses might have their own requirements, but I still find the tradeoff worth it because users gain a more secure and easier experience while supporting most of the use cases