RECURRING TRANSFERS
Sending recurring transfers is something that @howo is adding to the next hardfork. That is a great tool. I am not sure what kind of API it will support. Also i am not sure if transfers could be identified TIPS vs the other things they may be considered (aka payments)
I guess we can see if @howo has some thoughts on it.
SEMI-AUTO?
Also recurring transfers are likely TIME based and probably can't be given to individual posts and that's what a TIP is so my guess is some sort of semi-auto system for tips could be a solution.
For example you state your intention to tip a list of content creators based on POSTS (aka every post or one post a day or one a week) then the system would find all the instances that should be triggered but because tips are an active key transaction you would likely need to confirm the transactions.
I implemented memos on the recurrent transfers, so it would be possible for front ends to add some identifier on recurrent transfers and build on it :)
In terms of apis I haven't built many apis yet. So far it's just an api call "find_recurrent_transfers" to see where your recurrent transfers are going. Thinking of building more in hivemind or directly in hived.
What kind of apis would you like to see @jarvie / @asgarth
I think this is needed also the other way around. To see which recurring transfers an account is going to receive. Suppose you are a content creator you want to see the 'incoming' recurring transfer, not the outgoing.
If you can include all the operation details (including the memo) will be great :)
Another point is how to fetch the transfers history. Are you going to use a new operation type? Or just a standard transfer? Ideally we would like to show a filterable list of all the recurring transfer received/sent by an account.
Everything else in my opinion should not be included in the core API 👍
Haha I figured you'd say that. There is a good chance that we might implement this at the hivemind level instead of hived because those kind of indexes increase the ram requirements of nodes and we want to avoid that.
New virtual operation ! Two actually, you will find them in the usual get account history call
fill_recurrent_transfer_operation and failed_recurrent_transfer_operation
fill is pushed when the recurrent transfer was a success, failed is when it wasn't (if the user ran out of money).
I assume that that shouldn't be a problem with your current implementation of the wallet like where you sort by "outgoing/incoming"
Awesome, thanks 👍
Gotcha, then maybe create content paywalls and paid subscriptions in the future?
That requires pursuing encryption methods ... would love to see someone pursue a way to integrate decentralized encryption on hive. Because those features you mentioned would be awesome
If you come along a Dev willing to take it on keep this in mind. Another profile feed could be used for all subscription based material. Like we now have a separate 'Blog' and 'All Posts' feeds, another for subscription content would be perfect. That way you can showcase the best of the best for easier discovery and evergreening. This would be the feed potential subs would want access to.
Of course, many other platforms which are open sourced have these features, like Minds.com and Flote. It might be easier to incorporate than you think.