Since reading the last winter update post from Steemit, Inc. here and the newest update, I’ve been researching the Smart Media Token (SMT). I’ve tried reading the whitepaper, but it’s a hard read because it’s full of technical jargon. Searching the information across Steemit and Google has proven to be quite arduous. Most of the articles are just touching the surface of what SMT is without any in-depth explanation. I’ve compiled this post with that little knowledge and information that I’ve gathered, so please be kind to me if I make any mistakes, especially the technical ones.

Here are my opinions about the things that will make SMT a failed project. It’s not that I expect SMT to fail. Quite the opposite, I expect SMT to be a success. I’m trying to point out the problems SMT will face beforehand. So, here it goes.

Problem 1: Technical Barrier for Content Publishers

Use cases from SMT whitepaper: 1 - Content Publishers 2. Forums 3. Comment Widgets 4. Sub-Community Moderators and Managers

The majority of content publishers are not technical people. Some of them have the funds to hire technical people, but the majority of them are people relying on the plug-and-play of modern CMS, such as Wordpress, Drupal, Joomla, PhpBB, SMF, etc. They would expect a simple usage of filling in simple forms and doing several clicks. Especially with the word “widget,” most content publishers would expect just to upload it and done, collect money.

The fourth use case for moderators/admins would be a harder case. We can’t expect mods or admins in specific groups/forums to spend money to hire tech people to implement SMT. Later on when SMT has gained popularity, we can expect this, but for starters, I don’t think it’s doable.

Modern CMS are mostly several clicks away for them. If SMT implementation is hard, then it won’t have enough motivating power to ask content publishers to try it. It’s a hassle to move to a new platform, and they will be afraid of losing their subscriber base along with the move. The difficulty of a new income stream might not motivate them enough.

Solution 1: Common SMT template

As stated on the whitepaper, having an already attached database layer is great. However, I think Steemit, Inc. needs to move one step further to create a simple SMT template. Small content publishers could just enter less than ten parameters, and done! The pricing could be pegged to USD, SBD, or even share the usage of SBD altogether. If that is technically doable (not sure if it’s viable to do or not, I’m not a techie myself), this would surely help SMT adaptation. The main point is, make it as simple as possible for non techies, then SMT will have major absorption.

Problem 2: Spam and bandwidth problem

I’m reading from the whitepaper that all SMT will use the Steem blockchain and thus use Steem bandwidth.

Bandwidth Sharing with SMTs Based on Reserve Liquidity Pools… SMTs can run while only having STEEM running in the background to calculate the necessary bandwidth for transaction costs.

This article about bandwidth from one of our witness, @drakos, explained that there is basically very little a normal user can do to avoid this bandwidth problem. Of course this can cause a big problem.

Don’t forget to vote for our awesome witnesses. I myself voted for witnesses behind the Minnow Support Project. You can find the witness list here, scroll down to witness section.

Because of its closed community feel, there are a lot of content publishers who are (very) satisfied with “very nice, good post” comments. The “you suck” comments are dreadful for them, and they will likely welcome any “very good” comments anytime. These comments are often frowned upon and discouraged on Steemit. However, many content publishers will just be okay with or even expect to hear this.

Spam-wise, these comments would not bother Steemit because those comments would happen on the publisher websites. However, all of these small comments would be counted as transactions and would take up bandwidth. And this will affect Steemit as a whole, and especially witnesses who maintain the bandwidth.

There can be no, “it’s peak time, wait a little bit and you can use the platform” reply. Content publishers will likely post at peak time, ensuring the best reaction and monetary gains. And SMT is an alternative income from the publisher point of view. If SMT is “down” because of bandwidth, the content publishers can’t get the upvote (read=money), then they will go back to ordinary income streams such as Google Adsense. Being “down” means no income. It’s better to have little income then none. Makes sense, right?

Thus in short the problem would look like this:
Content publisher uses SMT --> content publisher purposely publishes at peak time --> the users vote with “good post” comments --> bandwidths are taken, a lot --> Steem bandwidth down --> users can’t vote --> content publishers annoyed --> content publishers “uninstall” SMT.

Solution 2: Steem developers and witness cooperation

As these bandwidth and spam-related problems are on a such a higher level, Steemit, Inc. (@ned), the developers (@pkattera & @sneak, and others that I don’t know of), and witnesses should sit down and discuss how to safely approach and solve this. The idea behind SMT is great, but if the execution is poor, then it won’t launch to such a great height.

I have high expectation for SMT. I hope that it could be as easy as possible to have my own SMT. Cheers up!

---

Don’t forget to follow and vote @lenadr. She proofread this article, and she makes awesome posts.

images source: 1 , 2 , 3

---

If this blog post has entertained or helped you, please follow, upvote, resteem and/or consider buying me beers :

BTC

ETH

LTC

DOGE

XMR

 

 

 

BTC : 1HqYTjRdZvss32vDrp1T8gRAXTgdqfZ6VS
ETH : 0x1fc22bC528ceE3DaA39555269b70e287dda9aE3E
LTC : LdEiGzjcG36EoZoezDu6rZmdwVcSJHazfr
DOGE : DMYx1w5Sr4uoMnNWymn5nMpCuySSr178TA
XMR : 46QngrRwYgAbQJzW2ZJZ8HEuirkUW2bw84ajWhk73DLG8iT9NqgfzSU4ddRZbeAaLgFeL6gAxzVtGZPHJhFmCDXF3ZEwimT