Step-by-step guide on making David’s job obsolete

I am not talking about my job, I am talking about the founder and CEO of HackerNoon David Smooke’s.

The writer-editor loop can be explained in two steps: 1. Writers submit or edit their story 2. Editors return a story for additional editingThese two steps are repeated until the story is up to standard and ready to be published.

The best way that David’s job can be made obsolete is to automate the tedious parts of the syndication process and give more incentives to editors and writers. I‘ll try to create a step by step guide how could this be achieved while keeping in mind a few pointers of the bigger Hacker Noon 2.0 vision.

The Vision of Hacker Noon 2.0 taken from Hacker Noon startengine campaign.

HackerNoon started a crowdfunding campaign, and it explains that HackerNoon will be free to read forever without tracking the users or forcing them to log in. Moreover, HackerNoon will not run intrusive ads and considering all that, it’s easy to see why it would be a perfect place for anyone to read up on the latest tech-related stories.

Without further ado, let me walk you through a possible solution that could automate the syndication process and allows us to keep all wonderful aspects of this great publication. Let’s nerd out.

Smart contracts as a writer-editor loop solution

The writer-editor loop problem could be solved by having a transparent CMS which enforces the same rules for each participant. One way to implement this kind of a solution would be by using smart contracts.

For those who haven’t been reading Hacker Noon articles very thoroughly a smart contract is a computer protocol intended to digitally facilitate, verify and enforce the negotiation or performance of a contract without third parties. This technology allows us to have traceable and irreversible interactions between writers and editors because we will use transactions on the blockchain to implement them. Interactions such as submitting, publishing, editing or versioning a story will all be represented as a transaction in the blockchain. Subsequently, all this data will be immutable and forever stored inside the blockchain. By using this technology the writer is no more condemned to either blindly trust the closed system or to write countless emails just to get the response where the story got stuck. By using smart contracts the writer can now as an equal in the system see all interactions that have happened with his story and in real time see it’s progress. Moreover, anyone regardless of being a member of this system can see what has happened with our writer’s story. The same goes for any story and any writer/editor interaction.

Observability, verifiability, and enforceability are important properties of smart contracts which are gained by design (check out this article by Taylor Pearson).

Observability means the ability for the stakeholders to see the state of the system. In our case, that means that all stakeholders get to see all writer-editor interactions that make up our system.

Verifiability is having the means to verify whether or not something truly happened. This would be the verification of an interaction inside of our system.

Last but not least, enforceability means having the contract enforced in the same way for all stakeholders. For HackerNoon 2.0, all writers and all editors comply with the same rules as stated in the smart contract and participate in the exact same process. These key smart contract properties are the ones that enable us to have a fully transparent system.

To implement such a system, in my example I have used Ethereum smart contracts. However, only using that technology would not suffice, because we have a high transaction rate and each transaction carries a lot of data. For those reasons using only Ethereum smart contract to implement HackerNoon 2.0 would result in a slow and expensive system. Using Gas Limit, minimal transaction cost and average block time we get a maximum of 28 transactions per second, which is way below what we need. (Data gathered from ethstats.)

To solve this implementation problem I’ ve transferred the smart contracts to a Layer 2 solution: Loom Network. Any scaling mechanism that isn’t programmed into the Ethereum protocol is called a Layer 2 solution. Loom network is one of many such solutions out there and I’ve chosen it because it relies on smart contracts and allows it’s clients to create a more centralized and localized Ethereum chain that has a higher transaction rate than the original. We call these centralized and localized Ethereum chains sidechains. By sacrificing the total decentralization of the system we are in fact gaining the speed of transaction fulfillment. Everything else in the system stays the same — including all the before mentioned positive aspects of smart contracts. Even the used programming language frameworks stay the same.

Creating a sample solution using Loom Network

Loom Network is a Layer 2 scaling solution for Ethereum that is ready for use in the production environment. You can use it to build highly scalable applications and games while still using all the positive aspects of smart contracts.

So let’s write a smart contract that will implement an interaction: writer submitting a story.

Implementation of writer submitting a story. link to the gist

The code above is a simple implementation of such interaction written in solidity. Every Hacker Noon story must have a title, content and the author. This data is represented in a struct called Story and stored in an array called stories. In addition, we have defined a function for submitting stories (submitStory) which basically creates, saves the submitted story and is followed by an emission of an event (StoryAdded). Anyone who is subscribed to this event via WebSocket protocol will be informed of this change in the system. Contract events are important for solving our writer-editor problem because they provide a channel for notifying editors that a new story has been submitted for review.

For additional info about Loom Network, you can check out their homepage or this article.

For anyone wishing to run this simple example here is the link to the repo. The code contains a simple HTML form which can be used to simulate submitting and publishing a story. With that being said, I do not recommend the new site to look like that. 😄

Indexing Layer

Indexing can be thought as a way of organizing data according to a specific schema or plan for the purpose of streamlining data retrieval. In this solution, we can use it to store data from the blockchain into a database that is even more performant and optimized for information retrieval. This way we can query that database opposed to retrieving the data from the blockchain.

A good example of such usage is Loom Network’s website DelegateCall. They even have an awesome blog post explaining it in detail.

The number one go-to solution for implementing this is the Elasticsearch.Easy enough, we can pipe the events emitted from the contract to the Elasticsearch instance, as written in the following code.

With such implementation, you get a fully functional search updated every time a story is published to HackerNoon 2.0’s CMS.

Tokens as rewards

David and his team mentioned that they would introduce tokens to the system like this for the purpose of rewarding writers and publishers for their devoted work. The proposed solution has the ability to create ERC-20 and ERC-721 tokens directly to the Ethereum main-chain. What this essentially means is that you can fully automate the token creation as well as their distribution. Tokens can be distributed by sidechain smart contracts and upon triggering a defined action in the system. As this is not a fully implemented solution, my example does not contain code for that, but be sure to check out some of these articles:

Conclusion

To sum it up, our new system consists of a CMS connected to the Loom.js sidechain. Every interaction that happens in the CMS gets written in the sidechain and passed to the indexer via emitted events. The indexer makes sure that everything is stored in Elasticsearch and that data is displayed to the user via the new website. The diagram below shows a bird-eye view of the elements within the system and the users that interact with them.

The overall architecture of the system

HackerNoon is taking its first steps to creating a fascinating solution, both for its stakeholders and for technology nerds. I definitely believe that it’s going to be a game changer in the tech media field and I can’t wait to see HackerNoon 2.0 MVP. I hope you have enjoyed this small glimpse into a possible implementation of such a system. If you think there is an even better approach, be sure to let me know, I would like to hear the thoughts of fellow HackerNoon enthusiasts.