district0x Dev Update - January 22nd, 2019

Development progress and product changes from district0x

The first complete development cycle of 2019 has concluded, and with it comes many key updates for the district0x team. Meme Factory marches ever closer to a full mainnet launch, Ethlance gets the beginnings of its GraphQL resolvers built, the District Registry finally has had its contracts cut down to appropriate size, and all throughout the previous week we’ve been completing migrations across our old applications to our new devops suite. This brought some unexpected downtime to a few of our dApps, and a few unexpected bugs to tackle as well!

Meme Factory

Meme Factory continues to be the primary focus for district0x service providers, and several different lines of work are underway. Several engineers tinker away at every small bug and styling nit that can be found. As the rest of the operations staff contributors begin beta testing, we’ll discover and implement fixes and new user flows where necessary. It’s important to us that anyone with a web3 wallet and some Ether for gas can easily use our newest product.

Additional work has been done on the data generator for Meme Factory as well, mostly amounting to the way we ingest data from IPFS. We’ve built a blacklist filtering mechanism, as well improved error logging and messaging from IPFS (previously we only had one!). Through a new caching mechanism, we were able to drastically improve load times for the web app while still calling out to IPFS as a redundancy.

Work has also continued on the DANK faucet, for which we are debugging its own set of deployment issues. A bug was discovered where we were overwriting configurations on the server unintentionally, and when this was resolved, we faced a new set of errors to battle with the combination of MetaMask and Ganache. Moving forward with these issues quashed, there is a “spinner” UI component for the faucet that will be completed next.

District Registry

The District Registry has been on a several-cycle-long mission to split apart our contracts in order to get them within the the hard size limitations required by the EVM. This was an unexpectedly difficult task, requiring a nearly unintuitive level of subdivision of backend functionality (for instance, JUST the power curves for the staking mechanism alone had to be spun off into their own contract) in order to make ends meet.

Thankfully, we’re happy to say that we’ve now got this done, and are dealing with the various externalities that come from this design pattern. Namely, we need to simplify and implement a permissions scheme to appropriately allow interactions like anonymous token transfers between the fragmented smart contracts. As this work wraps up, we will begin the process of acquiring one or several security audits.

Ethlance

As mentioned above, service providers working on Ethlance have been focused on building GraphQL resolvers for the district’s rework. This has included a few training sessions on how we currently use GraphQL across the other projects in our repository. Borrowing from that architecture, we’ve produced our first draft of resolvers and are working on hooking them in with the inclusion of additional pagination to what we’ve already produced of the backend.

In the introduction we mentioned some issues we encountered throughout our application suite as we migrated live applications to a new devops architecture. Though we believe we’ve rooted these out and are currently working on fixes it’s still possible that some subtle features of our dApps (in particular Name Bazaar, being the most complex) have broken and gone unnoticed. Please be on the lookout for anything that seems out of place. For any issues you do encounter, you can always join our Discord for quick help or send us an email for more involved issues