It's official. As of a couple of hours ago, 
Now you may be asking yourself what is HF17? It means Hard Fork #17 and it introduces several changes that are a bit controversial but which we believe actually make steem and steemit better and more useful.
Here is a run down of all the changes and why we support them for your approval.
Remove Posting Rate Limit.
Posting rewards are no longer penalized for posting more than 4 times in 24 hours. Originally this was implemented to reduce the impact of bots posting junk content. Ultimately it ended up hurting legitimate authors.
The comment depth limit has been increased to 255.
The limitation was created to make UI design easier. Many changes we are making are to do right by the blockchain and have the UI adapt. Each UI can and should choose how deep of comments they want to display and can actively reject comments that are deeper than the limit they wish to display. The soft limit is 255 with a hard limit of 64k. 64k was chosen as a limit because the depth is stored on each comment object. This allows us to use a 16 bit field and 64k should be more than enough depth for anybody. (Reddit has a limit of 10,000)
Thank god! Few things are more annoying than hitting the comment depth limit when trying to have a conversation. This feature alone was worth the time and effort of upgrading to HF17
Comments can now be permanently edited.
We are adapting a new model of imposing as few restrictions in consensus code as possible and having witness actively reject transaction for both rate limiting and security. There is a soft freeze of 7 days that will be lifted with a non-consensus operation. This custom operation still needs to implemented, but will be included in 0.17.1. The operation will be a plugin op in the witness plugin that will inform a witness to accept edits for the next T minutes.
We've always been iffy about editing anything once it's on the blockchain. However this is a good compromise and does allow one to fix things to perhaps remedy a misunderstanding later, or retract a view that has changed and they regret.
Comments are now paid out independent of their discussion.
Paying out discussions as a whole was a design decision to make displaying discussions by total_children_rshares2 easier. It also made sense to do this with multiple payout windows. This tight coupling ultimately has proven unnecessary. Removing restrictions on depth and editing makes this idea antiquated.
This one sort of explains itself. Removing comment depth limits and fixating to a single payout window made this pointless to have, so they removed it to make our jobs easier.
All comments are paid out 7 days after creation and there is no longer a second payout window.
99% of votes are cast in the first 7 days after creation. This elimates (sic) the need for a second payout to accumulate value to a post and simplifies logic significantly.
I would have preferred 30 days for this. It can take time for content to spread onto other social networks and often I find my most fervent audience weeks after my initial postings. We support this only as a digression to Steemit Inc, because of the other features that are coming with this fork that we do support 100%.
There is now a comment reward fund separate from posts.
We want discussion to be incentivized. Currently, comments are only claiming 2% of the content rewards and there are more comments than posts. Comments will receive 38% of the content reward fund. This change should incentivize commenting, engaging in, and curating discussions.
This is a great concession! It means that discussions have value and it's seperate from the authors fund. The more you talk, the more you earn. We can finally have decent indepth discussions ala Slashdot.org and not feel like we are wasting our time.
All payouts now look at the prior 30 days of payouts to determine the share of the reward rather than the current pending rshares.
The reason for this change is twofold. 1. Looking at a 30 day decaying window reduces variance in payout due to small changes in vote densities. 2. On votes we are currently updating the comment the vote is on, every comment in the tree up to the root, and the global property object. With this algorithm we only need to update the comment, significantly reducing the amount of time spent processing votes. With this change, payouts will initially dip and then ramp up over the next 30 days until the reward fun reaches a steady state.
This seems abnormally complex, but it's a result of looking at the existing system and realizing it didn't work. Payouts are going to go down over the next 30 days, but will begin to ramp up as the new rules kick in. We can support this.
Reward Balance
Rewards will now go into a separate reward balance that must be claimed before they can be used.
That one could use much more explanation, but is supported because we are supporting HF17 in it's entirety in order to see how everything plays out long term.
Comment Reward Beneficiaries
All content can now specify beneficiaries to receive a part of their author rewards. The beneficiaries are specified in the extension field of the comment_options_operation and is a sorted vector (by account name) of account name, weight pairs. The beneficiaries can only be specified once and must be specified before any votes are cast on the comment. Most apps are already adding a comment_options_operation in the transaction that creates the comment, so this should not be much of a challenge to add to existing apps
HELLO NURSE! Alright for anyone who is scratching their head on that. It means you can start a site finally and use steem and configure the content so you get paid a little on each bit of content added to steem by your site or service. This has been a huge missing part of the puzzle for several projects that Team VIVA has been working on and it provides a solid incentive for us to begin building those right away.
Delegated Steem Power
Steem Power can now be delegated to other accounts. This transfers content voting rights and bandwidth allocation but not witness voting rights. Delegations come in to effect immediately, both when increasing and decreasing a delegation. However, Steem Power being returned by decreasing or removing a delegation has a one week delay in limbo before it is returned to the owner. This is to prevent a satoshi of Steem Power from being able to vote on the same content twice.
Accounts cannot power down Steem Power that is being delegated, nor can they delegate Steem Power that is being powered down.
Here is an example of why you would want this. 
Accounts can be created with a smaller fee and an initial Steem Power delegation.
Instead of paying the entire account creation fee with Steem, creators can now pay a smaller fee (30x less) and delegate some Steem Power for 30 days. The exact amount is 5 * min_fee + STEEM_POWER == 150 * min_fee. You can pay any combination of STEEM and Steem Power along that curve (so long as the minimum fee is paid).
The witness voted STEEM fee is now the minimum required STEEM fee for delegation. Witnesses should reduce their fee by 30x when the hardfork goes live to preserve the same required fee for an all STEEM account creation.
This means that a site such as
PoW is being removed.
PoW has been broken for a long time. Very few people pay attention to it. It is dominated by the same few people and is providing very little value to Steem. Instead of investing even more time fixing it, we have decided to remove it entirely.
PoW has never made sense in the context of a Proof of Stake coin, except to assist with initial allocations. We're glad to see this gone finally.
NTP is disabled by default
There is an option, enable-ntp that can be set to true in the config file to enable ntp in steemd. All node operators should begin using ntpd as we will be removing ntp from steemd in a future release.
I've never seen a justification for reimplementing the wheel and having our own NTP. This simplifies the client and is one less thing to break.
That's our commentary for HF17. There seem to be a lot of witnesses who are refusing to implement it and that's their choice. But we at VIVA believe that all of these changes serve to improve the steem platform and make it easier to onboard new users, new use cases and new businesses.
There isn't a valid reason in our book to reject these changes and the ones people are objecting to seem like things that can be re-examined later if needs be. In otherwords we firmly believe that 
So if you support these changes like we do, please vote for viva.witness we aren't even a top 50 witness yet though so to give us your vote, please read this guide.
https://steemit.com/witness-category/@williambanks/how-to-vote-for-a-witness-and-why
As always this post is 100% Steem Powered!
More info on HF17 and other releases...
https://github.com/steemit/steem/releases