Blockchain as a Backend Part Two: Lateral Forking Following Content Types, Agnostic Rewards
This is a very simple diagram of the Steem ecosystem, as I understand it now. I will try to give a brief description of all of the elements on this diagram.
Steemit.com, eSteem and Busy.org are all "first rang contributors and consumers" for the data in the Steem blockchain. They interact either directly, through proprietary libraries (Steemit.com) or indirectly, using Python or JavaScript libraries (eSteem, Busy.org).
The contributions they make to the blockchain are formalized into blog posts, comments and votes. For these operations, they are rewarded according to the parameters of the economic system, established and enforced by witnesses (inflation rate, rewards pool allocation, etc). The governance process is fundamental to the blockchain, hence is a monolithic component of it . Financial transactions and content transactions, on the other hand, can be seen like plugins. In the sense that they are both performing atomic data operations on the blockchain, with different types of inputs and outputs.
But along Steemit.com, eSteem and Busy.org, there are many other apps which could benefit from the Steem ecosystem. These are what I call "second rang contributors".
For instance, ZenTasktic, a real-time, collaborative task management app coded by yours truly, could benefit from the social layer already existing and could foster content creation. I already integrated a posting feature from ZenTasktic (you can see it here and read more about the technical details here) which basically lets a ZenTasktic user share what is he doing with his followers on Steemit. The nature of the ZenTaskstic app, which is built on top of a productivity framework called Assess-Decide-Do, makes the sharing process necessary in the assessment stage (for more details, read the articles on the @zentasktic account). Given the hard-coded nature of the blog posts and comments, storing todos directly in the blockchain wouldn't be effective, because it will collide with other types of content. Using Steem custom_json operation type we can devise a minimum workflow, but I won't hold my breath. The data layer should be more formalized, allowing for discrete indices, etc (it gets too technical for this article).
A task management app wouldn't be the only candidate for a blockchain based ecosystem like steemit. Running apps (apps that measure running our outdoors activities) could also benefit, by storing their geolocation attributes, along with some metadata in the blockchain. The social in this type of activities is very strong, believe me, I know that. The statistics generated by the public geolocation data could also bring in more value.
Pushing things even further, a leaderboard server for games could also be integrated. In order to participate, a game should only register with this leaderboard service on the blockchain (much like iOS developers were doing with the defunct now Game Center of Apple). From that point, all they have to do is to send information about the specific level, points, etc. The conversion should be done internally. by the game.
But as Steemit is designed right now, these apps can only be "second rang contributors". The only relevant content they can store in the blockchain is in the form of a blog post. "I wonder if I should do this task, I need feedback" (ZenTaskstic), "Hey, I just ran 10k, check out my map" (every running app can do this, from Strava to Runkeeper) or "I just bought 10 more acres of land in Farmville (who plays Farmville anymore, anyway?)" (any conceivable mobile or desktop game).
I think there is a better way. Some of the hints in the Steemit roadmap are pointing in this direction too.
Lateral Forking Following Content Types
By this syntagm I understand: "creation of various sidechains on top - or around - the main Steem blockchain, which will hold specific content types: tasks, geolocation info, leaderboards".
As you can see, from "second rang contributors" the external apps can have their own sub-ecosystem. That means they will not contribute only blog-like content, clogging and diluting the main Steemit feed, but they will also give other types of content for consumption. People will check their tasks from the blockchain and they can get paid within the same app, in Steem. Gamers will check their own specific points and levels (game related coins?) from within the game and get paid by the same game, in Steem. Runners will store their geolocation data and metadata in a sidechain, and may start challenges (like the ones in Strava) in which they may get Steem.
Agnostic Rewards
Right now, Steem, the currency, is only measuring one type of activity: attention. Imagine a currency which could only measure carrots. I have this thing which is worth $0.17, but I can only buy carrots with it.
Huh?
The power of a currency is made by its fungibility. The more ubiquitous it is, the more valuable.
Ideally, Steem should be an agnostic type of reward, not tied to a single point of value.
You may get Steem for writing blog posts, for commenting on them, OR for finishing tasks, for running marathons or for completing levels in a game (or in a gamified company structure, why not?).
Somebody must pay for this, at some point. Inflation alone can't sustain this growth. And it wouldn't be healthy either, IMHO. But this content-type driven segmentation will attract far more advertisers than just simple blogging. Sport equipments companies may sponsor running challenges. Groups using the task management feature will provide liquidity by transferring their assets on the Steem blockchain, in order to pay their counterparts.
I'm not saying this is a fool-proof mechanism. I'm not saying this may happen tomorrow. But this paragraph in the roadmap made me think it's doable:
The new architecture is a fabric consisting of multiple blockchains, one of which handles each distinct feature provided by the platform. The state of each entity within the blockchain can then be moved between blockchains with small synchronization delay (on the order of 30 seconds). This allows all of the blockchains in the fabric to use the same design set of witness nodes to produce blocks, STEEM and Steem Dollar tokens, user account identities, etc.
If any of you would like to comment, criticize or give suggestions, please do so. We're all in this together.
P.S. I would be really curious to know what @dan or @ned are thinking about this. But it's just a curiosity. :)
I'm a serial entrepreneur, blogger and ultrarunner. You can find me mainly on my blog at Dragos Roua where I write about productivity, business, relationships and running. Here on Steemit you may stay updated by following me @dragosroua.
https://steemit.com/~witnesses
Great write!
I guess I will add another category to my collection - Steem blockchain explained :)
What about golos? How does golos fit into your diagram?
And any future spinoffs ... ?
Golos is an almost identical clone of Steemit, just a copy / paste, the main differentiator being the language. There are a few economical differencies but not much. As I understand, they're still on the hyper-inflationist model Steemit had until hardfork 16, but they're working towards implementing the new one too.
Golos could use the publishing side chain, just like Steemit, in the new architecture.
That's what I assumed - sidechain instead of clone.
What about independence from the main chain? Is the sidechain independent? Or is it just piggybacking on the main chain? With independence you gain freedom of act and choice. And take on the burden of administration :)
Where do sidechains store data? Sorry if I overlooked this one ...
The sidechains will process - in my approach - only specific data. For instance, in the case of the publishing sidechain, it will be responsible only for articles and blog posts. So that's what it will store, with a reference to the owner account.
Account management and rewards processing should be done on the main blockchain to preserve the monolithic aspect of the operations.
Please be aware that this is just my own view of how things should be, after just a few months of studying the processes here, and with a minimal knowledge of the code base. The creators of Steem/Steemit know much better than me if this will work out or not, what I wrote is just a bunch of suggestions. They may, or may not function in the current setup.
Of course, there can be various and different approaches.
So, specific sidechain data would be stored in the json-metadata field?
And sidechain logic would search, filter and act on this specific data? And create / modify it, of course.
Because ... you wouldn't want and won't be allowed to change the block / transaction structure itself.
For example - #steemgnome coordinates :)
@dragosroua
OK, add-on data fields and logic upon them. I got it, TNX.
Back to real work now :) Write you ...
Nope, the json metadata field will be just for metadata and it will remain as it is.
Each sidechain should host only data type specific operations. Right now you have in the main blockchain operations for posting a specific article, a comment, for retrieving comments and tags, etc. These should be transferred in the sidechain completely, and the sidechain should only sync with the main blockchain a specific data type:
{id:unique_id, data_type: publishing, account: acct_id}. Or something like that.The task management sidechain should have native functions for adding tasks, projects, retrieving tasks and projects based on various metadata (due date, context, etc) and it should synchronize with the main blockchain, again, just a specific data type:
{id:unique_id, data_type: task_management, account: acct_id}.The account management and rewards processing should be somehow centralized (although I don't like the word, it just means they shouldn't be part of the sidechains to avoid bloating).
Just wanted to point that Steemit is webapp, Steem is blockchain/distributed database. Somewhere you said Steemit blockchain, I think this needs to be fixed. Nice write up, brother... I have finished up similar article but more general one for web developers :))
Yes, I know the difference, I will look over and fix it. Thanks for the nice words and looking forward to your article. More ideas, better outcomes :)
BTW, the source code for eSteem really helped me to integrate ZenTasktic, I spent like 4 hours yesterday to understand a glitch, then I looked how you do it with eSteem and it suddenly worked. Thank you! :
That's great, glad that it was helpful! :)
This is an excellent article, Dragos, I'm sorry I've discovering it so late !
Ah, it's Sorin by the way, didn't notice I was posting from the witness account !