The BlockTrades team is planning a lot of future work to the Hive ecosystem. This posts details some of the changes we’re planning so far.
I want to apologize in advance, as this is still a somewhat raw dump of my thoughts about sometimes complicated issues. This means that some of the topics are written for everyone, but other topics contain fairly technical details that will likely be difficult to grasp at first reading (and maybe subsequent ones). As we get closer to implementation of some of these ideas, I’ll try to elaborate more on individual ideas from this post in later posts (if someone else hasn’t taken on that challenge in the meantime).
I’m dividing these changes up into several categories, because they impact different systems and therefore have different scheduling needs.
Blockchain-consensus changes (hardfork changes)
These are changes to Hive’s governance model, so they require a hardfork and approval by the top 20 witnesses.
Hardfork changes require all nodes to update to continue operating on the Hive network, which is a bit of a pain to coordinate, so Hive devs try to avoid requiring too many hardforks (usually by scheduling several hardfork changes at once).
The current plan is to schedule hardfork 25 for around 6 months from now (mainly to avoid requiring exchanges from having too upgrade too soon after the last hardfork). The protocol changes planned for hardfork 25 are expected to be rather easy changes and will likely be coded much sooner than 6 months from now.
The changes planned for the hardfork are NOT required in order to execute on our other planned changes to the Hive ecosystem: this means we can make many important and useful changes to Hive before the next hardfork.
What about HMTs (user-defined tokens)?
The only potential change we might conceivably make to the blockchain rules in hardfork 25 that wouldn’t necessarily be easy would be enabling HMTs (mainly because the HMT code hasn’t been tested well yet and would likely need improvements prior to release).
At this point, we haven’t made any decision about whether or not to enable HMTs, because we think there’s a reasonable chance that we can do something more useful in the way of tokenization at the 2nd layer. In short, the topic needs more research, and will be discussed in depth in a later post, after we’ve fully explored the options.
My personal preference at the moment is to implement user-defined tokens at the 2nd layer using a smart contract evaluation system, which will allow for much more flexibility than is possible with HMTs. But to make this feasible, we have to define a robust model for decentralized 2nd layer apps (to be discussed more in later sections of this post).
It’s also worth noting that these don’t have to be exclusive options: it’s possible to implement HMTs at the first layer and smart contract-based tokens at the 2nd layer. But this could be more confusing for Hive users and may offer no real benefit.
Governance changes planned for hardfork 25
Vote expiration for witnesses, proxies, and proposals
Currently governance votes don’t expire, which can lead to votes that never change, either due to inattention of the voter or in worse cases, because the owner loses their keys or passes away (yes, on Hive, dead people really can still be voting). This can lead to non-optimal voting, since the stake isn’t properly monitoring the people and proposals being voted for.
To address this issue, we’ll set governance votes to automatically expire one year after the last governance action by an account. This will be implemented by storing a “last governance action time” for each Hive account (this information will be part of an account’s profile information).
Whenever a user sets a voting proxy, or vote/unvotes a witness or a proposal, this last governance action time will be updated to the current time. If a year passes without a governance action by the account, the account’s votes for witnesses and proposals will be canceled, and any proxying of the account will be reset.
User interfaces like Hive wallets and browsers will be updated to report a warning when an account’s votes are getting near to expiration. Such warnings should prevent any active user from forgetting to take a governance action that keeps their votes from expiring.
Just to be clear about how this works in practice: your votes will only expire if you don’t take any governance action for an entire year. So this change should only impact people who are no longer “paying attention” to what’s going on (or who have lost control of their keys).
Change 5min vote window to longer window and provide proportional rewards during the window
Currently, voting earlier than 5 minutes after a post is published results in less curation rewards for the voter. This led to the rise of auto-vote bots that vote at or near the end of this 5 minute window, severely disadvantaging manual voters.
With this change, there will no longer be a penalty for early voting of a post/comment. Furthermore, there will be no advantage to voting earlier than anyone else who votes within the new longer time period.
There will still be an advantage for voters who vote within the time window, but the idea is that the new window time should be long enough for manual curators to find good content, putting them on equal footing with the vote bots.
How long should the new window be? I’d argue for somewhere between 2 hours and 24 hours at most. I generally favor it being closer to 2 hours, to allow for some friendly competition between manual voters, and to encourage somewhat rapid curation that brings good content to the trending page quicker.
This change isn’t expected to eliminate auto-vote bots, but it should remove the financial incentive to use an auto-vote bot instead of voting manually.
This change will still lead to an incentive to select “popular” content, since voters during the first 2 hours will gain somewhat more rewards than later voters on a post.
The above means that “Smart” auto-vote bots will likely begin trailing successful manual curators by voting near the end of the 2 hour period in an attempt to maximize their rewards. On the whole, this incentive seems beneficial, since it should lead to good manual curation being the guiding force for how the bots vote as well.
Non-consensus changes to hived blockchain software
These are changes that can be made without a hardfork, and often don’t require everyone to upgrade their node. Changes of this type include: 1) speed and memory optimizations, 2) minor bug fixes, 3) addition and changes to API functionality. They are also usually not very controversial, because they don’t affect governance.
Because non-consensus changes usually don’t require everyone to upgrade their node, these changes can be released whenever they are ready, instead of being scheduled as part of a big planned release. As a simple example, we’ve had 7 such non-consensus releases since HF 24 (we’re at hived v1.24.7 right now).
Most of these changes only impacted API node operators, so normal witnesses and exchanges didn’t need to upgrade their nodes (most hived nodes are still running v1.24.2).
There’s several areas we can explore making non-consensus improvements to the blockchain:
- further reductions to memory usage
- improvements to peer-to-peer networking layer
- improvements to API services
- a hived plugin to provide real-time data to 2nd layer apps
Of the above areas, I believe 4) is the most critical change. Currently it takes over 4 days to sync all the existing blockchain data to a new hivemind instance. We should be able to significantly reduce this time by creating a custom plugin that can fill a hivemind database (we’ve made measurements that show that hivemind database filling time is the main bottleneck in hivemind full sync timing on a system with fast IO, because of cpu bottlenecking on the hived side).
Another issue is that the current hivemind “live sync” process intentionally lags 2 blocks behind the head block, because hivemind isn’t able to handle micro-forking by hived. The creation of a plugin that directly writes to hivemind’s database will allow for faster data filling and also allow hived to manage the required changes to hivemind’s database in the case of microforks. This, in turn, means that hivemind will be able to operate with the most recent block data, eliminating the 6 second lag (2 blocks behind the head block at 3s block intervals = 6s) that it currently has. This is very important for an interactive experience by Hive users on the various Hive frontends.
Development of 2nd layer ecosystem
This is one of the areas where I expect we’ll be devoting the most time in the next few months. The most important thing I want to do is to create an easy framework for the creation of new Hive apps.
Right now, apps usually rely on API nodes to supply a lot of their blockchain information via API calls (with the data coming from a hived blockchain node and the hivemind social media microservice). Some apps also directly process custom_json operations to implement functionality that is generally unique to their application. This approach “works”, but it could definitely be improved.
Implementation challenges for 2nd layer apps
One issue is that apps either need to run their own heavy weight API node or rely on the API nodes provided by others. Ideally, it should be possible for an app to run a lightweight node that provides all the data needed by the app, avoiding reliance on uptime and data integrity of external API nodes.
Another issue is the processing of custom_json streams (and other operations) in the face of forks, where operations in blocks that have already been processed have to be discarded in favor of new data. This is one of the most potentially problematic issues for any blockchain-based app.
A lightweight framework for 2nd layer apps (via “modular hivemind” nodes)
To address, the above issues, we plan to create a lightweight framework using much of the technology stack of hivemind, combined with the new hived plugin we’re developing that will simplify real-time reception and processing of blockchain data and support easy fork-handling via a generic undo mechanism.
However, unlike in a traditional hivemind installation, the operator of a 2nd layer node of this type will get to decide what data he wants to store and what APIs he wants to support. For example, a 2nd layer node that supports a game might initially only track account balances and game history, but no social media data. But if the node operator later wants to add more data and API support to their 2nd layer node, we want to make it easy to add it via some form of upgrade mechanism. I believe it was @howo that coined the term “modular hivemind” to refer to this idea.
Consistency checking to decentralize trust in blockchain ecosystems
Note: this is one of those topics that I mentioned at the outset of this post that might not be trivial to understand unless you’re a programmer (and maybe not even then).
Another important capability that would be very useful for 2nd layer apps is a way of automating the checking of data consistency between multiple API servers. A system of this sort would go a long way towards reducing the need to trust any particular node that supports a 2nd layer app (i.e. decentralizing trust).
One way to do this would be for decentralized 2nd layer apps to periodically (for example, once every 1000 blocks) generate a hash of their state (or some portion thereof) and publish it as a blockchain transaction. 2nd layer apps that generate the same hash are making a statement that they interpret the blockchain data in the same way (i.e. they are operating under the same protocol rules).
In such a system, 2nd layer apps can decide to operate by different rules (a protocol fork), while continuing to coexist on the same blockchain network. But by publishing hashes of their state, users will know which nodes have decided to operate under a common set of rules, and they can therefore make an informed choice about which nodes they want to rely on for data. Of course, a user can always decide to simply run their own node, which is something we want to make it much cheaper and easier to do. But even in this case, it’s very valuable information to know who is supporting a particular protocol, as the amount of consensus among protocol users is a major determinant of the value of that protocol.
Increase development pace of open-source user interfaces for Hive (e.g hive.blog , ecency.com, etc)
For the past few months, I’ve focused on adding more user interface programmers to our team to support increased development of open-sourced Hive-based front ends. Naturally BlockTrades already employed a number of front-end programmers, but they were all tied up on other projects, and couldn’t be moved without serious impacts on the scheduling of those projects.
There’s little point in going into specifics at this moment as to the exact changes we’ll be making on Hive front ends, as often these changes are quite small, can be done at any time, and are generally driven by user demand. But I felt it’s important to say we recognize the importance of how user interfaces impact enjoyment of Hive in all it’s facets (as a currency, as a platform of blockchain based apps, and as a social media backbone) and that we will be increasing our efforts in this area.
A new decentralized reputation/rating system using web-of-trust concepts
This last topic is the one that I’m most interested in, and I’ll have much more to say about it later, but it’s a huge topic and deserves many posts of its own to divide it up into digestible bites.
The basic idea for this system is you assign judgment skill ratings to people you know in various disciplines and you also publish your own ratings on products/people/ideas. Based on who you trust and how much you trust them in different areas of judgment, this system will compute rating scores using your web of trust network on potentially any subject where people form opinions.
I almost didn’t mention it in this post, but since this is something like a roadmap of planned Hive-related work for BlockTrades and this will function as a 2nd layer Hive app, I figured I should at least give it a brief mention now, as I plan to start this effort in the next 6 months. I say “start” because the reputation/rating system is planned to be a long-term project that will grow over many years and expand to address many different areas. Initially, of course, we’ll need to focus on creating a prototype that covers a relative small subset of things that can be rated and a few mechanisms for computing ratings and analyzing how ratings change as a user makes changes to his trust network.
Final note
Also note that this is just a roadmap of things BlockTrades is currently planning to work on. For example, @howo is working on support for recurrent payments currently, to allow for Patreon-style payment models.
Vote decay has been brought up a lot, and I am generally not a fan of it as I don't want to turn Hive into an endless campaigning and vote begging.
I really love this approach, this solves the problem people are most concerned with, people voting and then going afk or dying, but it also prevents endless campaigning and vote begging.
I'm all for this!
Curation is a mess right now, but this is mostly human behavior lack of protocols to solve the unfair advantage automated voting has. I don't agree with crippling automated voting though, not everyone can spend all day voting content. I believe this is a good compromise to remove a lot of the disadvantage manual voting has.
I'm really excited for anything that can improve the performance of Hivemind as we have now become far more dependent on it's performance and scalability.
I really would love to see a first layer token system (SMT or whatever) that supports the core functionality needed (which is very simple) and leave the rest to second layer. Although 1 second block time of a side chain is super attractive to gaming as even 3 seconds feels slow to interactive gaming.
My concern with a side chain, and why I have issues with Hive Engine is I want to see token transactions consensus so you can trust them, anyone can create a custom json saying they just transferred 1000 LEO tokens, no one but Hive Engine has access to the real database behind Hive Engine, so you have to then query their API nodes to verify this is a legitimate transaction. Custom JSON for this type of transaction is really hacky, and I would love to see something better.
That being said, I am a huge fan of getting smart contracts on Hive as soon as possible. Being able to offer free transactions with smart contracts would be a game changer and if we can just sign up one Gods Unchained like project, we could see amazing growth overnight.
We really need a USP (Unique Selling Proposition) that makes Hive a no brainer choice, adjusting curation and witness voting while critical won't do it. Smart contracts w/ free fast transactions could be a winning combination that puts us on the map.
DeFi has proven to be a huge success, with decentralized exchanges outperforming centralized exchanges in terms of liquidity and volume. We have been sitting on the SMTs (HMTs) for 4 years and it is time for us to join the proven trend.
Level 1 implementation offers much better protection and transparency for liquidity providers.
말 좀 들어 처먹어랏~! 다운보팅 고마해 확 쉐려뿐진닷~! 걍 뒈져~! 꺼져~! 빡큐~!
수사적인 질문과 농담을 넘으면 무엇을 얻습니까?
Sooo much great information and great conversation happening here.
I have wondered about API Nodes and our trust in them and their potential to maliciously (or maybe mistakenly) deliver "bad information" ... and at the same time supporting the ability for there to be decentralization of options for nodes which in my mind would lead to less site wide problems if all nodes use the same system and then all have the same bug. But also if all nodes are copies and they all decide to do something detrimental to a party, like perhaps censor (and even if the censoring is warranted to protect against attacks for example) there is little recourse to potential abuse of power when there aren't options. It does seem like right now if you made a change to hivemind almost everyone is just going to accept it and you(or anyone working on hivemind release) could (and thankfully don't) do some pretty detrimental things.
I'm still wrapping my head around this but seems like at least recognizing how nodes operate and which ones are processing things similarly is helpful. But I also hope at the same time there are incentives for people to have a different way to getting to the same point.
(If i'm mistaken on how i interpretted any of this would love someone to help out.)
There were some things I'm excited about not mentioned and I assume that's because someone like @howo is taking lead. You mentioned the reoccurring payments/transfers. But also RC delegation pools? ... In any case if anyone else does a post like you have done I hope it gets this sort of attention and discussion as well.
So a proposed blocktrades style decentralized-reputation-system could almost be considered a sort of 3rd party dApp?... something that we could integrate onto sites? Is that the right way of looking at it? Would you look at putting it into Hive Centric databases like Hivemind or HiveD? Or would it be something altogether different?
I have wondered if having multiple reputation systems as options would be a benefit or a distraction? Not sure really... but it does go in line with the idea of decentralization to a degree.
As for a system for tokens it's hard to recognize the pros and cons for the different potential solutions but I do trust others way more than me so i'll just try to read the discussions about the directions for this. But I as an observer seeing what developers have done on ethereum with their expensive slow system the contract idea does seem pretty appealing. Right now we have a decent number of games using jsons and then using a centralized API that you really have to trust so that's also on the list... so i guess i'm just putting a DITTO here to how your efforts would help a ton with these areas.
I am onboard with everything in this post. I like the idea of the sidechain as you described, seems very elegant. If asked if I rather have layer 1 vs layer 2 HMTs, I'll quote my mom: "I don't care how the sausage is made"
My biggest wish list item for Hive, has been for a while, is a decentralized way to create tokens on Hive. First layer or second layer dosent matter to me as long as I know my token balance is protected by decentralized, censorship-resistant technology.
I agree, Hive users definitely want/need a user-created tokens and it's definitely part of our roadmap, in one form or another.
👍 yes, please... I feel that's going to allow a huge onboarding because most of the serious investment comes from businesses trying to use new technologies to solve their problems. Programatically is a must for blockchain interoperability, both internally here... and when interfacing with other blockchains.
Basically, everyone could use HIVE to start their business, security and decentralized enough to put some respectfully business infrastructure on it.
This!
Still wish someone could figure out a way for the lower power down time. See it as a wealth hazard. If the price of hive was constant, then it probably wouldn't matter to me how long power up time was.
Lowering the power down time is honestly a trivial codebase change.. But would have to be something the top 20 witnesses have to sign up on.. In part I believe the power down time is so long in order to mitigate the potential for bad actors to buy up HIVE, do disruptive things and then be able to quickly power down essentially costing them little to nothing in terms of cost of attack or time.
It's a deterrent.. However it acts both ways as well as you've mentioned above.
thanks klye.
No worries captain!
Your balance is below 0.3 HIVE. Your account is running low and should be replenished. Check out the Dustsweeper FAQ here: https://hive.blog/dustsweeper/@dustsweeper/dustsweeper-s-faq
Sounds like a dream that finally comes true.
Literally will be to me too.
About decay vote. I think proxy votes should expire. Because if some people want only to use hive for games/content, they can proxy their vote.
I think there don't vote again if it expires. If they proxy their vote to someone they trust, it should be perfectly fine.
Only the voter should expire if he is inactive. Like 6 months no witness or DAO votes/changes = expire.
That should be work because then the inactive people cant block anything.
And as an alternative, if they want to be inactive, they can proxy. So it's more political like they vote for a middleman that is looking for their interests.
It can also be work that way, that many holders combine their vote, to get more attention for changes/ ideas.
Edit: Btw I love the roadmap. That is what I was looking for for a long time.
Also if at some point a front end should be as easy as a WordPress installation, nobody can stop hive ( I know that would be way more work :)).
Not loosing time on
HMTand relay it to 2nd layer is the best option 😉 There are some talented devs on the second layer like @harpagon (which, after having created the Smart Contract System, has just created the SmartScript virtual machine) for example to realize it.A one-year delay is not bad, even if it won't be easy to convince voters to renew their vote for low ranking witnesses like me, it will clean up the system of governance by removing the accounts of dead voters and may give more trust in the governance of Hive and more involvement of the Hivian.
Interesting vision of what the second layer should look like! Your vision will also give more flexibility, easy way to query
custom_json?Concerning the reputation/rating system do you mean like the skills people give you on linkedIn?
The
recurrent paymentsof @howo can be a game changer to attract more creators (that make Hive live by feeding it with their content) who are looking for ROI with a subscription system like Twitch or who don't want to depend on a third party like Patreon-style system. It can also have a positive impact on the content quality 😉 So I really hope to see it in HF25 👍@mintrawa: Witness FR - Gen X - Geek 🤓 Gamer 🎮 traveler ⛩️
Don't miss the Hive Power UP Day! more info here
It's not terribly difficult currently to query then read a custom_json operation within a hive block.. :P
If you need a hand with this sort of thing I can gladly walk you through it. :)
Hi @klye, thanks for your comment.
You can query
custom_jsonon key/value? If yes, it's limited only to theidkey? I tried to search in the API definitions on the Hive Dev portal but I couldn't find 😢@mintrawa: Witness FR - Gen X - Geek 🤓 Gamer 🎮 traveler ⛩️
Don't miss the Hive Power UP Day! more info here
Don't miss the #HiveFEST 2020! more info here
Not natively however it's not super difficult to write a bit of javascript to do this for you if you know what block the custom_json operation resides in.
If you need a code example I can likely hook you up.
@blocktrades Nowadays everybody is talking about the LeoFinance success. As you well know, they've achieved it in the following way: 1. Maintaining an open and easy to understande comunication with the userbase; 2. Full Power Down in four weeks; 3. Building bridges with other crypto and non crypto platforms; 4 Implementing a flat curation curve; and 5. Eliminating the dust. I understand and agree that the main focus of Hive needs to be on updating old data and creating tools for the setting up of new dApps. However, would it be possible to gather a small group of witnesses/developers to inspire confidence and promote growth in the platform as on LeoFinance? They would just have to copy the LeoFinance model. If with a 550 userbase LeoFinance have gone so far, what would be possible for Hive with a 10.000 userbase?
I welcome several proposed changes; namely the expired/decay of witness voting; 5-min window; and thoughts on the 2nd layer systems are most welcome.
We also need to think about proper digital marketing. I know we discussed this multiple times before; but now I think there is at least some positive forces in motion. I hope we can see some concrete action on that soon, perhaps even before the fest.
I also hope to see more digitial marketing/advertising take place, and while I don't plan to lead any such effort, I'm happy to vote for reasonable proposals on the subject.
yeah, lordbutterfly recently talked to me, he said he discussed some with you, and I also asked him to reach out to crimsonclad for advice. If a resonable proposal comes in, I think we have our ducks in a row.
Is getting rid of the voting window all together and moving back to linear an option?
I think we need to clarify on terminology first. We've never been time-linear in terms of rewards. Early voters always got more curation rewards than later voters. The planned change will make that not true during the window. I think some form of window here is valuable, because it makes some sense to reward early curators for doing the work of discovering content for the later votes.
However, you may be referring to a truly linear reward curve proportional to the amount of stake voted vs the change done by Vandeberg that nerfs the rewards for very small votes, making a quasi-linear curve. I've never investigated that issue much and therefore don't have much of an opinion on it , but I know it's been unpopular with some people. I'm not opposed to having a discussion about it (or maybe just a pointer to past posts on the subject), if this is the reversion you're suggesting. I suspect such a reversion wouldn't be difficult, so it's probably mostly a matter of weighing the pros and cons.
I am for a 2-24 hour window as you suggested in the post. At first I was at 24 hours because you can wake up and find new content everyday and be in the rush to vote. However, I do like the idea of 2 hours, as you said it creates a bit of competition and 2 hours is still plenty of time for manual curators. Maybe 2-3 hours can be game theorized and see if it makes much difference.
As for the reversion back from penalizing small votes, (comments got hurt the most by this) I am for this. I think we should try to boost engagement at all times and most users simply stopped voting comments because they can get better ROI (by a long shot) curating and voting bigger on post.
Why are we still trying to game theory the votes?? We have to accept there will always be side effects we can't predict before implementing the incentive change.
Let's make the window at least 24hours, I can't log in every 2 hours, it's insane.
A 2 hour window will force me to vote posts that were posted in the last 2 hours (even if I don't like them!), and will prevent me from upvoting posts that I enjoy but were posted 5 hours ago.
Hive is a global network and people are not awake at the same time. Content creators in different time zones will lose votes simply because of the time at which they post.
@blocktrades @theycallmedan
Because that's the smart thing to do when you create an economic system.
I don't think this is true. The possibility of making a mistake does not mean that mistakes are inevitable. And to the extent that the consequences are not always easy to predict, it still doesn't lead me to the conclusion that changes should not be made. IMO, this is clearly a change for the better.
You don't need to login every 2 hours. As mentioned elsewhere, you just need to find some good posts to vote on that have been posted in the last two hours. Given sufficient quality posts and reasonable tools for helping you find such posts, that shouldn't be too difficult, but to the extent that it is, the people doing such work deserve more rewards.
Auto-vote trailing of manual curators will likely negate any impact of that. In fact, it's reasonable to assume that some auto-vote bots would intentionally target posts made during "off hours" for more votes, because they would then benefit from manual voters finding the posts later after the two hour window.
Thanks for the input on the penalizing of small votes. What you said jibes with what I've heard in the past, although I wasn't aware this also reduced voting on comments.
If I recall correctly, the original motivation was to make it difficult to do some sort of large scale, low value self-voting. But I may have that wrong, and even if that's the reason it was introduced, I'm not sure it solved any real problem. I'll try to dig up the reasons, and see if there are any compelling reasons to stick with it. But my first guess is there aren't any.
I don't think changing the window does much to change human behavior to be honest. The bots just get set to whatever that window is in order to maximize. Getting rid of the window entirely and moving to straight linear is what LEO has done and it makes sense on a lot of levels. One of the biggest being that it keeps things simple for new users. One of the biggest problems with all of this is in terms of attracting and retaining users is how complex it all is for people outside of crypto.
That being said, it's never a good idea to make changes just because they are more "simple". This change also allows users to vote on what they actually like instead of worrying that they will be the last vote and lose curation etc, which is more or less what we are trying to accomplish with voting anyways, people voting on what they like. Also, agreeing with @theycallmedan above, yes the current voting system has killed comment voting as well as new/small users as they get 'penalized' until their vote is of sufficient size. I get the reasons behind some of these changes a while back in terms of trying to prevent abuse, but we have gone so far in trying to prevent abuse that we have killed on-boarding... which is the exact opposite of how/where we should be focused in my opinion...
The main change a longer flat window does is bring manual voters on par with auto voters. With the short time window, it was impossible to be a manual curator that earned as much as an auto voter. However, when all things are even, manual voters should earn more or at least more than they did before. The reason being if auto voters don't start following the manual curators (which dnst hurt the manual curator with a longer window) then they may start over rewarding content, which can lead to downvotes. How many times have you seen those embarrassing auto votes on a "This post has been deleted, Do not vote!" - ya well some people are willing to look bad for the increased rewards. So ya, all things equal, manual should earn more simply because they will be downvoted less because their votes will be strategic and realtime.
And curation isn't easy. I hire people to help with my curation, on top of spending hours a day doing it myself. When I see I earn on avg less than 10%, while auto voters earning upwards of 15%+, the investor inside me cringes. These people are doing no work at all, I'm coming out of pocket and spending countless hours and getting less. That is not an optimal system by any means.
The change really did affect comment voting, although there are a few who 'waste' their VP rewarding comments as a way to try to boost engagement on their posts, and others.
Personally, I think that as long as there is a window, there will be 'curation rewards over content' automated voting. I still automate voting on the LEO tribe following the change to no window - I can follow the tribes curation account with being heavily penalized for following a large vote, 'late'. I can see people doing this with the base token if there was no window - following curation trails like curie, ocdb, etc.
There is a concern with regards to late self-voting though, but some of the tribes (LEO, STEM, SPORTS) have already done away with the window and at present are not suffering from late self-voting. The reasons for this are due to a) larger stakeholders knowing that self-voting is like crapping in their own kitchen and b) methods being introduced to allow more time to downvote than upvote. I worked with the SPORTS tribe after they introduced 3 days to upvote, and the full 7 days to downvote. It's not too difficult to run scripts to check who's been heavily (with stake or numbers) self-voting comments (either with same account or an alt), and having a few days after the last upvote can be cast allows time to check for 'abuse'.
Thanks as always for your work on Hive!
There will always be auto-voting as long as there are curation rewards, IMO, because not every stakeholder will want to curate. Accepting that premise, I think the proposed solution will at least direct that auto-vote towards more deserving posts.
I agree. Following a respected trail with an auto-vote knowing you wont be penalized feels more acceptable and better than the network over auto-voting an author who is known to collect decent rewards just because of the network they have. A removal of the any window could steer more to the former.
In my opinion, the "Rewarding Curve" is one of the most painful measures adopted in the past and the most discouraging in terms of engagement promotion. As @theycallmedan said to boost engagement is a MUST do.
ok some stupid question from me, what is with flat rewards 50/50 no curve? Or curve begins after day 3 so it's not last minute voting for rewards.
Will this just lead us back to the spam days?
But I do like the concept. The proposed change will still have the end result be that a few content creators will consistently get all the votes.
I don't see any immediate reason why this should lead to more spam (assuming you're talking about the 2 hour window change). If you're talking about going back to straight linear vs quasi-linear, I think it had no real impact on spam either.
As auto-voted stake will likely be guided more by humans reading posts than by a simple list of authors after this change, it should spread the rewards more equitably among authors. How well it ends up distributing that stake among a large group of authors should mainly depend on the number of quality authors.
All the spammers moved to blurt.. If anything we should be thanking them for leading away a lot of the less than savoury characters to pillage their ill thought out chain instead of ours. XD
Hi blocktrades, it's a really nice change for the masses to come. I completely agree with this change. especially to eliminate automatic voting. I noticed that very few users cast the votes manually. and I see a lot of users who create really amazing content but only get very low sound. I hope the changes you'll make to eliminate automatic voting can happen quickly.
I think, this along with the ability to create their own tokens based on HMT would take HIVE to the next level. I saw a marketing campaign from The Man Cave Project on twitter and I think, this should be on the top of the list.
Good call on the witness/ DAO decay, essential change I think, certainly THE change I was most hoping for in the next HF.
And extending the vote window is also good - although I think nearer 24 hours would be best, we do operate across multiple time zones and a day should still allow for a reasonable rotation on trending.
Quite organised for a brain dump.
2nd Layer Dapps should always broadcast a HIVE BlockID with their transactions imho. That way we know what block that specific dapp is synced up to. Also, to make it less demanding for dapps, they should be able to reuse the same HIVE BlockID for up to X amount of blocks.
It certainly would be good practice to do something like this but is a matter of developer preference me thinks.
Would be interesting to standardize this sort of thing though. Certainly would consider doing this with my own development endevours!
How are you guys planning on handling the expiration of current votes? Having all votes removed on HF day will probably have some major shakeups and so will doing it a year from HF day.
HF day could just be the start of the 1 year Countdown.
Yes, this is one of the probable ways to mitigate any potential problem.
The first thing we'll do is run a simulation to see the impact of doing nothing in particular. Then if there looks to be an issue, we'll examine ways to smooth it out more.
I don't think this can be done all at once, which could be too risky for the stability of the blockchain. Rather, I think a better approach would be to delay the action until we have a large voting campaign, so that we will have a voting base with an expiry date already in place before the action takes place 😉
@mintrawa: Witness FR - Gen X - Geek 🤓 Gamer 🎮 traveler ⛩️
Don't miss the Hive Power UP Day! more info here
@blocktrades should really be the emperor of HIVE. 100%
Does this one wear clothes?
If not, he could help to support Dporn.
hard to know if BT is wearing pants really. lol
He might have been ahead of the zoom trend.
Always walked around in a dress shirt and his boxers.
Just to be clear when he says
HMThe meansSMTit actually stand for smart media tokens and not steem media tokens. But lots of people expect smts to be a steem thing so they naturally convert it toHMTand use both terms interchangeably.I've always wondered: What makes them 'smart'?
Their ability to escape development
Haha, splendid quippery!! :0D
I try to keep my humor to myself most of the time, as I don't want to waste it.
Terve!! Minä olen Boomy.
Quite rightly, you can't be wasting the good stuff.
Can you tell, I'm still watching the Finnish drama?
No nii - I find it weird that anyone would watch a Finnish show. Unless...
Is there nudity in it?
Only something incredibly brilliant can escape release.
This all makes so much sense.
awesome reply :))))
haha, made my day!
bahahahahah. Almost spit my coffee out
Well played
Proof of Brain I think. The inflation is distributed according to votes
People are really serious about moving away from Steem, they need to chill. Even though their token price is higher, they are just a centralized network and it will be better for everyone if we just ignore them.
Another problem that is still here because of the hardfork is powerdown. People have stopped talking about 4 weeks powerdown simply because steem did it. It's ridiculous.
This is news, I am shocked. Thank you, guys!
Sounds good! Some thoughts below
Does this mean that within the 2-24 hours, the rewards will be equal across the curators and decrease after that?
One thing that bugs me about this, is the fact that we actually really only need 1 open-source interface. There could be different teams hosting different versions but based on one code-base.
What's missing for me yet is something to incentivize token holders. I think it's crazy that LEO is creating more demand on the surface than the currency which bootstrapped everything. Why is LEO able to create and hold liquidity pools on Uniswap, while HIVE has no liquidity & volume. Any idea on how we can change/improve that?
This is easy - LEO has liquidity and volume on Uniswap because they use a portion of their inflation to incentivize people. Hive can and probably should do that too, and it's pretty easy as well. We could just create a DHF proposal that would give a certain amount of funds to anyone who provides liquidity to the wHIVE-ETH pool on Uniswap. It could be done in a somewhat decentralized way too with some development effort put into it.
This is the type of thing that I think would be a perfect use for DHF funds - incentive for people to lock up HIVE and provide liquidity on Uniswap.
After decentralized WHIVE is finished, I will create a proposal for this.
Awesome, I will heavily support something like that!
Awesome :)
Should be done for hive too. very good idea
Thanks for the write-up. Yes, I'm aware of the LPs incentives, I just meant what I wrote more in a generalised/dramatic way. I agree with your idea of utilizing the DHF for that though!
I agree, I don't see why we should be paying $130,000/year from the DHF to finance an interface a handful of users use.
Ecency is technically better than condenser, which should create the discussion of whether we should sunset condenser and use Ecency with a different color-scheme for https://hive.blog. Personally, I think this would also set a visual statement that Hive is truly not Steem anymore, by discontinuing the first application Steem ever had and going with something that is leaner & much faster.
In that case, paying a whole team 130k to maintain the primary native social app on Hive is worth it.
I haven't looked at it much but it doesn't look like a huge improvement from Hive.blog. Peakd on the other hand is light years beyond both. The only thing with Peakd is I wish there was a simpler normie friendly mode that it defaults to with the current advanced mode being suggested about a week later or even a month once the user gets more familiar with Hive.
Last I checked we are paying a significant amount for both front ends yet Peakd is by far the most popular.
By paying so much for these proposals we are just adding a lot more sell pressure to the Hive token for something I don't think is worth the money.
We are paying two teams to maintain two different front ends, one has a very small user base and one is used by the majority of Hive users.
From a joke I wrote near the end of March this year.
You check out my stand up I did in VR the other day? You might get a kick out of it.
I missed it! Going now...
Peakd is great, but it's closed source. It's written in Vue, (which I'm quite experienced with by now, so it would be much easier for me to contribute than React code). It has more features, but lacks in clarity, UX design, simplicity and is not yet enhanced for speed. Open up Peakd and Ecency and you'll notice how Ecency is much faster.
Personally, I think Ecency is the better candidate for the default open-source social-interface for Hive. It will need more work for sure, but the fundamental code it's built on is A+.
I've got much love for Peakd and the team behind it, but it will most likely require a rewrite and open-sourcing it, as closed-source code is non-acceptable for hive.blog.
Problem is that rewriting it would take time and two dev teams working on two different open-source code-bases is not efficient. If they do want to rewrite Peakd, I'd advise on looking into making Peakd not only a "Hive" interface but something blockchain-agnostic with an independent revenue model.
Last but not least, IMO any project getting funded by the DHF should be open-source and specialised for Hive.
I agree entirely ... we want to do things like this. In the meantime there are some small ui changes even wording changes we could do very quick to make things easier.
뒈져~!
I think is 100% worth it to make it. But it should be idiot friendly for users like me, that want to make there own front end. I would wish for something as easy as a WordPress ( or other CMS) installation. So the technical foundation is done and the marketing can begin :)
With Smart media tokens / second layer/hive engine or whatever it can be a huge gamechanger if this works for the less technical user ( not fulltime developer)
because we need different front ends that idiots like me can use at some point like a WordPress installation. I think that's worth on a longer time scale.
Is it under anyone's radar to work on atomic swaps?
There's two distinct concepts that are often confused: atomic swaps and trustless crosschain transfers.
Atomic swap technology is well-established and relatively simple to implement (it was implemented in BitShares for instance). You can find more about the tech here. But as the BitShares guys found (well, I tried to tell them before they implemented it), it's not really the technology they were looking for.
What people are usually looking for is a trustless way to transfer a coin back and forth between blockchain networks. Atomic swaps don't achieve this, because they don't provide a mechanism to peg the value between coins on each network.
Trustless crosschain transfer is a much more difficult problem, although there are feasible solutions. We did some research into this area many years ago and had what I believe were viable ideas for it, and it is quite likely we might revisit the ideas again. But it's not something I'm planning for hardfork 25.
What can I say more than thanks for the constant work
Hi there!
Thanks for your regular updates on what's going on on hive dev side.
Any thoughts on power down reduction period?
The current powerdown time discourages exchanges from staking their customers' coins. So I'm not eager to change the power down time.
The current powerdown time is also discourage new investors to stake.
Most importantly it discourages most of our HIVE community members to power-up.
I strongly believe that exchanges have too much money that 13 weeks or 5 weeks makes no difference for them.
Somewhere between 5 - 10 weeks staking is what I wanted to see
4 or less is good. you twisted my arm so ok, I'll settle for 5 :)
And if the question is: why should an exchange be able to Power Up?
How do you stop them?
You cold stop it from one account, but an exchange could just set up another.
I dont think there really is a way to prevent then from doing that. It is part of all hive wallets.
Maybe with an agreement and coding. Is the blockchain consensus that should make the "rules" not the Exchange. Or should we be on the hands of a exchange to have an exchange listing hive?
I know this can sound a bit arrogant but is not my intention, what I mean is we (all hivers and the blockchain it self) must count more than an exchange and never more be in risc with a "stake attack" like it happened on Steem. Now it take 1 mouth to that "stake attack" but if for some reason happens we have to take some action, so maybe a pre agreement may be accepted by exchanges, don't know..
Anyway.. I'm comfortable with actual power down, just not sure if potential investors are.
You could give recognized exchange accounts other privileges in return for losing voting rights. E.g. listing them on the front page or in a wallet menu, or paying them interest.
Job well done from the team... We are moving forward..
Sincerely,
You guys are awesome. Thank you for such a clear and concise map of upcomming changes.
It's like you guys really do want HIVE to be successful; unlike the previous "Leadershiip" in the previous chain.
HIGHLY Appreciated!
Nice to see this!
About the topic SMTs or second layer user defined tokens, would be nice if the wider community see more infos about it in some next posts.
We don't know much about them. Even less for the second layer tokens. Having two options will be a bit confusing.
The end goal should be easy and no dev (or very little) knowledge to create communities tokens.
Also it would be interesting to have some discussion (maybe even dhf voting) on some of the Hive tokenomics features.
I agree with you about the confusion.
The idea of HMTs (SMTs) appeals simply because it is instantly as decentralized as the HIVE token in terms of the number of nodes supporting it.
If we go with a second layer smart contract solution, the issue of centralization comes in.
Here is where I think more clarification is required as to how that will look. From past posts, I understood it to be some type of multi-server system.
Understanding how the proposed second layer smart contract solution would look is necessary I think. With that, users will be better informed.
Yes, I have much more to say on the topic of tokens (and tokenomics that are beneficial to Hive holders). But I don't want to get too deep into these economic issues until we've built some simple prototypes to explore the smart-contract evaluation system from a tech perspective. And to do that, we're going to first want to make 2nd layer apps easy to build as this is a precursor to developing that, and it's tech that stands alone and is clearly needed not just for the smart-contract system but for the entire apps ecosystem.
I agree with the work on the 2nd layer for dapps.
A lacking of a better interface is slowing our development.
A lot of your "modular" hivemind goals sounds a lot like the project we are working on because of a lack of this.
This will be necessary to grow dapps.
I would also like to bring up the point once again.
All the 2nd layer dapps are great but if the core blockchain only pays out on Blogging.
It will be hard to attract other types of dapps.
We still have to use a voting bot to reward our game players because of this.
Really appreciate all your work!
2nd layer smart contract tokens are likely to be the easiest solution to the economics problem you're bringing up. And to make sure that the Hive token holders benefit from the work done to develop it, there should be an airdrop of the gas token for such a smart contract system on Hive holders. I've got some early ideas about how this would all work, but prototypes need to be built to fully explore the idea space properly.
agreed.
we will be releasing something hopefully in about 4 weeks or so.
I Think this is a good idea!. Tanks for share with us!
Happy to see the demise of the 5 minute window.
The big manual curation projects will be able to reach in 6~12 hours I believe. 24 is a bit much and 2 requires everyone to not sleep or have helpers all over the map.
I like the discussion about second layer stuff and think more discussion is good.
The governance idea is long overdue.
I am loving all the updates here.
I will say 24 hour , because I guess there are so many like me that come daily to platform but not in every 2 hours.(everyone has a job to do) checking at every 2 hour is not feasible at all. Give more power to daily users in turn they will give more power to hive.
That make a marketplace in Hive very unique.
Yes, but I don't see the need for everyone to "get in early" on every good post that is created. There just needs to be sufficient good posts for them to vote on during the time they are curating that are still in the two hour window.
Making the window shorter means that people will have to do a little digging through the new posts that have been created, instead of just upvoting the trending posts to maximize their rewards.
Do you think it is an equitable split of the inflation when the top curator is making 16x what the top author gets?
If we hard forked out the vote sellers, why do we tolerate the wholesale selling of votes by tolerating delegation for profit?
Thanks for the update. These changes will help HIVE moving forward. I'm sure there's a lot of work needed to implement the plans but I'm confident that the "team" will be able to do it. Kudos to the devs working on these.
I'll just go with the flow. The changes mentioned here can/will be beneficial and could potentially bring on a new set of challenges, but that's to be expected.
@blocktrades. Are you passionate about this project? Does it bring you joy?
I'm passionate about some aspects of Hive, less passionate about others. I'm mostly passionate about the rating calculation system I want to build on top of Hive, as I think it addresses some of the major problems we all face nowadays in practical epistemology (if one accepts there is such a thing, and I do) and in fair/optimal economics.
I'm curious to see where you're going with that system. Save it for a post though.
How do you feel about — rather than taking another shot at reinventing the wheel — we simply randomize voting order at payout... ?
Everything could remain as is, but every post would turn into a fair curation reward lottery. It won't matter who votes when or how. Some days people get skunked, other days they hit the jackpot. Auto voters can't snag a better position. Late voters/actual consumers/contributors aren't topping up the wallets of noncontributors. Every vote is an equal opportunity.
Randomization on a blockchain is more work than it sounds, especially to get it right. The proposed change is actually easier.
It's times like these I regret giving up on Qbasic, back in the day. Instead I focused more on the art side of development.
I'll just take your word for it. LOL!
I'm glad and happy with the ideas shared as a roadmap.
I was eagerly waiting for this feature. I personally thought 1 year is too long and maybe 6 months would have been a better timeframe.
It is still a question as to how it will work with the current proposal system. There are some proposals created by people that last only for 3 months or even less than that. Maybe a downvote option for the proposal system alone would help? Currently, there is no option for the community to tell if they don't want a particular proposal.
Wow, I like this idea so much. Right now most of the dapp developers are dependent on the public nodes that run Hivemind. There are still lots of latency issues where for example, even after 3 minutes delay I'm unable to fetch post details from condenser_api at times. It is also very costly for us to run our own full hivemind instance. If we can modularize hivemind, it would benefit the developers to run only the particular module that we would need.
Thank you so much for all the hard work that you and your team do.
$tangent
Congratulations, @asimo You Successfully Trended The Post Shared By @blocktrades.
You Utilized 2/3 Daily Summon Bot Calls.
TAN Current Market Price : 1.500 HIVE
Thank you for taking time to put this on writing! Excited about the future.
This mean if user sets the proxy, they have to renew as well right?! Because if proxy performs governance action, proxied account also getting last action updated means everyone would potentially proxy. Once a year is quite reasonable, especially notifications and email subscriptions could be handled by frontend.
Would great to explore/research idea of creating token on 1st layer and customizing it on 2nd layer solutions. Like define initial token parameters and assign account to perform future changes only to certain areas, of course supply and other critical parts shouldn't be allowed to change, but with proper migration technique it is possible to create robust system. If token needs critical changes there could be migrating mechanism to define new token id and old token would convert to new token with different parameters, just thinking out load but this could be researched deeper.
Yes, the governance action is separately associated with each account. So a governance action by an account's proxy only sets the last time for the proxy, not for the accounts that proxy to that account. So accounts that proxy must renew their proxy request (or cast a 0-valued governance vote perhaps).
I agree there's a lot to explore on the topic of user-defined tokens. It's one of the reasons I haven't wanted to describe any particular implementation in detail yet: with the many new possibilities inherent in 1st and 2nd layer tokens, we've entered unchartered territory, so careful investigation is required to find the optimal solution.
Super post man!
The potential to enter a higher dimension.
So excited about decentralized reputation and its possible implications for society!
Yes, this is ultimately what I'm most excited about too. If I ever have a magnum opus, this will likely be it.
All good stuff. Improving curation so that the cream rises to the top and the manual voter doesn't feel like they at battling the bots will for me be the greatest change. It also seems that keeping the curve someway like it is will keep a bit of competition going.
I also like the idea of a new reputation system. I can imagine that it could also have wider uses outside the ecosystem.
Thanks, as always for keeping the community updated.
The decentralized reputation system will run into political issues if the ratings are not completely private.
Also, I believe everything else in the roadmap is much more critical to hive for the next 1 to 2 years. And as always, things will require more time than they should.
Ratings are planned to be a mix of public and private information.
Software timelines are always difficult to set. But the things planned for HF25 are easily achievable in 6 months I think. The other features don't have set deadlines, so we just do the best we can.
First let me say great update!
Questions:
MT is media tokens.
HMT - what does the H stands for?
I think the 2 hours window is a wonderful change.
The advantage should also be simple and not to high on later voters up to 24 hours (lets give all timezones a chance).
Very good news and wonderful to see how the developement methods of the future starting here on the decentralized Hive.
HMT = Hive Media Tokens
Right under my nose :)))
YEAHH Fucking Finally!
with all the overexcitement from btc and atlcoin pump we had fuzz all over Hive's price and why it remains like this! I read countless posts of people wondering, sharing their thoughts as well ideas or issues that we need to overcome!
Reading this roadmap type of post i think it's clear we have certain goals, works is been down and most of our issues are noted and will be taken care of! I am really happyn after reading this post i expect a lot!
Keep spirit
I was expecting RC delegation feature in next HF or atleast in tge roadmap, but couldn't find it. It is one of the most demanded feature wif we want to onboard masses.
Good Luck with all the updates. Great work and keep it up.
As I mentioned at the end of my post, this is just a list of changes that the BlockTrades team plans on implementing. I believe @howo has done some work on the RC delegation feature, which we'll review for possible inclusion in HF25.
Thanks for heads up. You are really doing some great stuff, empowering HIVE. More power to Blocktrades and Hive.
That's cool. We should make some table "who is working on what". Because there are so many awesome things, but is hard to follow them all.
1 graphic with all major plans + links to the content would be awesome. I would do it, but I'm 100% sure I would miss a lot :)
Thanks for that, it was really what I was hoping to read. (For us, new witnesses could be a sigh of relief)