district0x Dev Update - August 6th, 2019

Development progress and product changes from district0x

The network of district0x service providers is rallying around a series of changes to Meme Factory, key new additions to the District Registry in preparation for audits, and steady progress with Ethlance. As we’re entering our QA sprint and begin extensive testing on some of these changes, we have a bit less to share today than usual. However, if all goes according to plan, Meme Factory should receive a fresh mainnet deployment by next Monday, with rather significant changes described below. We’ll be sure to detail the exact changelog next time.

Meme Factory

Meme Factory has received a host of changes, some of which will directly impact the average DANK holders ability to govern the website. These are, of course, the parameter change pages. While these were feature complete and nearly deployed to our QA instance last time, we encountered a slew of hard-to-debug issues as typical failure paths we saw locally while running ganache ended up with completely incongruent counterparts when utilizing parity. With those issues troubleshot and cleared out of the way, the team is now testing these new features.

Similarly, last time we discussed the potential for supporting new formats, in particular supporting .gifv and .mp4, with complementary auto-play features. This has now been deployed to QA, and is actively being tested. By next week, we expect to support these on the mainnet instance, giving meme creators more flexibility, particularly when producing animated images with many frames, all while maintaining sizes under 1.5MB.

Among other changes include an addition of some email notifications, in particular a highly requested notification to reveal your vote when the voting period begins. This will hopefully assist voting users in remembering to return to reveal their votes for a given challenge.

Additionally, we’ve been testing and working on a feature that will allow users to backup and import vote secrets. This isn’t the most intuitive feature at first, but understanding that the secrets to reveal a vote after its made are stored in the browser that placed the vote means that vote cannot be revealed from another device. With this new backup and import feature, you can easily take your vote secrets from one machine and reveal them on another later.

Finally, after some in-depth investigation with the community, we’ve discovered what is a pretty deeply embedded bug with the vote counting mechanism that, when encountered, can cause the total vote count and registry state for a particular challenge to read incorrectly in the client, despite all of the information on the blockchain being read correctly. The explanation for how this happens is quite involved, but to simplify, the way we were previously watching for vote/reveal events on our server resulted in returns of “null” values for vote counts on unrevealed votes.

In the end, this produced weird results in the app where the total votes on a particular challenge might not include unrevealed votes, and could even incorrectly assign the DANK/STANK status (again, only in the application’s view, all data is still correctly making it on chain). We’ve pushed what we think is a comprehensive fix to this issue, and we’re in the middle of testing on QA. If all goes well, we should be able to fix this not only for all future votes, but should be able to correct any historical mistakes with a simple database resync post-fix.

District Registry

Most of the District Registry’s progress in the past two weeks has been isolated to the backend. In particular, we had some trouble migrating the newest changes from our local setup to the QA instance. As we also mentioned in our previous update, we encountered issues with our test suite written in Truffle, and instead have had to default back to clojurescript for tests. We’ve spent the past cycle converting those over and getting them firmly in place.

Alongside this, much of the work currently being done on the District Registry is actually a carbon copy of what’s been done on Meme Factory. Just like Meme Factory, the registry also needs the parameter change ability, and so we’ve been laying the groundwork for those pages and migrations based off what we’ve learned from Meme Factory’s struggles.

Similarly, email notifications are also needed for registry events on the District Registry just as they are for the DANK registry on Meme Factory. These have been added and are currently being tested alongside the rest.

Finally, after our initial round of testing on the District Registry, we’ve found that our initial specifications left out a relatively important piece of information for users in the form of a “staking history” chart. While we do display the particular staking curve a district is obeying currently, what we need alongside that is a chart that shows a complete history of stakes/unstakes for a given district in the registry. This will inform not just the expected vote payout, but also give users some idea of actual user interactions with a given district over time.

In total, the past two weeks have contained a solid combination of important bug fixes, updated features, and completely new development towards our two upcoming applications. As we settle into our second testing cycle since adopting our new sprint methodology, the team is beginning to hit strides in parallel development, we’ve not yet seen, as exemplified by shared work between the District Registry and Meme Factory. We intend to make this a lasting trend as we work to crush our remaining roadmap items.