Programming Diary #11: Ready to start on vanity messages

remlaps (74)Verified Developerin Steem Dev • last year (edited)

Summary

Six steps forward and two steps back. I'm done (for now) with displaying @null beneficiary posts, and moving on to broadcast messages from burning STEEM. But, problems loom on the horizon.

Background

As the reader may recall, I am currently working on a toy Java programming project in order to build my programming skills with java on the Steem blockchain. The project is called, "Steemometer", which is a play on words from "Speedometer" (or, could be, "Thermometer" - take your pick). In Programming Diary #10, I set myself two goals for the next two weeks. They were, as follows:

Add author information to the @null beneficiary display, including (probably): author reputation, number of followers, median SP of followers, and median reputation of followers ( the thinking here is adapted from busy dot org (now defunct) some years ago, basically the more SP and higher reputation that an account's followers have, the more likely it is that they're writing something that's worth reading... so I want to make that information available to the viewer ).

Add a pause button.

I'm pleased to say that in the course of 38 git commits, I accomplished both goals, and more. And I merged my changes into the git master branch, locking version 0.0.3a of the Steemometer. The visual to the right shows what version 0.0.3a looked like.

Progress

Version 0.0.3a (still alpha)

It's plainly visible there that I added the pause button, and that I also added specific information about the author and the post. Here are the fields in the Visibility as a Service (VAAS) section of the program.

Link: Contains a clickable link to the post that will open in the regular system browser.
Author: Unsurprisingly, this contains the author's account name
Row 2: Contains the post title, scrolling from right to left across the screen, since its length might exceed the display width.
Reputation: The author's reputation score on the Steem blockchain
# Followers: The number of accounts that follow an author.
Median follower rep: The median reputation of the accounts that follow the author (something that I noticed is that authors with more followers actually tend to have lower median follower reputations. I hadn't expected that, but I guess it makes sense.)
Pending payout: The post's pending_payout_value, as reported by the blockchain. I believe this changes to zero at payout time, so I'll eventually need to update the handling of post value.
Net Votes: Is the number of net votes, as reported by the blockchain. Something surprising that I don't fully understand yet is that the net_votes value doesn't actually match up with the actual count of votes... and even steemit and upvu sometimes report the vote counts differently, so this number will eventually need more research.

The only field I had mentioned in the previous post but did not include was the median SP of followers. When I started to think about the mechanics of that, I realized that it would involve far too many network calls, so I shelved that for the time being.

In addition to completing my two stated goals, I also added a new button that lets the operator select between steemit.com or upvu.org for the web site. Please let me know if any other web sites should be added.

Finally, I did a fair amount of code cleanup. The code is still a mess from all the "trial and error" that I'm doing, but it's better than it was.

At that point, I decided to move on from @null beneficiary posts, so I locked version 0.0.3a, and began work on 0.0.4a. The goal for this version (still in progress) is to let people send broadcast messages to all users of the application by sending STEEM to @null (not SBD, which is used for post promotion).

0.0.4a (still alpha)

Fortunately, I've had some time in the evenings this week to move forward with version 0.0.4a, so it already looks somewhat different from 0.0.3a. Here's what it looks like at launch time, and after someone posts a @null beneficiary post:

launch time

After @null beneficiary post is observed

The main changes thus far are:

I added all of the author/post fields to a separate JavaFX AnchorPane object that can be activated and deactivated, easily, at will.
I made it so the entire AnchorPane object is a clickable link, so there's no need for the "Link:" field any more.
I changed the scrolling title to Blue and colored the beneficiary percentage with different shade of red/orange for 0-25%, 25-50%, 50-75%, and 75-100% beneficiary percentages. (Similar to what I had done in the previously described Browser Extension for Steemit). Eventually, I'll change this to link the shading to something other than a text object, but that's where it stands right now.

And all of this is in preparation for the main goal that I'm going towards this weekend, letting Steem blockchain users display "vanity messages" in the application by transferring STEEM to @null.

On one hand, this is a fairly simple change, but on the other I'm facing a sort-of writers block because it involves two things that make me cringe:

I'll have to iterate through the @null account history
I'll have to do date comparisons between when the transfers are sent, and when the program was launched.

For whatever reason, I seem have a mental block against getting started whenever JSON iteration and date comparisons are involved. Coding those tasks just feels disproportionately tedious to me. But, I'm expecting to force myself into it today or tomorrow.

Storm clouds on the horizon

Now, for anti-progress: I am aware of two challenges, outside of the programming arena, that I'm likely to face in the future. First, I am at risk of exceeding the storage allowance for a free bitbucket account; and second, I broke my SteemJ capability.

Bitbucket space issues

I had been storing the MSI files in my (free) bitbucket git repository, but I learned that this was a bad idea. The repository crossed a 2G threshold, and bitbucket started threatening to make it inaccessible if it goes up to 4G.

So, I took a break from coding and - with help from ChatGPT - learned how to delete the MSI files from current and past branches. On my local machine, the repo is now down to 300M, so space should be plentiful, but bitbucket hasn't recognized the changes yet. I'm not sure if there's garbage collection that needs to happen or if I'm missing something. So, according to bitbucket the repo is still 2.1G. I'll have to keep an eye on that, and act in time to avoid disruption if it resumes growing.

SteemJ dysfunction

As I noted in Programming Diary #8, SteemJ was working as recently as a few weeks ago. However, one of the things I tried when I was troubleshooting the bitbucket space problems was deleting my local Maven repository under the theory that anything I needed would get downloaded again.

Unfortunately, last night I tried to compile a program with a SteemJ dependency, and it failed with a message about a missing jar file, so I'm guessing that I had a local jar file in my Maven repo, and it's not available centrally anymore because SteemJ is no longer maintained. At this point, I have a copy of the SteemJ github repo, but I'm not able to compile it, and I'm not able to download a Jar file from Maven. So, when I'm eventually ready to start using read-write instead of read-only, there will be challenges.

Next up

So, continuing the practice that I began in Programming Diary #8: I'll set myself 2 goals for the next two weeks. Weekend and evening time is a continuing challenge, so they will be conservative, again. My goals for the next fortnight are:

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.

Before moving on, I'll say a few words about vanity messages or "broadcast messages". As I mentioned, iterating through API calls and doing date comparisons both trigger a sort of writers block in me, but on the other hand, this is something that I've been looking forward to seeing because I don't think it's been done (or even described) before this series of posts.

As previously described, the idea is that the @null wallet address can be used as a broadcast or multicast address to deliver messages to numerous application users at the same time. On a popular app, for example, a person could send 0.1 STEEM to @null and reach thousands or tens of thousands of people with a free-form message. This would obviously need to be regulated by things like minimum prices, subscription fees, white lists, and black lists, opt-in and/or opt-out; but in combination with the right application, I think that people would find this capability very useful and desirable.

Reflections

Two main reflections for this post: (i) We need public APIs to be more scalable and reliable; and (ii) Curators and stakeholders could attract developers by hosting 2-week long developer contests - a perpetual hackathon.

API reliability

Since I select the API server at random, one of the things that I'm noticing is that there is a big difference in the availability/reliability of the various APIs that I'm using. Without naming names, there are several that almost never work as expected, there are others that are intermittent, and there are a couple that I can almost always count on. Actually, I'll name the reliable ones: @moecki and @pennsif. So, please let me know if I need to make adjustments to the API list. Here are the ones that I currently have available (ignore the first one. 😉)

    String[] apiServers = {
        "https://api.bad4testing.example.com",
        "https://api.blokfield.io",
        "https://api.campingclub.me",
        "https://api.dlike.io",
        "https://api.justyy.com",
        "https://api.moecki.online",
        "https://api.pennsif.net",
        "https://api.steememory.com",
        "https://api.steemit.com",
        "https://api.steemitdev.com",
        "https://api.upvu.org",
        "https://api.wherein.io",
        "https://api.worldofxpilar.com",
        "https://steem.senior.workers.dev",
        "https://steemapi.boylikegirl.club"
    };

If Steem is going to attract developers, our API infrastructure really needs to be a lot more scalable and reliable.

The perpetual Steem hackathon

One of the things I've seen over the years is that developers come in with grand plans, it's harder than they expected or they don't see rapid adoption, and they fizzle out. IMO, we need to incubate development differently, from the ground up. We have some solid developers here, but nowhere near enough. So, I suggest a perpetual Steem hackathon (Steemathon?) as a solution. Unfortunately, I don't have the stake to back the idea, but I think it is a solid, pro-growth idea. Maybe the #steemdip team could organize it in a Steem community and back it with their voting (@steemchiller, @justyy, thoughts?)?

Basically, it centers around people doing what I've been doing for the last 6 weeks, but in a more formal way, like this:

Week 1: Contest begins. Contestants announce their plans. They can do whatever they want (even documentation), but it must be a 2 week project.
Week 2: Contest host summarizes the in-progress activity
Week 3: Contestants announce their results and their plans for the next two weeks.
Week 4: Contest host summarizes the in-progress activity for the new contest and the winners of the previous contest.
and so on...

(Note: I'm intentionally avoiding the word, "sprint", but we all know what it is. 😉)

Forget about the grand plans. Just develop something that can be built here and now, and make a little progress every fortnight.

The winners don't have to build the next killer app. They just need to build something better than their competitors. Eventually, we can hope that this process will incubate the next killer app(s).

Looking ahead

Just pulling forward from my previous posts so I don't lose sight of the longer term goals, here they are:

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: Still haven't written it down. Best get on that.)

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, in light of the fact that I lost my ability to use SteemJ during this cycle, my unanswered question from Programming Diary #10 is now more important to me, so I'll repeat it again here:

Feedback requested

Also, I have a question for the community. ChatGPT told me about the OpenAPI generator, which can be used to generate API wrappers in 50+ languages based on the OpenAPI Specification. So, my question is twofold: first, does Steem already have a published OpenAPI specification for its interfaces? Second - assuming "no" to the first question - can we put together a community initiative to create one in order to attract developers?

Please respond below with your thoughts...

Finally, let me say that if anyone is interested in trying out the Steemometer app (Windows only) and letting me know your thoughts, just let me know. I make no promises of functionality, but I can put the MSI file up in cloud storage somewhere so that you can (hopefully) download and install it on your own machine. It installs and uninstalls as a typical Windows package.

Eventually, my intention is to make the code "open source" and to publish the app in the Windows Store, but I'm nowhere near that point yet.

That's it for today. Next update in 2 weeks, I hope!