Programming Diary #16: Post aging and promotion totals

Summary

Here I am, back with another fortnightly Programming Diary entry. Two weeks ago, I posted Programming Diary #15: Voting suggestions and author incentives, so now it's time for #16. Tasks this week involved working on program stability, setting time limits for how long posts will stay visible in the Visibility As A Service (VAAS) queue, and getting total promotion amounts for posts and memos with multiple promotions.

Background

In the last post, I set myself two goals and a "stretch goal" to be completed by today. Here they are:

1. Age posts and vanity messages out of the middle portion of the window (the Visibility As A Service (VAAS) section).
2. Cosmetic changes to improve the look and feel of the Suggest vote pop-up.
   

Additionally, I want to consider improvements to the Suggest vote logic, and think about ways to evaluate the scoring method's effectiveness (or whether that is even possible).

I also noted that I might not be able to accomplish all of the goals because my spare time that I hoped to use for programming was going to be consumed by the need to cut up a tree that had fallen in the yard during wind storms.

On that last point, I was correct. Between cutting up the fallen tree and shoveling snow, my programming time has been very limited during this interval. So, I accomplished the first goal, but made no progress on either the second goal or the "stretch goal".

So, let's talk about what I did manage to accomplish. Unfortunately, today's post will need to be rushed so I can get some more tree branches cut up before darkness falls. Please forgive any shortcomings in proof-reading.

Progress

Aging posts & vanity memos out of the VAAS display

Up until this week, once a post/memo got into the VAAS section of the display, it stayed there until program termination. Now I added a "half life" and an expiration time based on numbers of blocks after the post/memo was added. Every time that "half life" blocks pass, the post/memo becames 50% less likely to be displayed. At the end of the max life span, the post is completely removed from the queue.

In order to accomplish this, I needed to learn to make use of a Java properties file. The properties file looks like this:

blocksPerMinute=20
! likelihood of display is cut in half after halflifeBlocks are seen.

! Posts are deleted from XferMemoList and PostList objects after maxlifeBlocks

!   1200 = 1 hour, 7200 = 6 hours, 14400 = 12 hours, 28800 = 1 day, 86400 = 3 days, 201600 = 7 days.

halflifeBlocks=28800

maxlifeBlocks=201600
! If startBlock is < 1, start with last irreversible block, otherwise start with startBlock.

! startBlock=81790958

startBlock=-1

And the functions to retrieve the relevant properties were created in a new class that makes use of the java.util.Properties class.

At present, the VAAS objects are set to cut their likelihood of display in half each day and to get deleted from the queue after 7 days.

Unplanned progress

The main reason that I didn't move on to my second goal was a shortage of time, but I also got distracted by another challenge. I wanted to add the promotion amount to the display for promoted posts, but this is not as easy as we might have hoped.

First, I can't use the promotion amount from the blockchain because I'm allowing the use of STEEM or SBD for post promotion. Second, the STEEM condenser_api.get_content API call always returns "0 STEEM" for the promoted amount, so it's not even straightforward to just get the SBD promotion amount.

So, the solution that I settled on was just to total the promotion amount during the time that the program is running. I had already saved the normalized amount for each transfer (i.e. ratio of SBD / STEEM prices at the time of transfer), so now I just needed to calculate the total whenever the source of the transfer and the memo are the same. We can see this in practice, here, over the course of four transfers (three SBD and one STEEM):

Transfer 1:

steempy transfer --account remlaps null 0.001 SBD @remlaps-lite/calling-the-peak-expected-daily

Note that after conversion and rounding, the promo amount (which is new) shows up as 0.005 STEEM, not as 0.001 SBD.

Incidentally, I also added the "Suggest vote" button here. I had intended to leave that out on promoted posts, but I changed my mind.

Transfer 2:

steempy transfer --account remlaps null 0.001 SBD @remlaps-lite/calling-the-peak-expected-daily

Note that the promo amount has now updated to 0.009, which is 0.002 SBD after rounding and conversion.

Transfer 3:

steempy transfer --account remlaps null 0.1 STEEM @remlaps-lite/calling-the-peak-expected-daily

Unsurprisingly, after the 3^rd transfer, we see the promotion total increase by 0.1 STEEM to 0.109. Also, note the brightening of the border of the VAAS section and "Promo" label as the promotion amount increased.

Transfer 4:

steempy transfer --account remlaps null 0.3 SBD @remlaps-lite/calling-the-peak-expected-daily

Here we see that ³/₁₀ of an SBD added more than 1.3 STEEM to the total.

I mentioned this before, but it bears repeating... the post that I promoted there has already passed its payout window. So, using this method, we are able to promote posts using STEEM and SBD, before and after their payout time. This contrasts with the blockchain promotion function, which only allows promotion in SBD, and only prior to payout.

Next up

In the next two weeks, my first goal will be to improve the look and feel of the "Suggest vote" pop-up window, which was my unfinished goal from the previous two weeks.

My second goal will be to add a notification icon and pop-up window with information about exceptionally large transfers, power-ups, and power downs. This is similar, in concept, to the WhaleAlert Twitter (X) account.

Again, as a stretch goal, I might make some changes/improvements to the vote suggestion algorithm.

However, I still have a lot of tree branches that need to be cut up and stacked, so don't be surprised if I miss one or more goals again during this cycle.

Reflections

Recent numbers have confirmed what I posted here, namely that the expected number of "New STEEM per day" peaked on November 10, 2023, and it's now projected to follow a 13 year down-trend (subject to caveats). So, what does that mean to the Steem developer?

My thinking is that the developer's business model should be migrating away from reliance on rewards and towards some other form of revenue generation. I think this was always true, but it's becoming more important now. Other sources of revenue might be any of the following:

1. Software licensing/usage fees
2. Subscription fees
3. Advertising revenue
4. Value appreciation for STEEM holdings
5. What else?

Software is a mature industry, and numerous revenue models exist. Historically, however, it seems to me that most of the Steem developers have developed their business model around the ability to extract rewards directly from the blockchain.

As the daily number of new STEEM declines in the future (gradually and then suddenly), developers will probably need to fall back on the tried and true methods that other software developers have used for the last 50+ years.

I'm reminded of the claim about Levi Strauss building a successful clothing company during the California gold rush. They didn't become a success by mining gold. Instead, they became a success by providing rugged clothing to the people who were doing the mining. In my opinion, the successful Steem developer needs to start thinking along these lines.

This is also illustrated in the book, Two Years in the Klondike and Alaskan Gold-fields, where William B. Haskell wrote:

"It is one of the peculiarities of mining regions that much of the gold goes to those who do not dig it."

The mission of the developer, I think, should be helping the users of their software to succeed with the Steem blockchain, not necessarily to extract value directly from the blockchain, itself. The developer should start thinking along this line of reasoning,

I'm not here to collect rewards. I want to help my clients collect rewards and increase the value of their stake (and get paid for doing it).

Thinking along these lines opens the possibility that the Steem developer can get paid by their clients in the form of STEEM, SBD, or even USD/local currency.

As the daily rewards continue to decline, I expect that this will become increasingly important.

Conclusion

Time is getting short, so I need to wrap up here. I apologize for any errors that slipped through my rushed composition and proof-reading. Thanks for reading.

As before, my longer terms aspirations for the future can be found, here.

---

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.