Programming Diary #9: Steem + Informatics = Steemformatics

Background

Two weeks ago, in Programming Diary #8, I reported that I had resumed working with Java and Steem, after stalling with the pair a couple of years ago. My eventual goal is a standalone desktop application that can be used by authors and curators for social media activity on the Steem blockchain. My more immediate goal is to develop the skills I'll need to create such a thing. Towards that end, I've started with a toy application that looks like a speedometer. As a play on words, I named it "Steemometer".

In my previous post, I reported two goals for the coming two weeks. They were:

1. Update the "Steemometer" to show the number of posts & votes per block, in addition to overall operations. There are a couple ways I might display these values.
2. Add an option to choose from a list of APIs. (right now, I'm using UPVU's API).

Progress

Despite having limited time to work on the project, my git log shows 31 commits, and I managed to accomplish both of those goals, and more. In summary, the progress can be seen in the screen captures, here:

These captures were taken after running the Steemometer to collect numbers for almost a week.

In the top-left visual, we see counts and averages for all transactions during the time that the program was running. The "per minute" number is calculated by counting the operations (including virtual operations) per block and multiplying by 20 (number of blocks per minute). For example, the total number of operations per minute was reported at 280. This means that block number 79189986 had 280 / 20 = 14 operations, which can be confirmed at SteemDB. I scaled from "per block" to "per minute" in order to avoid displaying fractions when averaging.

