Send IRD to a target address(es) at reccuring intervals

[Eternalkr]

Ability to send IRD to target address/s' (one or more addresses) at reoccurring intervals (Every week, every 2 days, every week, every, month, every 2 months, every year, only on a specific date of a month.)

[danielclasen]

Thanks for the feature request @Eternalkr !

I really like the idea and I understand the need for a feature like that but I guess that will be hard to accomplish in the webwallet. The main architecture and idea of the webwallet is to run each users wallet in a completely sandboxed docker container only while the user is logged in. Inside of that docker container there is the users wallet file which is encrypted with a password even we don't know and do not want to know. Meaning that the user is in full charge of his/her wallet and we can not interact with the actual underlying wallet while the user is not logged in and did not unlock his wallet with the designated password. So it is nearly impossible for us to create new transactions on the blockchain on reoccuring intervals form the webwallet with the architecture we have choosen to provide more security for our users. Yet it might be possible and a nice new feature for the blockchain itself!

@steevebrush what do you think? Might it be possible to implement something like reoccuring tx on the core itself? I think we already have something like future tx and the only thing we would now need to store is the reoccurence pattern for the individual tx and make the nodes commit those tx whenever the patterns says to do so. Maybe a cron-like pattern or something very basic we could store on a reoccuring tx? From the webwallet (or also from the desktop, simple and walletd wallets) we would then have new methods to create/read/update/delete those reoccuring tx. With that we would not need to interact with the wallet anymore to spend some IRD e.g. every week. Hence I can not say what that does mean on a security perspective in the core but I would love to see a feature like that! :)

[steevebrush]

@Eternalkr Due to the web/mobile wallet architecture, as @danielclasen says, there will be no keys stored on the server side, we are also thinking about providing our own solid auth method. I did not think about the auth design yet, but for sure, we want to store the minimal informations and in no way the keys or wallets files, even the sandboxed container will be destroyed at the end of the session.

For the BC implementation :
I think it might be implemented at bc level, but yes, security have to be over-checked for this kind of feature... I mean only the user can access to this option with his own key.

For future tx :
Future tx is a walletd implementation so it have to be run on the green wallet itself, I never tried but doubt it's an original BC feature : when the walletd is closed, all the not released future tx are deleted... I have to test this : iridiumdev/Iridium-IRD-Core#25 !
For the cron kind job : it can be done at each new discovered block by adding a 'crontab' to the BC.