district0x Dev Update - July 10th, 2018

Development progress and product changes from district0x

The past two weeks have flown by as the team keeps busy with the many initiatives discussed in the last few updates. By and large, most discernible progress continues with Meme Factory and it’s various pages, while other projects such as the District Registry have larger backend features being scaffolded. We’ve conducted a ton of research in regards to the planned changes for Ethlance and the complementary user identity systems mentioned previously, and are now committing to the finer details for the future after Meme Factory.

We have hired an additional two engineers to help get us there, but we are still in need of experienced, curious thinkers capable of researching and designing novel cryptoeconomic systems for future districts and modules. If you think you’ve got what it takes, shoot us a line at talent@district0x.io.

Meme Factory Updates

As in our last update, the bulk of development work has gone into completion of the functional components as well as the styling for the many pages of Meme Factory. Specifically, the Meme lists page and styling is complete, the Memefolio and the Meme Details pages are nearly complete as well. The challenge and voting flows have been crafted, and functional work has finished with completion of the reveal vote and reward collection buttons. These also move onward towards styling.

The most significant piece of functional code completed was the Meme Submission form. This submission portal allows Meme Creators to submit their designs, along with a name and description and propose it for sale (including the starting price and number sold). A simple interface by the typical web-app’s standards, the upload process for Meme Factory borrows the same simple design cues, including a custom built drag-drop modules, but hides so much more under the hood.

When a user submits an image and description to the Dank Registry, first the image is uploaded to IPFS, returning a hash. That image hash is then combined with the Meme proposal’s metadata (name, description, number for issue, etc.) into a formatted JSON string, which gets uploaded again into IPFS. This returns another hash value. That second hash value, containing the image hash and the metadata of the proposed meme and its sale, gets sent to the Dank Registry contracts, storing it on chain.

When our server receives the event that a new entry has been created, it retrieves the hash value, from which it gleans all of the meme’s metadata as well as the image from IPFS, and creates a record in our database. From there, our server can display content to users browsing the site in real time. Utilizing this structure allows us to maintain the level of availability modern app users are accustomed to whilst the data and all of its components can be securely stored in a completely decentralized and immutable way.

d0xINFRA Updates

Current development efforts not directly related to Meme Factory come in two forms. The first was mentioned in the previous update — the District Registry. Thus far, the work completed has mostly involved ramping up smart contracts based on previous design patterns using TCRFactory and the Dank Meme Registry. However, we also have our first working implementation of the Simple Staking Interface, and we are now ironing out the kinks in any unforeseen design issues — mostly involving concurrency of votes, challenges, and staking.

The second effort is still in the formative phases. In order to better support our future visions for Ethlance, we are constructing some semblance of global, network-wide user accounts that will serve all districts. In preparation for this, we’ve been researching ERC 725 and it’s various implementations, and are plotting ways in which we can roll our own instance utilizing Clojure and the other flavors unique to our tech stack.

What’s Next?

With the acceptance of two more offers for engineers, our development team has grown from just four at the end of May to what will be eight by the end of August. With each new hire, not only do we require time to get up to speed on the broader technologies in use (in and of itself quite a demanding bar), but also require that they familiarize themselves with everything we’ve already built (or at least everything relevant to their job — which for current hires means learning most of what we’ve built).

Part of our long term vision has always involved fostering a self-sustaining developer network around our platform. In order to do so, it’s crucial that we streamline the process of discovering and imbibing development patterns so that anyone from any demographic or walk of life can pick up where our collective efforts have left off. As our newest hires fight to find understanding in our codebase, we will take every opportunity to author tutorials and demonstrations, in the end lowering the bar for others to utilize our platform.