Similarly, numbers for votes are found in the bottom-left, comments are found in the top-center, and transfers are found in the bottom-center. The top-right visual shows the available APIs that can be selected (including one that doesn't exist, which is included for testing purposes). Finally, the bottom-right visual shows what it looks like when it loses contact with the API and triggers a failover.

It's not really part of the programming effort, but as long as we have the numbers, here's a table:

Operation	Average Ops / Min	Max Ops / Min
All	297	36500
Comments	8	14020
Transfers	8	13640
Votes	204	14380

Activities

I actually tackled the two goals from above in reverse order. The first thing I did was to add the menu of API hosts and to set it up so that it would automatically switch to a randomly selected alternative if it was using an API that became unreachable. I don't recall where I grabbed the list of APIs, so if there are any that I should add or remove, please let me know. After that logic was set up, I also changed it to select a random API at launch time, too.

With the goal #2 checkbox complete, I moved on to goal #1, adding the options for votes and comments (and I decided to add transfers, too). At first, to accomplish this, I simply reused the variables while filtering for each of those operation types. This meant that I had to set the Steemometer to reset counters to zero when the operation was changed, or else I'd be mixing numbers from different operations types. As long as I wrote the logic to reset counters to zero, I went ahead and added a reset button, too. Additionally, I made some cosmetic changes, including the following:

1. New color scheme
2. Moved labels from below the Steemometer to inside of it
3. Added labels for # of blocks examined and the most recent block examined

This is where things stood when I posted How busy is the Steem blockchain? last week. The reuse of variables meant that I had to run 4 separate copies of the program in order to simultaneously collect numbers for comments, transfers, votes, and all operations for that post.

This was unsatisfactory, though, because it would be unwieldy if I wanted to extend it for new operations, and because there was no way to switch between operations without losing the data that had already been collected, so I made two additional changes:

1. I restructured the variables as an associative array, so that now I'm saving the statistics for all operations of any type - not just comments, transfers, and votes; and
2. That change let me switch between operations without zeroing out the counters.

And finally, I have spot checked some of the results to develop some confidence that the numbers are valid.

Next up

So, now I need some goals for the next two weeks. Again, I can only do this in my spare time on the weekends, so my goals have to be extremely limited to be achievable. Here are the two things I'd like to accomplish in the next two weeks:

1. Make some of the code more modular, especially the checkbox functions, which contain some repetitive code.
   • This will not be visible from the outside, but it's necessary.
2. Start incorporating Visibility as a Service (VAAS)
   1. With the labels moved from below the Steemometer to the area inside of it, that leaves some free space behind. I'm going to use that to provide visibilty for token burning in 3 ways (one of which is new):
      1. Show promoted posts (SBD sent to @null)
      2. Show posts with beneficiary settings for @null
      3. new: Show "broadcast messages" from the memo field of transactions where STEEM was sent to @null
   2. The frequency/duration of the above displays will be determined by the size of the transfer to @null or the beneficiary percentage that was assigned to null.

Reflections

One thing that I'm noticing while working on this is that there is an infinite variety of applications of this type that could be created, call it "Steemformatics" to offer an exchange of information between the blockchain and the application user. On one hand, the application provides useful information (the Steemometer portion of the app) to the app user and on the other hand, it provides visibility for blockchain users - in exchange for token burning (VAAS).

( The information provided by the app doesn't even have to be about Steem. It could be something as simple as stock prices or weather reports. As long as it also provides visibility for token-burning, it would still benefit the blockchain's users. For example, imagine a widget on CoinMarketCap, Yahoo Finance, or TronScan with a scrolling list of Steem's #burnsteem25 posts. )

We already know about promoted posts and @null beneficiaries, but it occurred to me that someone could simply send STEEM or SBD to @null with a customized message, and that message could be displayed directly in the application. Instead of sending 0.001 STEEM to 10,000 users, you send 10 STEEM to @null, and achieve the same result.

Of course, this third possibility opens up a new possibility for spammy or abusive messaging, which would need to be controlled with pricing mechanisms, white lists, and/or black lists, but that's life in the technology world. Still, if an app happened to see widespread adoption, people would certainly be willing to burn STEEM in exchange for getting messages to large numbers of users.

When I started on Steem, there were a number of web-hosted applications that provided information about the blockchain (for example, Steemit Pond), but few of them survived. Why? My guess is that there were two reasons: (i) They didn't generate financial value for their creators; and (ii) web hosting costs money.

So, my proposed solution to those issues is for Steemformatics apps to make use of standalone technologies that don't involve recurring hosting costs, and to do it in a way that generates financial value for the creator. I can see two ways of generating value for an app creator who is also a Steem investor: direct payments, and token burning. At the moment, I'm not interested in pursuing direct payments, so I'm focusing on token burning. For direct payments, though, any model that involves the use of @null, could be duplicated with any other account, instead.

As soon as you have a financially sustainable model, an infinite variety of implementations are possible. Steem development really doesn't need to be a huge undertaking to be useful, so Steemformatics is a way to start simple - a "good first project".

Looking ahead

In Programming Diary #8, I mentioned the following long term goals:

1. A protocol and framework that I'm bouncing around in my head for decentralized abuse measurement and resistance.
2. A new version of @penny4thoughts that will be more tolerant to Steem API interruptions, extend a post's engagement lifecycle beyond 7 days, and let the author be more flexible in rewarding commenters.

And I've also been giving some thought to what would be needed for a UI for Steem authors and curators. I don't want to merely make a desktop version of what already exists, I want to make it better - or, at least, different. Some of those thoughts, I'll keep to myself for now, but one that I want to voice out loud is the need for velocity.

If we want Steem to be more than a niche blockchain, I think velocity should be priority #1. If I post on Facebook or Twitter, it can take me a matter of seconds or minutes. It almost never takes ¹/₂ hour or more. On the other hand, a Steem post almost always takes more than an hour, and commonly 2 or 3 hours. Unless that changes, we're simply never going to see mass adoption.

Some people have solved that problem with delegation bots, but that leads to a situation where the rewards are out of proportion with the value of the content.

IMO, what we need to find is a way to support high posting velocity without skewing the relationship between content value and rewards value. And to do that, I think we need to encourage replies and deemphasize top-level posts. Facebook and Twitter seem to accomplish this by resurfacing posts in user feeds when replies are entered. Accordingly, when I get to the point where I'm ready to work on a UI, I'll definitely be experimenting with ways to increase velocity by increasing the visibility of replies. So, here's my long-term list of goals for Steem development at this point:

1. A standalone desktop UI that gives the user independence from web sites and focuses on increasing social media velocity;
2. A protocol and framework that I'm bouncing around in my head for decentralized abuse measurement and resistance; (note to self, I'd better write this down before I forget what I have in mind...)
3. A new version of @penny4thoughts that will be more tolerant to Steem API interruptions, extend a post's engagement lifecycle beyond 7 days, and let the author be more flexible in rewarding commenters.
4. After I get done with the Steemometer, I think my next project will be a fairly simple 2 person game that will utilize Steem's content for the subject matter and use custom_json transactions for communications between the players.

Guess that's enough for today. Hopefully, I'll be back with Programming Diary #10 and Steemometer version 0.0.3 in two weeks.

---

Thank you for your time and attention.

As a general rule, I up-vote comments that demonstrate "proof of reading".

---

Steve Palmer is an IT professional with three decades of professional experience in data communications and information systems. He holds a bachelor's degree in mathematics, a master's degree in computer science, and a master's degree in information systems and technology management. He has been awarded 3 US patents.

---

^{Pixabay license, source}

Reminder

Visit the /promoted page and #burnsteem25 to support the inflation-fighters who are helping to enable decentralized regulation of Steem token supply growth.