A deep dive into Hivemind's design

I am studying the Hivemind codebase at a much deeper level these days, in preparation for when I start writing code for the Native Ads project. I figured I would share what I am learning and related thoughts through a series of blog posts. What better way to deepen and expand on what you are learning is there than to try and explain it to other people, right?

So, this is the first post in the series and I just want to share a basic overview of what I have learned about Hivemind's purpose. Subsequent posts in this series will focus on more particular aspects of design and will be more technically detailed.

A layer 2 scaling solution

You've probably heard of Layer 2 scaling as it refers to Bitcoin's scaling issues: the Lightning Network, to be specific. Well, Hivemind is not the same as the Lightning Network, but the two share a similar aim: SCALING.

Hivemind's design reorganizes the Steem blockchain's data in a way that makes retrieval and querying more efficient. By keeping a local SQL database that's synchronized with live blockchain data, it essentially maintains blockchain state in a format that is flexible and easy to work with.

Layer 1 is used to maintain consensus and other critical blockchain operations, and Layer 2 is used to expand on that solid base.

So what's possible with Hivemind?

Well, in short, any feature that depends on the data states it maintains:

• Posts and their metadata
• Accounts and their metadata
• Transfers of tokens and associated data
• The relationships between posts, accounts and operations

Hivemind primarily acts as a data retrieval interface. It doesn't handle wallet operations. It scans blockchain data that's already there in the blocks as they are added to the chain, and then it organizes and stores it for quick retrieval.

This makes it a lot more flexible. There are too many possible use cases for Hivemind and possible features to name. One feature is communities, which I touch on below. Another feature I recently came up with is a Native Ads system that's built around the communities feature. There are links to related documentation at the bottom of this post.

Communities!

Communities are one of the features made possible by this improved data architecture. In a nutshell, any Steem account will be able to create a "community account" that can represent a community in the real world, or a particular type of content. A "Topic" community type best fits this category. It allows anyone to post and comment, pretty much like how Steemit.com looks right now.

There can also be a "Journal" community, where you share a certain type of content and the people who subscribe (guests) can only comment.

All these options provide a more organized way to hold public discussions and share content. What this also creates is a foundation for other related features, because once there is a good user experience on the social network, people will want to do more.

Interactive polls are one feature I am thinking a lot about. I am working on some design specifications that will also be used in Native Ads (placing an ad as a poll in a community). Having this poll feature as a core part of the community experience will have to come first before they can be used in ads.

Other ideas revolve around user experience, like reactions; but there are a lot more features that you can implement through Hivemind.

Thanks for reading! I'll share more specific insights into how Hivemind is designed in my next posts in this series.

---

---

I am working on a new feature called Native Ads, that may be added to Hivemind Communities in a future update.

For an overview of the Native Ads feature and how it will work, read this doc.

If you would like to take a look at the code, visit the GitHub repo.