Well, another two weeks have gone by since Programming Diary #12, so it's time for an update on my Java programming activities. I think this was the 3rd post in a row where I can say that I accomplished the goals I had set. I also locked the code version at 0.0.4 (alpha), since it seemed to me that this was a logical place for a version change. Finally, I had the opportunity to learn about the Java decompiling tool, JD-GUI. So, let me tell you more about it.
As with past posts, I start by restating my goals for this last fortnight, so here they were:
- Change Steemometer VAAS format for post promotion to look like the format for burned beneficiary posts.
- Change the top section of the Steemometer so that the one minute average is computed based on historical numbers, instead of naively multiplying a single block by 20.
As already stated, I accomplished both goals. I also made some additional progress, which will all be described below.
It's not really possible to visualize the completion of the first goal, since the instrumental portion of the display still looks the same. So, I'll just note that I added a queue data structure to hold 5 minutes of data (i.e. 100 blocks.
more on that later), and the instrument portion of the panel is now displaying a number that is derived from averaging the last minute, instead of just multiplying a single block's number by 20. This means that the movement of the needle is a lot less jerky.
This change can be visualized. You may recall in my previous post that the promoted post was just showing the URL/memo of the transfer to @null. Now, however, it's showing the post's author and title, as well as information about followers, votes, and payout value. Unchanged from last week, here's what it looks like when I display a post with an @null beneficiary setting:
And, changed from last week, here is the now-similar format for a promoted post.
The only difference being that it says, "Promoted post", instead of showing a null beneficiary percentage. Note that it now shows the post author's account name and not the account name that sent the promotion amount.
In addition to those planned changes, I also updated it so that post promotions with STEEM and SBD are roughly proportionate to each other (this uses the true median of the blockchain's price feed, not the reported median price, so haircut rules do not effect the comparison). I did this by using the blockchain median price to "normalize" the transfer amounts, by converting SBD transfers to the (roughly) equivalent STEEM value at the time of the transfer. So, here's how the Visibility as a Service (VAAS) logic goes now:
As previously discussed, in this context, post promotion can be done using STEEM or SBD and it can also be done on posts that have already paid out. This contrasts with the blockchain's promotion function, which does not allow promotion with STEEM, and it does not allow users to promote an already paid out post.
Incidentally, I also added blog.nutbox.io as one of the user-selectable web sites:
One of the things that I apparently didn't realize is that the Netbeans IDE that I'm using doesn't automatically add files to a git repository. As a result, I somehow created a class file that did not get incorporated into my git repo. Then, when I locked the version and tried to merge my "feature branch" with the "master branch", it ran into difficulties.
Thinking that I had backups of everything, I deleted the file that was involved in the merge conflict. But... you guessed it. No backups. One of my source files for a Java class was gone, and I had no other copies of it.
After searching my hard drive in vain for a backup of the source file, I knew that I still had the compiled class file. So, I asked ChatGPT how to decompile a Java .class file. ChatGPT referred me to JD-GUI, and I was able to use that to recreate the file (which is now added into my git repo. ;-). Otherwise, I probably would have lost a good bit of time figuring out what that lost code did and recreating it.
Before I can list my goals for the next fortnight, I have to describe the direction that I have in mind. Remember when I said that I'm saving five minutes worth of data, but only showing the one minute average? This is why.
From here, I'm going to move back to working with the instrument section of the display and let the user switch between the speedometer style visualization to a new one that will show up to five minutes of data. I'm imagining something like the Windows performance meter, but showing Steem blockchain activity instead of computer performance.
With holidays coming up, I'm not sure how much I'll be able to get done during this next fortnight, but I plan to start working on it. So, here are my goals for the next two weeks.
Other things that I eventually have in mind for this toy project in future weeks are as follows:
After completing those four additional items, I might take a run at publishing this in the Microsoft Store.
And, after that, my thinking is to rewrite all the VAAS section stuff to be a separate module that can be layered into any future Java project.
Finally, Java 22 is coming and Netbeans 20 was released, so I need to have an eye on those versions for the future.
In this post's reflections, I'm going to draw from some reading that I did in recent weeks and an article that I published last week instead of focusing on my coding activities.
During the last two weeks, I read a book that has been on my "to read list" for - probably - 20 years, The Selfish Gene, by Richard Dawkins. I wanted to read it because this is where the term, "meme" was introduced, but it turns out that the meme concept was just covered in one chapter, and the others were also fascinating and thought provoking.
It turns out, I think, that there are multiple relevant ideas here for Steem developers. I'll touch on three of them:
Dawkins argues that the proper level to think of natural selection is not at the level of organism, family, or group, but rather at the level of the gene. In this view, animal and plant organisms are basically robots that have evolved in order to increase the odds of gene survival. (consciousness, he hypothesizes, emerged as a means of simulating the future in order to improve survival-related predictive and decision-making capabilities.)
Drawing on numerous examples from biology, he shows how cooperative and altruistic seeming behavior at the level of the organism can often be explained by the gene's self-interest. It makes sense, for example, to sacrifice a single "survival machine" if it means that dozens of others with similar genes will survive and reproduce.
As Dawkins tells it, the first simple replicators (genes) emerged in early Earth history, and ever since then, natural selection has continuously filtered them in an unconscious, undirected process so that the lucky ones, the ones that constructed the best survival machines, have emerged and survived.
According to this argument, the human body (as with plants and other animals) is a survival machine for any number of cooperating replicators (genes): genes for blue eyes or brown, genes for tallness or shortness, genes for hair color and skin color, and so many more.
After 10 chapters of biology, chapter 11 almost feels like a tangent, where Dawkins introduces the notion of the meme - a unit of culture - which is equivalent to the gene in the sense that it's a new type of replicator. Dawkins definition of the meme is much larger than the concept of an Internet meme.
This, he argues, is indicative that evolutionary processes have now begun acting on a new replicator. The meme's survival machines, I suppose, would be things like speech, art, music, writing, computer databases, etc... The Steem blockchain (or individual Steem accounts) could also be seen as survival machines for memes. (Update: I should have mentioned that Dawkins said that our brains are the memes' survival machines, but the problem I have with that is that with writing and storage, memes can survive for long periods of time outside of our brains.)
In chapter after chapter, the tool that Dawkins used to make promote his central theme is the idea of the evolutionarily stable system (ESS). When you have an evolutionary system, an ESS is a configuration that (not surprisingly) remains stable over time. Once an ESS state is reached, the overall system normally doesn't change without some sort of outside influence (there is at least one exception, which is the reason I chose this topic to write about). Incidentally, the ESS is the same notion that Donald Hoffman used as a foundation for the arguments in his book, The Case Against Reality, which I wrote about here.
Dawkins, for example, examines the ESS with regards to aggression in a hypothetical population of hawks (aggressive) and doves (peaceful), and shows that if nearly all members of a group are peaceful, then evolutionary pressure would select for more hawks, but if nearly all are aggressive, then evolutionary pressure would select for more doves. The stable ratio turns out to be 5/12 dovish and 7/12 hawkish. Once this ratio is reached, it would be maintained. Similarly, Hoffman argues that when perception of truth competes against perception of useful abstractions in evolutionary systems, the truth-perceivers always go extinct.
The main point here is just that evolutionary systems tend to evolve towards some stable state. In some cases, there could be more than one possible stable state, which is where the iterated prisoner's dilemma comes in.
I presume that the reader is familiar with the prisoner's dilemma. In this exercise from game theory, two players are asked to make a choice: to cooperate or to defect. Importantly, this is a non-zero sum game, where the choices are described as follows:
| Scenario | Player 1 | Player 2 |
|---|---|---|
| 1. | Defect | Defect |
| 2. | Cooperate | Defect |
| 3. | Defect | Cooperate |
| 4. | Cooperate | Cooperate |
In scenario 1., both players receive a small penalty. In scenarios 2. and 3., one player receives a maximum payout and the other receives a maximum penalty, and in scenario 4. both players receive a modest reward. When you play that game repeatedly for an indeterminate number of generations, this is known as the iterated prisoner's dilemma.
I was already familiar with much of what Dawkins wrote here, but what was new to me was the succinct way he packaged it. It turns out that there are two stable states in this game. One of the stable scenarios is for every player to defect every time. The other one is more interesting. This is when players follow strategies that are "nice", "forgiving", and "retaliatory" (NFR).
By this he means:
Strictly speaking, the NFR stability is described as "collectively stable", as it's made up of multiple strategies. Here's what I thought was important, though.
If the evolutionary system is stuck in a Defect/Defect state of stability, it's still possible to flip it over the knife's edge into the more cooperative state. The key to this is to arrange the NFR players in high density, so they can gradually dominate a small part of the system and expand from there.
If the NFR players are spread evenly throughout the playing fields, the always defect players will dominate, but if you can put enough NFR players close enough together, they can start a cascade that eventually flips the whole system. And once that's accomplished, it's not possible to flip it back the other way.
In the context of my article, Let's talk about voting bots, I think this gives Steem's developers and curators something to shoot for. I haven't worked out exact numbers for scoring, but if we think of delegated self-voting on vacuous content as defection and conscientious content creation as cooperating, it might be argued that the Steem blockchain is playing an iterated prisoner's dilemma.
The cooperators, then, are acting to some degree as meme survival machines. The defectors are not.
If we want the Steem ecosystem as a whole to facilitate meme survival, it's not enough for individual conscientious content creators to exist and succeed, but they need to be surrounded by others who are also successful conscientious content creators. The developer's job (and curator's), is to bring those cooperators together, help them to succeed, and help spread their success to adjacent authors.
How does the developer do this? Thoughts:
The other necessary pieces, of course, are retaliation against defectors and forgiveness when the (prior) defector's behavior changes. As seen below, I have thoughts about these aspects of the Steem game, too, but I'm not ready to write about them yet right now.
Again, pulling forward from previous weeks, here are my longer term aspirations...
- A standalone desktop UI that gives the user independence from web sites and focuses on increasing social media velocity;
- 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...)
- 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.
- 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.
Not necessarily in the order above.
Additionally, related to #2 - I have now had an idea for bringing Quorum Sensing to bear on the abuse problem. It's slightly different from the other approach I have in mind, and the two approaches might or might not be complementary. I haven't thought through it enough yet.
Also, I've been thinking about the possibility of a private messaging/chat application that encrypts its messages using memo keys and sends them using
custom_jsontransactions.
Clearly, this is too much to accomplish in short order, but one step at a time, maybe I'll accomplish some of it.
Happy Holidays and I hope to see you again with another programming diary in a couple of weeks!
Visit the /promoted page and #burnsteem25 to support the inflation-fighters who are helping to enable decentralized regulation of Steem token supply growth.