dWeb Foundation is a grant-giving org that gives large-scale projects or contractors grants between $25k-$150k on a quarterly/semi-annual/annual basis depending on the individual project being proposed.
I have worked on bcoin and related projects (bmultisig, bledger,
bsigner) as well as bcash fork for quite some time (3+ yrs) and have
pretty deep background both in bitcoin protocol and the codebase.
Motivation
Handshake and related libraries all need maintenance and in some cases
essential improvements. There are very few people working on the
hsd itself and issues are getting backlogged.
There are currently several PRs that need review/testing before they can be
merged. Some critically important improvements still need to be ported from
bcoin since a good deal of work was applied to bcoin after the hsd fork.
Scope
The project scope is relatively big, Handshake encapsulates several
projects in itself: hsd, hsd-wallet, hnsd, hsd-ledger and multiple
components around these projects. The tasks for each project can be categorized
as: bug fixes, improvements, features, review, research. All of these
can be part of the scope for this contract or some of them.
These are summaries of the task definition:
bug - mostly small bugs that are not critical, some small bugs can lead
to improvements if better solution is to rewrite some parts of the project.
improvements - Improving quality of the codebase for different reasons
(performance, quality, tech debt, extending tests and etc.) - this are from
mid-to-big sized tasks.
feature - Range of the feature is wide, so its' size can vary from small to
big. It can be just extending API for easier consumption to implementing
soft/hard forks.
review - Review is necessary for any of the above and is critical to the
handshake project, even when reviewing simple bug fixes. In general,
complexity of review depends on the complexity of the task and mostly
scales linearly to that complexity.
research - Issues that fall into this category can be any of the above
similar to review, but can't be easily quantified.
Priorities
Priorities are never static and can change depending on the feedback from the
users, investors, projects or from the community in general. It will also depend
on the length of the contract - as many of the important backports can't be
accomplished in small timeframes and may only allow for bug fixes and reviews.
I will try to list couple of priorities that I think are necessary. It may
change with further involvement in the project or from the feedback.
There are some optimization research that needs to happen to the fullnode
codebase, that became apparent in the last PR I was working on: blockstore. That
is essential in order to outline the changes necessary to benefit from
blockstore, checkpoints and possibly some future improvements to the codebase.
It may lead to the improvement implementation.
There are small or moderate sized PRs backlogged that will only
get harder to merge as time goes. Every change introduced to the codebase,
makes it harder (depending on the PR context) to merge old PRs,
so I believe it would be good next step for the hsd codebase.
This mostly includes bug fix types or small improvements and is
in the review category mentioned above.
Issues on github need to be categorized, because they fall in range of the
categories described above(applies to PRs to some degree), but as priorities
go - bug fixes first and then improvements and backports.
Backports are, mostly, the biggest in size and depends on the contract length,
but also one of the most important improvements to the codebase. It applies
to hsd as well as hsd-wallet.
Next will be non-backport type improvement/features that are big in size
and may not be critical right now, but will become important as the chain
size grows. There are some in issues, that may lead to improvements or
discover new ones with more research and feedback.
hnsd also has several big PRs as well as important issues pending to be
fixed. Priorities in hnsd are similar to hsd, where bug fixes are the
most important in order to ensure services that are using it don't get
held back because of it.
There are also important features and improvements pending in the PRs,
testing needs improvements. Issues are same as in hsd - they fall in
many categories and some need research.
Contract
Previous big project I worked on was backporting blockstore from bcoin
to hsd, we had milestone of two months - but it became apparent that without
improvements to the codebase it would add to the tech debt(migration PR).
So the timeline got extended but funding did not, which left me in undesirable
position. That's the main reason this application is not project based but more
open and hopefully will scale with the contract length.
It is also hard to come up with set of issue/PRs as a project without
research or may not be good enough as separate project even if it fills up
the time. Some issue/PR may need several back-and-forth communication in the
review process and is done better with more open contracts.
I am flexible with time logged per/week and the way we communicate about this,
from part-time (20 hours per week) to full-time (40 hours per week) and any in
between. I would like to get paid 60$ per hour, also open to communicate on this
further.
HSD development/maintenance
Motivation, milestones and goals
My background
I have worked on
bcoinand related projects (bmultisig,bledger,bsigner) as well asbcashfork for quite some time (3+ yrs) and have pretty deep background both in bitcoin protocol and the codebase.Motivation
Handshake and related libraries all need maintenance and in some cases essential improvements. There are very few people working on the
hsditself and issues are getting backlogged.There are currently several PRs that need review/testing before they can be merged. Some critically important improvements still need to be ported from bcoin since a good deal of work was applied to bcoin after the hsd fork.
Scope
The project scope is relatively big, Handshake encapsulates several projects in itself:
hsd,hsd-wallet,hnsd,hsd-ledgerand multiple components around these projects. The tasks for each project can be categorized as:bug fixes,improvements,features,review,research. All of these can be part of the scope for this contract or some of them.These are summaries of the task definition:
Priorities
Priorities are never static and can change depending on the feedback from the users, investors, projects or from the community in general. It will also depend on the length of the contract - as many of the important backports can't be accomplished in small timeframes and may only allow for bug fixes and reviews.
I will try to list couple of priorities that I think are necessary. It may change with further involvement in the project or from the feedback.
There are some optimization research that needs to happen to the fullnode codebase, that became apparent in the last PR I was working on: blockstore. That is essential in order to outline the changes necessary to benefit from blockstore, checkpoints and possibly some future improvements to the codebase. It may lead to the improvement implementation.
There are small or moderate sized PRs backlogged that will only get harder to merge as time goes. Every change introduced to the codebase, makes it harder (depending on the PR context) to merge old PRs, so I believe it would be good next step for the
hsdcodebase. This mostly includes bug fix types or small improvements and is in thereviewcategory mentioned above.Issues on github need to be categorized, because they fall in range of the categories described above(applies to PRs to some degree), but as priorities go - bug fixes first and then improvements and backports.
Backports are, mostly, the biggest in size and depends on the contract length, but also one of the most important improvements to the codebase. It applies to
hsdas well ashsd-wallet.Next will be non-backport type improvement/features that are big in size and may not be critical right now, but will become important as the chain size grows. There are some in issues, that may lead to improvements or discover new ones with more research and feedback.
hnsdalso has several big PRs as well as important issues pending to be fixed. Priorities inhnsdare similar tohsd, where bug fixes are the most important in order to ensure services that are using it don't get held back because of it.There are also important features and improvements pending in the PRs, testing needs improvements. Issues are same as in hsd - they fall in many categories and some need research.
Contract
Previous big project I worked on was backporting
blockstorefrombcointohsd, we had milestone of two months - but it became apparent that without improvements to the codebase it would add to the tech debt(migration PR). So the timeline got extended but funding did not, which left me in undesirable position. That's the main reason this application is not project based but more open and hopefully will scale with the contract length.It is also hard to come up with set of issue/PRs as a project without research or may not be good enough as separate project even if it fills up the time. Some issue/PR may need several back-and-forth communication in the review process and is done better with more open contracts.
I am flexible with time logged per/week and the way we communicate about this, from part-time (20 hours per week) to full-time (40 hours per week) and any in between. I would like to get paid 60$ per hour, also open to communicate on this further.