This document will give a comprehensive view of the state of the grant work as its duration comes to a close.
Rough-Opal is a grant accepted in October 2022. The duration spanned from September to December 2022.
The original proposal containing grant deliverables has not since been edited.
Below the Deliverables and Development Roadmap from that post have been turned into a Table of Contents. This document ends with a Closing included in the ToC.
The links for each item snap to a section that references prs/issues/commits related to them. Items that are not linked have been included in the parent or child or are insignificant. Crossed-out items will not be completed as part of this grant and include a written section for explanation. All other ToC items have been or will be completed (see Still Ongoing for incomplete but still planned items).
At the start of the grant, the protocol and implementation shared the name opal
.
The grant proposal and the implementation's repo mentioned possible name changes.
Names have been changed for the protocol and implementation to hldb
and welo
, respectively.
The project now has its own Github org located at github.com/hldb.
Two significant changes involve removing Zzzync replicator
and Heavy Testing
from this grant's roadmap.
- Deliverables
- Development Roadmap
- Opal Repo Init
- begin opal design and spec
- configure project repo
- write unit tests
- prep for adding features
- make databases locally persistent
- Opal Replication and Perf
Zzzync Replicatorbegin design and spec of persistent replicatorchoose a design to buildconfigure project repowrite implementation (likely using web3.storage and w3name)write unit teststest interop with Opalwrite benchmarksautomate release with generated API docs and changelogrelease draft specrelease alpha with expected public API changes
- Release
Heavy Testingnetwork simulated testing with testgroundstress-test and benchmark replicatorscheck for replication bugs and perf improvements
- Usage References
- Release Opal and Zzzync 1.0-beta
- Opal Repo Init
- Closing
Issue: hldb/welo#8
This required persisting the replicas and indexes of each database. Enables database reads (store index), and writes (replica) immediately upon being opened.
- hldb/welo#12
- https://github.com/hldb/welo/commit/a9958dae8d105ca39f666487ee99bcb7cfee621f
- https://github.com/hldb/welo/commit/8bcbd35b8a935edffa13a9e540bd8554d3015255
- https://github.com/hldb/welo/commit/bcc880d197990688491b0bb6ecbb5ec4ffe135f8
Creating custom databases is easy now but can still be much easier, so leaving this unfinished. Necessary documentation will be added for this feature when it's ready.
Here is the key-value store model showing what will be needed. It includes a reducer, an init function (which supplies the initial value for the state), action creators, and selectors. These are all similar to Redux's design.
This replicator is a reimplementation of the OrbitDB replicator. Welo nodes join a shared pubsub channel unique per database. When nodes see peers join the shared channel, nodes attempt to join a direct channel to advertise database updates.
Unlike OrbitDB, the replicator has a specification, and replication tests are not flaky.
Unfortunately, a Zzzync replicator was not added. Building one will take more time than expected to do right. In this case to do right means the result is: relatively efficient/fast and general purpose (can be used apart from web3storage).
The proposal identified this as the most difficult part of the grant.
It's still possible to have a naive/experimental Zzzync replicator fairly quickly. However, I didn't see this as worth it and am looking at designing a system for use long-term.
I did inquire about this with Irakli from web3storage, who always has some good information.
Validating the schema at the IPLD layer will likely be part of hardening the implementation in the nearer future.
The release used is similar to js-libp2p's pipeline. It creates a changelog inside a PR; after it's merged, the workflow cuts a new Github release and publishes it to npm. A changelog is generated and the version is bumped by looking at the Conventional Commits in the commit messages.
The API docs have been automated. They look nice but can be improved in the future. JSDoc is parsed by the tool to add useful information. The Typescript types are used to show parameters.
- https://github.com/hldb/welo/commit/97a7f072ee51a8be1b446c2c6b70c822ae8c4b87
- hldb/welo#34
- https://github.com/hldb/welo/commit/b8c9b2a707a4825044c3f8fdd5757fdb05a5d7a6
See Zzzync Replicator integration
95% coverage according to codecov.io
There are more than a few testing-related commits; so I won't link them all. Feel free to check out the tests. I plan on organizing them a bit more in the future.
This work had to do with cleaning up code before adding new stuff.
Created Typescript interfaces for the different manifest modules.
Fixed the module registry where modules referenced by the manifest are registered.
- https://github.com/hldb/welo/commit/567646d872a09695544160b4666e566149f6b72
- https://github.com/hldb/welo/commit/e92a7410ec37c37c346c82ed0294b2c71db5241
Libp2p's startable interface is a Typescript interface for managing the lifecycle of objects. To make things easier when working with async start/stop I made Playable that classes inside the project use.
- https://github.com/hldb/welo/commit/c9ec979387ae51c0ab14917f85212f0f98a585b
- https://github.com/hldb/welo/commit/1e88f90b4dcd56d749cab9e9a49895b73e5a168
- https://github.com/hldb/welo/commit/397009d5f604e2d3fd02e769982b5ae7b8e10c1
- https://github.com/hldb/welo/commit/7dd3ff883fce2ffd9b937ed062f39ead6f54eb1
- 65d549aca0967331aac2952172b73b63f5861801
- hldb/welo#12
- https://github.com/hldb/welo/commit/a9958dae8d105ca39f666487ee99bcb7cfee621f
- https://github.com/hldb/welo/commit/8bcbd35b8a935edffa13a9e540bd8554d3015255
- https://github.com/hldb/welo/commit/bcc880d197990688491b0bb6ecbb5ec4ffe135f8
- hldb/welo#20
- hldb/welo#21
- hldb/welo#22
- hldb/welo#23
- hldb/welo#24
- hldb/welo#25
- hldb/welo#26
- hldb/welo#27
- hldb/welo#31
This is not complete yet. It is part of Still Ongoing. Benchmarks will be added for read/write/replication, and metrics will be tracked over time with github-action-benchmark.
- https://github.com/hldb/welo/commit/b8c9b2a707a4825044c3f8fdd5757fdb05a5d7a6
- https://github.com/hldb/welo/commit/97a7f072ee51a8be1b446c2c6b70c822ae8c4b87
See Automated Release: ci, change log, and api docs for more detail
The live replicator was unfinished at the time; as a result, an alpha was never released.
See Zzzync Replicator integration
I'll be looking at doing the heavier testing with tools like Testground around the same time as performance and hardening. I did not quite reach this step during the grant.
Decided to use api-documenter instead of Typedoc because it had much nicer-looking generated markdown.
See Automated Release: ci, change log, and api docs for more detail
Welo has not been tested with browsers yet. Support is tracked in browser tests issue.
The 1.0.0 release was prematurely cut while trying out different release pipelines.
Latest release is now v1.0.2
The original plan was to turn the project into Typescript toward the end of the grant. However, Steve, my partner on Cypsela, recommended I use Typescript immediately.
Thanks Steve
It helped a bunch and likely sped up development pretty considerably.
Welo, pronounced "way-low", is now a working peer-to-peer database written in Typescript. It's very similar to OrbitDB but does not need to load all entries into memory before opening a database (which can take multiple seconds; IIRC 2 seconds for every 1000 entries). Because Welo write replicas and store indexes to disk, databases do not need to load all entries into memory; exposing read and write immediately regardless of database size. It will be easy, starting from here, to lazily load as much of the database into memory as the user sees fit.
Publishing, testing, API docs, and checking/updating dependencies are now automated. Similar CI/CD actions to the js-libp2p repo test and create releases on push to the master branch.
I created copy-deps
, a package that makes updating shared dependencies easier.
This package comes in handy when upgrading ipfs-core
as it overlaps a handful of dependencies welo
uses.
A specification for the Opalescent database is published.
This is a living specification for version 1.0-beta
and will continue to be updated as things are changed and added.
This section will be updated as items are completed
This section outlines ideas to work on following this grant
After completing what is included in the section above, I plan to look at designing an IO-efficient replica structure in IPLD. Intuitively this also seems relevant to Zzzync replicators.
Testing, performance, and hardening the implementation will be the main focuses afterward, in that order. I'd also like to learn Typescript a bit better. I know general use right now but more advanced knowledge will enable me to write even cleaner code that requires less testing.
The protocol is in a good state for now, but look forward to adding a low-latency replication protocol after Zzzync.
Will explore these path options more in a follow-up grant proposal.
This was my first solo grant project. The admins managing the grant procedure and communication were great. It's always been a pleasure when interacting with anyone from the Protocol Labs umbrella.
There are some areas I can improve, like tracking progress and creating deliverables/roadmaps. Hopefully, these will get easier to judge.
I would like to see how transparent/auditable I can make grant work progress in the future by linking directly to issues/prs.
Zzzync is being added back with a demo web app to close out the grant. This list will link directly to the relevant issues for better transparency.
- Development Roadmap
ETA: June 17th
Grant budget is still capped at 30K
This amendment will count as the second two milestones, with the first two marked as complete.