Hi everyone.
I've been a bit behind making those updates, I generally say what I'm doing in the dev meetings, but I figured I'd put it in written form as well.
Rc delegations
Rc delegations are almost done being adapted to hf24's codebase. I have hit a problem where I'm stuck due to the way hf24 treats some objects. But I think I'll get some help to be unblocked quite soon.
In any case it's not very urgent as hf25 is still quite far, so I can focus on other feature while this is waiting.
code and commits are there: https://gitlab.syncad.com/hive/hive/-/merge_requests/45
Recurrent transfers
I finished the first MVP version of recurrent transfers, it's a new operation that will be added to hard fork 25. It's an important building blocks to enable patreon-like uses case on hive.
I think hive is well suited to enable these kind of use cases leveraging our fast and feeless transactions. The issue is that right now in order to do it you'd have to give your active key to the dapp or have to come every month or so to authorize the transfer, none of those options are great in terms of security or user experience.
Enter the recurrent payment operation. Some of the details are still being ironed out but here's the gist of it:
You send a recurrent payment operation with who you want to send money to, how much and how often (minimum 24 hours). And then money will be sent from your account to the other account regularly until you cancel it.
So you can be like "I like this content creator, I'll give you 5 HBD every month".
The state of the implementation is where the feature works with bare minimum tests, it needs to be polished, @blocktrade's team did a code review already with some comments on various design choices. We are discussing some details.
If you want to see the code and said discussions:
https://gitlab.syncad.com/hive/hive/-/merge_requests/150
future work:
I plan on working on recurrent transfers for a bit, then I'll probably do some optimization work or work on the changes for hard fork 25 depending how we split the work with @blocktrades
If you have any questions, feel free to ask them :)
I like the idea of the recurrent payment option. it will allow some people to develop small business potential on Hive with out having to worry whether their dhf proposal will get funded. EA good example would be hiveworld or hivetask, (steemworld clones), to improve upon the basics and really make it their own version/tool. This could go well for the musicians also where they have their own home page and people can pay a fee in hive to view and listen to there music.
Thanks for all the work you are putting into the base layer to make Hive Block Chains stand above all the others.
These are two of my top features I'm excited about for hf25
The shortest interval is 24hrs whats the longest interval going to be?
Also its not a HF25 thing but who will be handling language tag in hivemind? I'm guessing we are waiting until hivemind gets some more work done in it first.
Thanks !
Longest interval is 65535 hours or 2730 days.
Unclear yet who will work on it yet, I'm waiting for everything to be more stable hivemind-side before starting to add new features, right now it's still in active develoment
Why not add a parameter for the number of occurrences? This would allow us to have a "set it and forget" option.
Yeah I think I'll add an end date parameter.
Thanks for the work you are doing @howo!
I would like to see what are the potential topics you and @blocktrades team are focusing for HF25.
I am really excited for the next Hard Fork!
He will be releasing a roadmap for hf25 shortly :)
Cool!
Recurrent transfersare a very good idea and the right gift to give to Hive to take a step in the right direction. This opens up a wide range of possibilities and is a major asset for the onboarding 👍Thanks for your great contribution to Hive
@mintrawa: Witness FR - Gen X - Geek 🤓 Gamer 🎮 traveler ⛩️
Don't miss the Hive Power UP Day! more info here
Merci ! :)
I have some questions:
What will happen if the Hivian doesn't have enough HIVE on the due date? (does it cancel the Recurrent payment operation or postpone it?)
What will happen if the Hivian doesn't have enough RC on the due date to create the transfer operation? (does it cancel the Recurrent payment operation or postpone it?)
There will be an API to query the status of a specific Recurrent payment operation?
There will be a specific memo in the transaction of Recurrent payment operation?
There will be an optional option to set an end date?
That's it (for now 🤣)
@mintrawa: Witness FR - Gen X - Geek 🤓 Gamer 🎮 traveler ⛩️
Don't miss the Hive Power UP Day! more info here
It will be noted as "failed" for that iteration and the next payment try will be at the next recurrence, so if it's a monthly payment and it fails for that month, the next payment tentative will be the next month.
I have coded a system to delete the recurrent transfer operation after x failed tentatives in a row but I don't know yet if it will make the final cut.
So far we charge all the RC upfront, so rc at the time of the transfer is not an issue. But it's not ideal to charge a lot of RC at once. So I'm looking at the feasibility to charge RC as it goes.
If the user doesn't have enough RC the operation will just not be executed I think.
Everything will be displayed as virtual operation (similar to what you see for witness pay), there will be filled_recurrent_transfer for a successful transfer and failed_recurrent_transfer for failures
So technically the api already exists in the form of get_account_history. But I'm thinking of adding something to hivemind to make it easier for dapps to work with it.
You can set a memo when creating the recurrent transfer and it will be sent every time :)
It's not in the current implementation, but I think I'll add it in the coming week.
Thanks for the explanations 👍
It depends on the RC required but if it is high, you're right, taking the whole on the original operation may not be the best option.
Glad to hear it for the memo and consider adding an optional option to set an end date 👍
@mintrawa: Witness FR - Gen X - Geek 🤓 Gamer 🎮 traveler ⛩️
Don't miss the Hive Power UP Day! more info here
Recurrent transfers are a really good feature to have, nice.
And I want to see what RC delegations look like.
That post explains most of the info: https://peakd.com/rc/@howo/rc-delegations-current-development-status-and-request-for-feedback
Thanks sounds good. One thing I can't understand yet is how HP delegations affect RCs. When delegating HP do RCs go with them? Are RCs tied to HP, as in for each hive powered up is allocated a unit of RC?
Nice, the recurring payments thing would be great for @vimm to provide channel subs or something similar.
When smteees!!™?
When we figure out if we put them as layer 1 or layer 2
Why not both :)
Kind of a waste of time tbh :p
hahha yeah. But it also can be useful.
Some people will want smart contracts and upgradeability at the expense of security(layer 2), while others will just want a community token only used for PoB, transfers and balances with maximum security (layer 1).
The code for layer 1 is already done by the ex-steemit team, and I remember you had a lot of experience testing it and understanding it. Would be kind of a waste to let it all go away.
Does putting them layer one slow the chain?
It will slow/bloat the chain and add a loooot of complexity. But there are advantages too to be layer one like being integrated with everything else that's layer 1, and no need to build a secure layer 2 system.
So, making smt's negates all that aggie is doing?
Layer 2.
Keep layer 1 nice and efficient, then hopefully we see the tools getting build for use non devs to build out more communities to grow the user base and add more value back to the chain.
I'll say so far we are leaning towards layer 2 but very slightly leaning nothing is set in stone and we very well could enable layer one.
I would just be happy to see a proper roadmap after 3 years. One with some certainty of how it is going to happen and an end date for us to look forward to.
I know there will be a lot of work to get it all put together so it will be great when we can see it being put together.
Hopefully you can all get it worked out fairly soon and give us all a boost.