Core development proposal year 6

25 comments

howo10.7 K3 days agoPeakD6 min read

Hello everyone!

I have had the pleasure of working on Hive for five incredible years, and I am grateful for the support you have all given me. I would like to carry on working as a core developer and contributing to Hive for a sixth year.

Who am I

I have been on this chain for more than 8 years now.
I went from regular blogging, to contributing to open source on hive to building dapps and running a top 20 witness (@steempress now deprecated). I became much more involved in core development when we forked away from Steem, rising up to the occasion as we needed every manpower we could get to birth the chain. I contributed to the soft fork that locked Justin sun's funds and later the very first hard fork that created hive. Ever since, I've been working on hive as a core developer contributing to hive and hivemind implementing sensible requests from the community.

If you're interested in my full journey I made a throwback post retracing most of my activities on steem then hive here: https://peakd.com/hive/@howo/my-hive-story

Notable examples of my work

If "core development" does not ring a bell to you here's two features that I shipped to give you an idea:

Rosetta/Mesh API

This deserves its own post later, but the gist of it is that in order to integrate with coinbase, they require blockchains to create a set of specific apis https://www.coinbase.com/en-ca/blog/introducing-rosetta-build-once-integrate-your-blockchain-everywhere, so that all blockchains speak the same language. It's no easy feat because the documentation is very generic so a lot of back and forth was needed with coinbase to see how we should implement things, for instance there's a whole section about generating addresses on the fly and UXTOs which is something hive doesn't use. But now it's done and HIVE no longer has any major roadblocks to being listed on coinbase !

Recurrent transfers

Before if you wanted to subscribe to a service on hive you had to either pay upfront for a long period of time (eg: a year), send a transfer every month or worse: trust their active key with the service (NEVER DO THIS), which was a pretty terrible UX for those who want to build businesses on top of hive and benefit from one of our main selling points: fast feeless transactions. Now with recurrent transfers users can simply set a recurrent payment, and every time it hits their desired frequency, the money is sent from their account. It's a much simpler UX similar to one you're see on web2 payment solutions like paypal

New community types

Part of the roadmap for communities is to empower community owners to fine tune who can post or comment in a hands-off fashion as the software takes care of everything, when previously you'd need to be there all the time to moderate posts/comments. This enables them to create paid communities, enforce quality by vetting quality writers or whatever else you may find interesting ! This also means it's very easy for community owners to build systems on top of it, want your community to only be accessible if the user owns a specific NFT ? Or if they have an active recurrent payment to you ? No problems !

If you want to read a bit more about it:
https://peakd.com/hive/@howo/communities-is-getting-an-update--what-to-expect

RC delegations

If you've joined hive in the past two years you probably heard a decent bit about this one. RC stands for resource credits, whenever you do a "free" transaction you spend RC, but unlike other chains like ethereum, it's free and recharges over time. The more Hive power you own, the more total RC you have to spend. And for the longest time Dapp developers had a big issue when onboarding:

Either you make users pay for their hive power when you onboard them, which is going to drastically hinder your growth, or you have to delegate hive power to them, which means people will try to abuse it by registering hundreds of accounts to get free hp and self vote. We've seen this play out times and times again and the solution that most dapp developers has been to police and check every new subscribers. Which obviously is a lot of wasted time and money that should instead be spent on building.

Rc delegations allow you to delegate RC but not hive power. allowing users to execute transactions and try out dapps, but without any monetary power. It also can be executed with a posting key as opposed to an active key for hp delegations, so should this be executed by a bot, you no longer need to expose your active key to an online environment (eg: a server)

Some other notable examples from this year

Obviously big features isn't the only thing I do. I also work on smaller things, low hanging fruits, bug fixes etc here's some examples from this year:

Removed the DHF hbd from inflation calculation : There was a threat of an uncontrolled inflationary spiral where should the price drop significantly enough, the HBD in the DHF would become a larger portion of overall marketcap raising the inflation, which will effectively drop the price further, which will raise inflation etc... leading to massive printing of HIVE and effectively driving hive price to 0. Before this development, the only way to stop such spiral would be to make a proposal and burn a large portion of the DHF, which is capped at 1% per day, so it's not like we can quickly react to such an event.

Removed hive_payments table and promoted feature from hivemind some features are in hivemind but no longer relevant, this removes a lot of dead code and saves all node operators compute power and most importantly space

Explicit field describing why a post is muted: when your post gets muted, there can be multiple reasons why (posted in wrong community type, you're muted, moderator muted you etc). Which is quite the bad UX as newcomers won't know what they did wrong. This fixes this by exposing the reason why they were muted to front ends who can then show the info to users.

new api to simplify profile fetching for front ends: this was a request from @asgarth (peakd team), this allows front end to fetch a list of profiles without having to get ALL the data from them, this helps remove load from nodes and make front ends snappier as it requires less api calls to get the same result.