Hived updates (core blockchain code)
We had to make changes to some of the virtual operations that were added to allow voting and payout information to be moved to hivemind. These problems were all identified by hivemind’s automated testing system:
https://gitlab.syncad.com/hive/hive/-/merge_requests/85
https://gitlab.syncad.com/hive/hive/-/merge_requests/86
https://gitlab.syncad.com/hive/hive/-/merge_requests/88
https://gitlab.syncad.com/hive/hive/-/merge_requests/90
We also added some new tests for hived and made some improvements to the automated testing system itself. Notable additions to the testing system include replay tests and tests for saving/restoring state information (new feature added in Eclipse release).
https://gitlab.syncad.com/hive/hive/-/merge_requests/87
https://gitlab.syncad.com/hive/hive/-/merge_requests/89
Hivemind work (2nd layer social media microservice)
We made a few more small improvements to the hivemind’s automated testing system, but most of the time was spent fixing hivemind bugs that were identified by the testing system. Most of these bugs were due to the movement of data from hived to hivemind (to reduce memory usage), and several fixes also required changes to hived as well, as previously mentioned.
Improve automated testing for hivemind:
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/38
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/46
Hivemind bug fixes for bugs found by API tests
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/39
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/40
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/41
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/42
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/43
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/44
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/45
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/48
General code improvement
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/47
Condenser changes (hive.blog’s code)
We added support for Dapplr videos. As part of this work we reviewed security associated with iframe usage in condenser. Iframes allow content from other sites such as youtube, threespeak, dapplr, etc to be displayed inside of posts.
https://gitlab.syncad.com/hive/condenser/-/merge_requests/81
@roomservice and https://gitlab.syncad.com/jsalyers fixed a bug changing profile settings (this problem has been around for quite a while and several people have reported it, so it’s nice to see it fixed):
https://gitlab.syncad.com/hive/condenser/-/merge_requests/79
@quochuy fixed a bug where paging down didn’t always load the next set of posts:
https://gitlab.syncad.com/hive/condenser/-/merge_requests/77
Decentralized list progress
We’re still doing user-interface work for decentralizing lists; the latest change is to allow a user to add a “description” to his lists, so that other users can see the criteria used to make each list. These descriptions will be shown to new users when they first pick lists to follow and they will also be shown on the pages where the user has followed other people’s lists. This change also requires an update to hivemind to store these descriptions.
BlockTrades devs currently working full-time on hived and hivemind
In my last post, someone asked how to follow the work of individual programmers. Most of our devs don’t post on-chain, but if you’re interested in getting a snapshot view of what individual programmers are working on, you can use the links below:
https://gitlab.syncad.com/jsalyers
https://gitlab.syncad.com/ABW
https://gitlab.syncad.com/bwrona
https://gitlab.syncad.com/Trela
https://gitlab.syncad.com/kmochocki
https://gitlab.syncad.com/dkedzierski
https://gitlab.syncad.com/dan
https://gitlab.syncad.com/Ickiewicz (new dev)
https://gitlab.syncad.com/klesniak (new dev)
In addition to the devs above, we have several other devs contributing on a part-time basis to various projects such as condenser and hived, plus some full-time and part-time devops guys working on various Hive-related tasks (server setup and maintenance, manual testing, performance testing, etc).
Plans for upcoming week
We’re planning to replace the pyresttest testing framework used by hivemind’s automated testing system with the https://github.com/taverntesting/tavern framework. Pyresttest is no longer actively developed, and tavern also provides better reporting and better integration with gitlab’s automated testing environment. Tavern will also allow us to mark individual tests within a testing job as “allowed to fail” so that the overall test job doesn’t report as a failure, which can be very useful when making changes that are expected to temporarily break some tests.
Unfortunately, we weren’t able to complete enough testing this week that we were comfortable to make a release candidate for hived, mainly because we keep finding hivemind-related bugs that required us to make changes in the virtual operations needed by hivemind.
But at this point we have enough tests passing that I think we’ll be able to provide a hived release candidate early next week. That means we are a little over 1 week behind compared to our original, optimistic schedule for HF24.
Plus all the community devs.
If you are wondering why we are iterating so much faster than steemit inc could that's the reason, they pretty much had 2 core devs, 1 front end guy (working on steemit.com) and one devops guy. If you need a reason to buy hive there you have it. We probably pour almost three times as much man hours into the project as they did.
We'll soon be done with eclipse, and in only three months we shipped a ton of stuff. Now imagine what we'll achieve in a year.
Thats good to know
Tests, tests, tests.
Tests!
Better safe than sorry.
One thing worth mentioning is that all the work that is done now (automated testing system) will save us A LOT of time in the future.
Cool! 😃
I’m intrigued by voting & payout info moving to the Hivemind layer. I know it can be a contentious issue... but if the processing burdens are eased enough could this eliminate the 7 day window and facilitate “evergreen” content? I was always under the impression that aspect was tailored to fit what was technologically possible, and wasn’t a core tenet of the system itself. Is it becoming possible to scale past that limitation?
The current changes only impact storage of non-active voting and payout info (old votes and payout information is no longer retained in hived after a post has paid out).
The actual calculation of payouts still needs to be done in the 1st layer code (the blockchain code itself), as you believed previously. The only way to move this calculation out of hived would be to pay the rewards in something other than HIVE/HBD.
As to the reasoning for the 7 day window, we haven't looked into why it was set to one week, although I was under the impression (seemingly like you) that it was to prevent too much load on hived (the core blockchain process).
Isn't the reason for the seven day window also to prevent delegating one's HP to several different accounts to be able to self-upvote own posts several times?
By the way, I think we should reconsider the five minutes curation window (directly after a post was written), because it clearly disadvantages manual curators who try to read and evaluate posts before they decide to upvote them or not. Until they have done that always lots of automatic upvotes have already come in. Also it makes 'curators' lazy (especially since there is 50 % curation reward): they simply upvote the same people again and again, while not enough users are seeking for new authors (respectively honor posts from old authors who aren't on their 'lists').
I see no reason to be rewarded less for a late manual upvote than for an early automated upvote.
Considering the high percentage of automated upvotes, I think it's simply a myth that manual curators find 'quality content' early, and then more upvotes follow and reward them.
I wrote two posts about that problem:
Here and here.
I don't think so, as the 7 day post reward window existed before delegation. But I think the delegation "return delay" is based off the 7 day post reward window, to prevent abuse of the type you mention. So it would likely need adjustment if the duration of the post reward window changed.
I agree that the current curation reward system is still not tuned very well. As you've mentioned, it has become obvious that the super-linear reward for early voters hasn't done one of the jobs it was designed for: to reward manual curators versus bots. But it was also designed to discourage "pile-on" voting where everyone just votes on the same trending posts, because later votes give less curation rewards. Again, it's possible it's not really doing this either, hard to say for sure.
But proper tuning is actually quite difficult, IMO, because the intersection of economics and human behavior is often more complicated than people expect. It may turn out that the only way to find something that works well is to keep making adjustments.
Cap all rewards at $20 hive.
That way, when a post maxes out, curators and bots will have to go searching for new authors.
The bots will just keep voting on the same maxed out posts which will give a distinct advantage to the humans!
I think that limit would be way too low to differentiate between 'great' and 'not so great' posts.
I'm not convinced that total payout is the most reliable indicator of a "great post".
The burnposts make tons of money for curators and ste.emcleeners (not exactly content that would appeal to the public at large) was the most consistent top earner.
What about a cap of $50 ?
The overwhelming majority of the posts I make and vote on make less than $0.25
Big payouts don't seem to attract readers or commentators, but they do seem to attract autovoters like flies.
Of course you are right! How time sometimes can blur the memory ... It's much more logical that the delegation "return delay" has been adapted to the post rewards window than reversed. :)
I wonder if curation rewards should solely depend on the weight of the upvote? So that neither the date of the upvote nor the number and strength of upvotes of other users would influence the curation rewards of a curator (but only his HP and the percentage of the upvote).
I know that would make self-votes on comments etc. more interesting again, however, at least for the author it would still be more beneficial to get more upvotes than only his own self-vote.
So as curve for the author rewards we could stick with convergent linear, but for curation rewards the simple formula that curation rewards would only depend on the vote weight of the curator could apply?
I know the matter is complicated and maybe my ideas have more weak points than I am aware at a first glance ...
Someone actually suggested your curation reward idea recently. It may be better than what we have now, but one potential problem is it might lead to more self voting. That could potentially be countered by downvoting, but so far all signs point that downvoting just doesn't happen much, no matter how the rules are changed.
Interesting (and good) to know that this idea is actually being discussed, and that some stakeholders are aware of the suboptimal curation situation (which can be quite frustrating for users who try to curate manually)!
Concerning my idea, right, the self-votes are a problem, the flags part of a possible solution.
Actually, I would modify my idea above in a way that reduced the benefits of self-voting:
I know that the probability to see this last step is rather low ...
Some time ago I had the idea of 'diminishing returns' (against self- and circle-voting) when upvoting the same accounts again and again (within a short timeframe), but it seems that can be circumvented by creating many alt accounts (even if it still should be suspicious and detectable if a certain group of accounts only upvotes each other).
... I will keep thinking about possible other solutions ...
I don't understand why "self-voting" is considered a crime.
And if it's so horrifying, can't you just restrict it in code?
Cap all rewards at $20 hive.
That way, when a post maxes out, curators and bots will have to go searching for new authors.
The bots will just keep voting on the same maxed out posts which will give a distinct advantage to the humans!
Where the heck is this post ($40.55)? - https://hive.blog/hive-122315/@logiczombie/trust-cdc-gov
IMAGE SOURCE - https://hive.blog/payout
@jaki01 who do you think I should ask about this?
Do you still have the url of this post?
Then maybe you find it in hiveblocks?
Here's the url - https://hive.blog/hive-122315/@logiczombie/trust-cdc-gov
I'm just wondering what I'm missing, I've been lucky, the last few posts I've made received over $30.00 Hive and none of them showed up on the https://hive.blog/payout listing.
So the problem is only that it wasn't in the payout list? I wouldn't bother too much ... you got the money anyway. :)
However, if you want to open an issue you can do it there: https://gitlab.syncad.com/hive/condenser/-/issues
But maybe I didn't get what the problem is and you meant anything else?
Postpone as long as you need to... This release will be laying the groundwork for a glorious future.
People need to understand that fixing and changing thousunds of lines of code will break some other code. So test, test, test. I am already feeling the hype just because of the months of work you guys are putting into this.
I'm truly excited how fast Hive is developing and evolving, HF24 is bringing forth some major and much needed enhancements to the back end code that runs the blockchain - and I am sure everyone respects the fact you and your team are not rushing this out - it will arrive when it is ready and perfect, and everyone will love it.
A huge hug 🤗 and a little bit of !BEER 🍻 from @amico!
Un caro abbraccio 🤗 e un po' di BEER 🍻 da @amico!
Very very impotant this post. Thanks for share!
Very important all these changes that are made on the platform for the good and future of all who make life in hive. Thanks for the information, but for the moment we have to wait
@blocktrades
Very important everything you're doing on this platform. Good job! Greetings
Congratulations @blocktrades! 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 to others on 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:
If anything, I am enjoying seeing regular updates about improving the efficiency of the Hive Blockchain regardless of the delays.
A strong foundation will see Hive grow into a stable blockchain in the years to come.
I am really looking forward to what is in store.
Posted using Dapplr
Thanks for your work. I wish you success.
Weekly update is really positive to know what is going on.
Great effort and endeavor for everyone involved.
Thank you very much for you work!
gracias por su apoyo amigos @blocktrades de igualmente sigan trabajando en la mejora de de todo y para todos, gracias
Thanks for sharing this information .
:)
Love to get this kind of feedback to see what is going on.
A !BEER for the team.
You provide very clear update on Hive development. That's I missed at Steemit...
Correcting failures to prevent in the future, good information
Quite good progress and I can barely wait until HARDFORK 24 is release. It will be the first true community release and will bring improvements at network level which should benefit us all.
Keep on the right path and you will be rewarded, don't stop build great things!!!
Thanks 😊