On Tuesday, at 15:00 UTC the Steem blockchain hard forked as planned.
It wasn't a successful initial user experience, but it wasn't a failed hard fork from all I could see until now. I'll stick with the word I used: it was as expected.
I think lately, enough people have joined Steem who couldn't care less about the technical side of it, but care about Steem and its future. Therefore, we need to find the ways to ameliorate considerably the user discomfort while the blockchain "upgrades".
And not only that, but it is the most obvious example we have in front of our eyes in recent memory. Otherwise I think ALL relevant DApps need to upgrade their UI in time, to include tutorial-like steps, taking users by the hand, introducing fun and gamification to their interfaces.
On the other side of the coin, we should keep in mind upgrades on the blockchain (especially the major ones), take much longer than on centralized systems, and any bugs found need fixing, which may need many other hours to apply to the blockchain. I'm trying to use a language as less technical as possible here.
I never had an Apple computer, which seems to be failure-proof or something like that, but those of you old enough to remember Windows in its first versions (when it came on floppy disks), you also remember the amount of bugs, blue screens and how much time and work from your part was needed to bring it to a stable version.
Well, Steem is two and a half years old. Remember that!
I won't talk in this post about the particular issues that were found post-hardfork. I may be contradicted, but I believe from the technical point of view they were minor. Nothing major broke. The RC system didn't have to be reverted to the old bandwidth system (a fail-safe which was in place and at the disposal of the witnesses by the way).
On the other hand, the frustration created by these issues among the users was considerable, and many voiced it with good reason.
There is a gap here that needs further attention in the future. The gap between the severity of a potential issue from the technical standpoint and its implications from the user experience.
Some of these implications are unpredictable and can only be seen in the real ecosystem, when everything is on and everyone starts doing their thing.
It has been pointed out that better testing conditions, rules and documentation for it, and maybe assigning testing roles I'd add, are necessary. Also that witnesses should make clear the conditions under which they vote for a hard fork, which shouldn't be too rigid though.
A testnet existed for this hard fork for the first time (meaning there wasn't one on previous hard forks). On a testnet it is difficult to replicate the exact conditions of the real net, and even more difficult to generate the conditions of the hard fork to match real ones.
Being the first testnet, communication wasn't very good between Steemit, Inc. and the witnesses, and there were some assumptions from both sides that weren't quite true, from what I saw. It's definitely needed a better communication, documentation and rules for the next hard fork (which will probably be for SMTs).
Steemit even had a condenser on this testnet. That is, they had a steemit.com clone for the testnet. I briefly used it, but I wouldn't call that testing. Not really! Not sure if I could have helped much from the condenser either. Would have been helpful if users were aware of it and told what to do?
Following this hard fork there are some decisions I personally made
I'll be watching from now on - as in receive notifications - all Github repositories I consider relevant to me for the Steem blockchain starting with https://github.com/steemit/steem. If I feel I can contribute in any way, I'll do that.
I approved two new witnesses, both outside Top 20 at the moment:
Since I always have my 30 votes given out, two other witnesses lost their votes from me these days. I hope no one takes it personal, because it isn't. I reevaluate my witness votes regularly.
Since I'm on the witnesses ground, I am interested in initiatives that analyze the possibility to reduce the replay time (
Both of them would be in the benefit of a smoother user experience, as we move forward, as well as less workload for the witnesses on the technical aspects.