Hi ! I've been quite busy in the last week polishing the recurrent transfer feature, he's a rundown of everything that happened:
- https://gitlab.syncad.com/hive/hive/-/merge_requests/150/diffs?commit_id=25a0f0cf5ef84df457c3cd56a91a181ddb80b1c0 I have added a counter to the recurrent transfers so that if you fail to pay a recurrent transfer 10 consecutive times, the recurrent transfer is deleted, this helps keeping the blockchain clean of recurrent transfers that were created once and keep failing weighting the chain down for nothing, I also added a virtual operation for failed recurrent transfers, that way you can view all successful and failed recurrent transfers. by looking at the account history
- https://gitlab.syncad.com/hive/hive/-/merge_requests/150/diffs?commit_id=d8e1d547e36f9f50f5efbb3595b544fdd4323786 : I have added an end date parameter and fixed some issues that @blocktrade's team mentioned in their initial review: the idea of the end date is so that people can set and forget without fearing that their recurrent transfer will empty their accounts if they forget about it.
- https://gitlab.syncad.com/hive/hive/-/merge_requests/150/diffs?commit_id=6dca066814ff9a888c3759b09374f88c77970083 / https://gitlab.syncad.com/hive/hive/-/merge_requests/150/diffs?commit_id=1cf1698f9c83d4215e39cb51784ef8094f712feb
/ https://gitlab.syncad.com/hive/hive/-/merge_requests/150/diffs?commit_id=0b4ee43c58612c0e96d29fbff3b21b1a09930d14 Then it was time for some proper unit testing. this is especially important to detect some bugs now and in the future, if the unit testing covers everything, if someone breaks the feature as a side effect in the future we'll know. It's also a great way to double check everything. And I found a few bugs while doing the unit tests that I fixed. - https://gitlab.syncad.com/hive/hive/-/merge_requests/150/diffs?commit_id=543349f520870425dfe6fa04659416a9211d8ebb Finally I added an api endpoint to see the recurrent transfers from an account to another called
find_recurrent_transfers, and added it to cli_wallet
Here's a sample output:
[{
"id": 0,
"trigger_date": "2020-12-08T02:16:51",
"from_id": 5,
"from": "initminer",
"to_id": 3,
"to": "hive.fund",
"amount": {
"amount": "50000",
"precision": 3,
"nai": "@@000000013"
},
"memo": "recurrent t",
"recurrence": 48,
"consecutive_failures": 0,
"end_date": "2021-05-05T05:08:33"
},{
"id": 1,
"trigger_date": "2020-12-08T02:16:54",
"from_id": 5,
"from": "initminer",
"to_id": 2,
"to": "steem.dao",
"amount": {
"amount": "50000",
"precision": 3,
"nai": "@@000000013"
},
"memo": "recurrent t",
"recurrence": 48,
"consecutive_failures": 0,
"end_date": "2021-05-05T05:08:33"
}
]
Next I plan on doing more of a research task figuring out if we can expand the rc plugin to charge RC as it goes, so that we charge RC for an user every time he triggers a recurrent payment. It's a better UX than making him pay upfront the whole cost of all his future recurrent transfers.
If you have questions on some implementation details feel free to ask them :)
Peakd is very excited about the work you are doing!!
You're also doing RC pool stuff as well? We are excited for that too.
The connection between subscription style automatic payments and the potential option of encrypted content is something we are particularly interested in has there been any more discussion about that? I would love to catch up on it
Thanks for always being there !
Yes ! Not actively working on it right now because I hit a wall and it's quite boring spending hours while making no visible progress so I figured I'd work on something else to get some "fresh air" until I go back to it But it's almost finished.
regarding encryption (pinging @theycallmedan so he gets a notification), we talked about it on the initial dev meeting about patreon use case: I think it's around 20-25 minutes
Tl;dr: it's very challenging to do it layer one, and I don't think all front ends are ment to have the patreon use case enabled anyways, so I think the patreon hive front end should do the encryption in a centralized manner:
The downside is if we have multiple front ends competing. Then you have to hop from one to another to see encrypted content. And then we can think of clever layer 2 solutions with a distributed database with the keys in it that's shared among patreon front ends so they all share the same keys.
But I don't think it's worth spending time on it until we actually see multiple front ends and that being a problem.
encrypted content? 👀
Congratulations @howo! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPTo support your work, I also upvoted your post!
Do not miss the last post from @hivebuzz:
Congratulations @howo! You received a personal badge!
It's great to see you are attending HiveFest⁵ in Altspace VR.
Have fun!
You can view your badges on your board and compare yourself to others in the Ranking
Do not miss the last post from @hivebuzz:
Ho Ho Ho! @howo, one of your Hive friends wishes you a Merry Christmas and asked me to give you a new badge!
HiveBuzz wish you a Merry Christmas!
May you have good health, abundance and everlasting joy in your life.
To find out who wanted you to receive this special gift, click here!
You can view your badges on your board and compare yourself to others in the Ranking
Do not miss the last post from @hivebuzz: