Add expiry feature

[chevdor]

I understand the gift is only reserved in the sender's account until the gift is claimed. it would be nice to define an expiry for the gift that schedules a transaction that cancels the gift after N days. This ensures that the reserved unclaimed gifts get freed at some point.

[shawntabrizi]

@chevdor usually it is an anti-pattern to schedule things in advance on chain when a user can just submit a transaction to do the same.

The reason for this is that anything that is scheduled on chain must occur or the state transition will fail. (this is those operations in on_initialize and on_finalize)

On the other hand a transaction can always stay in the transaction queue, or be dropped, or whatever, and the blockchain will not be affected.

So you can imagine that if we schedule many things, eventually all of those scheduled things on a single block will push the block over its limits and brick the chain.

Not saying that this operation is heavy relative to what a block can handle, but you can see that this is not a pattern we want to follow.

The summary is that blockchain automation is def not free, and unless something is critical to the state transition of the chain, should be "automated off chain"

[chevdor]

For sure, the user can do things manually but I don't expect users to bother following up. The main goal of this App seems to be to make it easy for gifters and recipients.

Imagine you send gifts to 10+ of your friends, you just want to make sure you get back your gifts after 30 days if some of your friends (if any) ignored their gift.

The issue with doing the solution where the app would do that off chain is that we would have to provide the app with keys to sign on our behalf (no go...) or allow the app's account to send a transaction on our behalf (using proxies maybe ?). This last option would also require to schedule calls because ideally, as a user, I would like to allow the app to only send specific extrinsics (so picking the right proxy type) and for a short period of time (= setting and unsetting proxies).

I keep coming back to what feels the best solution being to schedule this onchain and I wonder if we cannot "simply" make it so that the scheduled call will be successful in any case (to avoid the issue you mentioned):

• if your friend claimed the gift, the scheduled cancellation would do nothing and succeed
• if your friend did not claim the gift, the scheduled cancellation does run and cancells the gift

I doubt the chances that we spam one given block with many of those cancellations is very high:

• users will create gifts at a random time/block
• even if we fix the expiry duration to 30d (for instance), the expiry would then be random + 30d

An alternative could be to track down in the App every unclaimed gift and offer a button can cancel/recall the gift. This sounds less cool to me but does the trick as far as not leaving an account indefintely with unclaimed gifts.

Or do you have maybe other ideas ?

[hamidra]

I think the offchain option is possible with minimum custody. we can handle the logic to give gift revocation permission to the gift secret key so anyone with access to the gift secret will be able to revoke the gift. We are considering to run some small backend server for gift management so in that case the gift server can revoke the gifts using gift secret with no need to have gift sender to sign the revocation tx. Similar to providing a proxy account but since it is a totally independent account/key it only has access to the gift balance with no risk outside of the gift revocation/claim tx.