Here's a summary of my Java coding activities during the two weeks since Programming Diary #11. Short version: I accomplished the two goals I had set for myself, made some additional progress with my toy Steemometer program, and also advanced with my ability to use (and potentially modify) the SteemJ libraries.
It's becoming regular practice for me to start these posts by recounting my previous goals and reporting on my progress against those goals, and this seems to be working well. So, here are the goals that I set for the previous fortnight:
- Display "vanity messages" in the VAAS area of the Steemometer application, alternating between vanity messages and @null beneficiary posts.
- Develop a shading mechanism for both the vanity messages and the @null beneficiary posts that uses a red/orange color gradient, but is not linked to the actual text - i.e. something in the AnchorPane fill color, bordering, or shadowing, TBD.
And, for the second week in a row, I'm pleased to say that I accomplished both (though I still have a lot of cosmetic work to do).
Here's what the vanity message (aka broadcast message) and the shading look like, at the moment:
In this post, the sender wants to promote a Steem community, so they send a message to @null and the message gets transmitted to all Steemometer users.
And here's a use that hadn't occurred to me when I wrote Programming Diary #11. In this message, the user wants to promote a web site that exists outside of the Steem ecosystem.
In both cases, you can see that I added a light shadow and I also colored the author label to indicate the amount of STEEM/SBD that was burned by the sender. I had trouble with the label coloring, and may still change them, but I basically followed the color of real flame temperatures: red -> orange -> yellow -> green -> blue. The more that gets burned, the "hotter" the coloring. The coloring of SBD transfers is scaled by the blockchain's median price for (approximate) equivalence with the coloring of STEEM transfers.
Also, as with burned beneficiary posts, the Visibility as a Service (VAAS) display box is clickable. In this case, it might send the browser to any of three locations:
I actually think that I'll disable the first use temporarily, though, because the risk of phishing attacks is too high without some sort of curation capability.
So, we can declare "Mission Accomplished" on the prior goals. I also made some additional progress that I hadn't planned:
Having created the vanity message capability, I found that it was easy enough to apply the same code (SBD, instead of STEEM) in order to also add promoted posts to the display. Here's what that looks like right now.
And the VAAS box is clickable, taking the browser to the actual promoted post. My intention for promoted posts is to change the display so it looks like the posts with burned beneficiary rewards, i.e. like this:
An interesting thing, here, is that - unlike the blockchain promotion function - it is also possible to promote a post that has passed its payout time (remember, the goal here is "audience building", not "reward harvesting"):
Again, this will eventually be updated to look like the burned beneficiary posts.
And this brings me back to the idea of vanity messages. My thinking when I last posted was that "vanity messages" would come from burning STEEM whereas post promotion would come from burning SBD (like it does now). I also had no thoughts, last time, about linking away from the Steem ecosystem.
My thinking has changed, however. Now, I'm thinking that there doesn't need to be any difference between SBD and STEEM burns. Basically, either SBD or STEEM can fuel a post/link promotion type of display or a vanity message type of display.
So, that's where I'm going next. If the memo comment contains a valid Steem link, I intend to display it like today's burned beneficiary posts. If not, I intend to display it as a vanity message (with/without a link to an external site).
Finally, I made a change to the random selection algorithm. The Steemometer is maintaining three lists: posts with burned beneficiaries; SBD transfers to @null; and STEEM transfers to @null. So, the first choice is to display one of those three types. This is done as a simple 1 of 3 selection (defaulting to a second and third choice if the first type(s) are not available).
What I changed, however, was the selection criteria for individual posts/messages. At first, the program was using a simple random selection. A transfer of 1 STEEM was just as likely to be picked as a transfer of 0.001 STEEM. Now, however, I changed it to select randomly according to the size of the beneficiary setting or the transferred amount. So what we see now, for example, is the following:
As noted in Programming Diary #11, I gave myself a scare when I cleaned up my Maven repository and SteemJ stopped working. Eventually, I was able to get it working again by updating the version and downloading from jitpack.io. However, I was concerned because there's a risk of that site becoming unavailable, so I wanted to compile a working version for myself. With this, I had limited success.
Basically, it doesn't seem that there's a release in the primary repo that actually works (or, at least, I couldn't get one working...). However, I did find what I think is the commit that's used in the jitpack.io distribution. Notably, the commit contains this warning:
However, I was able to copy that commit to a git repo of my own and eventually got it to compile. So, at this point, even if the jitpack jar file goes away, I'm confident that I can at least use SteemJ in its current form, and potentially even make improvements to it (I already updated most of the dependency versions, for example.)
The caveat here is that I had to disable testing in order for it to compile. It seems that the "surefire" (whatever that is) test modules depended on having a Steem testnet, and I suspect that none is presently available, so future enhancements seem to depend on restoration of a testnet (as well as skill improvements on my part).
I still use the Steem Links Creator (SLC) as my interface to SteemJ, so while I was working out the issues above with SteemJ, I also made some cosmetic changes to the SLC and modified it to use my locally compiled version of SteemJ instead of the one from jitpack.io. The current formatting of posts from the SLC now looks like this.
If you're curious, here's what the app looks like now. I haven't changed it much since I first worked on it a couple years ago:
This was done with Java Swing, instead of JavaFX, which I'm using for the Steemometer app. After hitting "Post to Steem", here is the corresponding post.
I already know that I have plans next weekend, and unexpected family activities arise frequently at this time of year, so I'll be especially modest with my two goals for the next fortnight. Here they are:
In this week's "Reflections" section, I want to revisit and extend one idea from the previous post, and also add a new one. The repeated topic is API reliability. The new topic is mentioned in this post's title: Building a bridge between "Steem Island" and the rest of the Internet. So, let's start with the newest topic first.
Maybe it should have been obvious, but this past cycle is the first time that I ever realized that someone can easily promote external web sites by burning STEEM/SBD. If we enhance that capability in the ecosystem, it gives whole new (real world) communities a reason to participate.
The fact that we have constant "link spamming" activities suggests to me that there might be a demand for this sort of capability, so I think it's something that all developers should think about. Obviously, I don't want to just move SPAM from one place to another, but maybe we can do more to help promote external sites in a way that is not intrusive, spammy, or scammy - and grow our community at the same time.
As I mentioned before, one unexplored use of Steem's Visibility as a Service capability is that we could put lists of #burnsteem25 posts in apps and websites that really have little else to do with Steem in order to help our authors build their audiences. Now, it's clear that the reverse use is also possible. By providing a link-out capability in exchange for token burning, we can give people a reason to buy and use Steem's tokens, even if they have no interest in blogging or curating.
And, of course, if STEEM's value is influenced by Metcalfe's Law, then every bridge from Steem Island to the Internet has the potential to increase its value.
Instead of API Stability, let's call it infrastructure. Simply put, we need to find a way to improve Steem's. Here are four examples:
Now, I don't point these things out to be a "Negative Nellie", so I want to explore solutions. I get that everyone is resource constrained, but (IMO), the need to fix infrastructure topics like these is a fundamental requirement for any blockchain. We, as a community, need to find solutions. Four possible approaches come to mind for discussion:
Anything else?
I'm sure that this is solvable, but it's something that needs attention and prioritization.
Again, I'll pull forward from previous weeks so that I don't lose sight of things:
(It's a shame that it's so much easier to have an idea than it is to implement it. 😉)
- 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... Nov 18 and Nov 30: Still haven't written it down.)
- 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_json transactions. I might give that a try, too. Although, with this post from @blockseater, that might not make sense.
That's it for today. Hope to see you again in 2 weeks!
Visit the /promoted page and #burnsteem25 to support the inflation-fighters who are helping to enable decentralized regulation of Steem token supply growth.