Recently I was approached with the question if I would consider to support the APPICS team to build out the APPICS community in my own country and local language. Nothing decided on that front yet, but it got me to download, install and register myself on APPICS.

My first impression of the App is GOOD. Yes, with capital letters, since I liked what I saw. Unlike many of the STEEM based services and front-ends, the APPICS team took great efforts to design the user interface. The layout looks good! It works very intuitively. Many of its features are where one would expect it to be.

> What is APPICS? It's very much like Instagram. It allows images and (short) video uploads and one can add text to the media as well. Likes (upvotes) are supported. A comment section is available.

It took me a few hours before I decided to make my first - and till now my only - post at APPICS.

The main reason for my hesitation is the fact APPICS uses the STEEM chain to store the content, ie my post through APPICS ends up in my STEEM blog channel. That in itself is not the issue. The issue I have with using the STEEM chain to store the content, is the fact APPICS posts also triggers my auto voters.

> Note: not sure of APPICS run their own content store and also post to the STEEM chain, or the STEEM chain is the content store.

<center>![](https://online-marketingblog.nl/wp-content/uploads/2014/06/content-curatie.jpg)
<sup>published by Online Marketing Blog ([source](https://online-marketingblog.nl/wp-content/uploads/2014/06/content-curatie.jpg))</sup></center>

In the early days of STEEM, some experiments with Instagram (Steepshot) and Twitter (Zapple) like services took place. I tried all of them, back then. Also these services used the STEEM blockchain to store content. And like APPICS does today, also Steepshot and Zapple ate from the same reward - master chain - reward pool. I thought I voiced my concerns about Steepshot and Zapple using the same reward pool through a post, but I was not able to find one. But, I did find - thanks to [eSteem Search](https://search.esteem.app/) - a few comments regarding this topic. In case you are interested: [one](https://esteem.app/steepshot/@edje/re-cryptoctopus-re-edje-re-cryptoctopus-instagram-like-app-on-steem-testing-steepshot-and-my-early-review-on-the-app-20170519t150058557z) | [two](https://esteem.app/cooperative-agorism/@edje/re-the-ego-is-you-discovering-the-sites-and-apps-that-let-us-explore-the-steem-network-and-give-steem-value-20170721t144504990z).

### Shall service of different nature, use the same Reward Pool?

A question I asked myself the moment the first none-blogging App emerged in the STEEM eco-system.

**It didn't took me a lot of time to reach the conclusion that each service type shall have its own reward pool and shall not be linked to the reward pool designed for another service type.**

> I specifically talk about "service type", instead of "service". A service type is for instance: Article sharing (eg Steempeak, PeakD); Media sharing (eg Instagram, Appics); Short message sharing (eg Twitter). 

Each service type has its own dynamics, it own ways of content creation as well as consumption. Each service type will also has its own way of deciding the value of content. Though you could say: Value can be set regardless of content type, the real value of content is more or less in sync with the effort and cost to create the content. A book is of higher value to the user, than a magazine article. A magazine article is valued more than a news paper article. While a news paper article is valued more than a news paper column. All to do with the time spend to create the content.

### ..back to Auto Voting..

When the auto vote value is low, this may not cause a problem to have APPICS post on the STEEM chain. But when the auto votes are either large in size, or the sum of auto votes to a particular user is large, this creates a problem for the economy around the blockchain. Essentially, long form bloggers taking hours to create a single blog post, may like to see more value from the reward pool going to long form posts, and not so much going to a post with an image with optionally a little bit of text.

In recent weeks I've read a few comments by existing STEEM users and some of the new community witnesses mentioning APPICS - amongst others - in relation to ripping the STEEM reward pool. They have a valid point in my honest opinion. I've seen STEEM users starting to create super quick APPICS posts and receiving 10s of STEEM Dollars each; Much of the rewards as a result of auto voting.

One could say: Auto voters will review their vote follow lists regularly and adjust accordingly. This may be true in theory; In reality, I do wonder if many of the users review their auto voting user lists regularly. I've seen users - with high vote values - auto voting for authors after a user gone 'bad' for months to a year and more. A few times I alerted the auto voter stating she/he was voting continuously for users cutting corners (eg recycling posts from the past, copy/paste from other sources) with the result - in all cases - the reported user was taken from the auto voting list. At all times, the auto voters I approached, reacted with: "Oh Really, I didn't know that! I'll have a look into it."

<center>![](https://i.ytimg.com/vi/hwUbJ7oRsdI/maxresdefault.jpg)
<sup>published by APPICS</sup></center>

### Short term Solution

For the time being, I think I have a simple solution to be able to use APPICS, whilst not 'abusing' my auto voters. I simply create a new account at the STEEM chain and use that one for my APPICS adventures. Just need to figure out how to get a new STEEM account, since all the usual applications supporting the creation of accounts, don't seem to work anymore on the STEEM chain. **Anybody?**

### Thoughts

Let us think about this for our HIVE eco system. We need SMT sooner than later to give a tool to create a unique reward pool for service types and even specific services. We also need to decide if we want to continue distributing HIVE to content creators and curators as we do this today. That said, I would like to see HIVE being distributed to not only developers, but also to curator teams, and other - none technical - activities, even in the case HIVE will not be used to directly rewards content creators and curators (voters).

# <center>What Are Your Thoughts?</center>

<center>a HIVE original</center>

<center><sub>**qsounds music library** with more than 300 entries | [A...K](https://hive.blog/musicdiscovery/@edje/your-bedside-companion-music-and-stories-part-1of2) | [L...Z](https://hive.blog/collection/@edje/your-bedside-companion-music-and-stories-part-2of2) |</sub>
<sup>hive curator for @illuminati-inc @qsounds @c-squared / @c-cubed</sup></center>