Programming Diary #29: Imagining the "value per feed" curation model

Summary

This post describes recent programming activities, primarily focused on new features for the Steem Curation Extension. These activities included extending the curator's information overlay and adding a capability to show or hide resteemed posts.

In my opinion, one of the key improvements from the curator's overlay is the addition of a value per feed metric, which is somewhat analogous to "pay per click" or "pay per view" in traditional social media. Although there are known problems with this metric, it creates an incentive for authors to grow their audience, and it provides curators with a simple piece of information to evaluate whether the blockchain's resources are being allocated efficiently.

Finally, the concepts of "feed-reach" and "value per feed" open up the possibility for a next generation voting service that will align participant incentives with value creation for the blockchain.

Background

Steem Curation Extension

In my previous Programming Diary post, I discussed the addition of a new overlay with information for curators in the Steem Curation Extension.

As you're likely aware, this browser extension has been around for a couple of years, but until recently it was limited in function to just highlighting posts that are participating in Steem's default Visibility as a Service programs with @null beneficiaries or post promotion. Recently, with help from @moecki, the extension was also updated to display an account's voting power in the condenser profile menu.

And in the previous programming diary post, I stated this goal for the coming two weeks:

I can already see that my time is limited for the next two weeks, so I'm only going to set myself one specific goal for this interval, and that is to start displaying information about the author and their reach in the Steem Curation Extension. We'll see how much progress I can make.

It turned out that I had more time than I anticipated, and I made much more progress on this than I had expected (as seen here, here, and here). More about that later, but first we need to bring in some additional background.

In addition to displaying some information for curators, I was also able to add a toggle to show/hide resteemed posts. There will be more on this below.

Follower network strength

I have another extension out there called the Steem Follower Checker, which returns a value that's intended to provide information about the strength of a particular Steem account's follower network. Basically, as described here, here, and here it's based on the number of followers and the median follower reputation with some adjustments for the account age.

Importantly for today's post, this scoring method can also (probably) be used to assess the strength of a community's subscriber network.

Semantic versioning

I noticed a github option to create a release, so with all of the recent changes, I thought it might be appropriate to do so, but github warned to learn about semantic versioning and the help link that they provided wasn't very useful in this context. So, last night I asked a bunch of AI assistants how to apply semantic versioning in this context. Answers were similar, but I think Claude's was the best:

Me: Can you explain semantic versioning to me in the context of a browser extension? I'm not sure how backwards API compatibility applies in this context. I'm not really making an API.

I have a browser extension that executes a content script on top of the steemit.com web site (and any other web sites that run the "condenser" software). In addition to the HTML & JavaScript on the web site, it also pulls in data from Steem blockchain API endpoints, and from the 3rd party SteemWorld API.

When I make my first release, what should I use for the version number, and when should I update the major/minor/patch values for future releases?

Claude: Let me explain semantic versioning (SemVer) in the context of your browser extension.

Even though you're not creating a traditional API, your extension still has interfaces it depends on:

1. The structure of steemit.com's HTML/JS (the "condenser" software)
2. The Steem blockchain API
3. The SteemWorld API
   
   

For a browser extension, here's how you might apply SemVer (MAJOR.MINOR.PATCH):

Start with version 1.0.0 for your first stable release. Then:

MAJOR (1.x.x): Increment when you make changes that could break functionality due to:

• Adapting to major changes in the website structure
• Handling breaking changes in the Steem or SteemWorld APIs
• Removing or significantly changing features that users rely on
  
  

MINOR (x.1.x): Increment when you add functionality in a backward-compatible way:

• Adding new features
• Adding support for new parts of the website
• Adding usage of new API endpoints
• Deprecating functionality (but not removing it)
  
  

PATCH (x.x.1): Increment for backward-compatible bug fixes:

• Fixing selector bugs
• Correcting data handling
• Performance improvements
• Minor visual tweaks
  
  

For example:

• 1.0.0: Initial release
• 1.0.1: Fixed a bug where a CSS selector stopped working
• 1.1.0: Added support for a new page type
• 2.0.0: Rewrote extension to handle major changes in the website structure
  
  

Now, let's look at recent development activities against that backdrop.

Activity Descriptions

Hiding resteems in feeds

First, and totally on a whim, I decided to add an option to show or hide resteems in an account's feed. This works in my own feed or in someone else's. At first, I placed the checkbox to do the hiding in the lower-left corner, but I had to move it later. More on that below.

Thanks to a bug report by @michelangelo3, I was also able to fix a bug where resteemed posts by followed accounts were being hidden, even though they should remain visible, from the perspective of the feed-owner (following account).

It also turned out that if you scroll down too far in the feed and then switch the checkbox, performance becomes intolerable, so I had to limit the toggle availability to 200 posts. If you scroll down below that, the checkbox disappears and you're stuck until reload with whatever setting was last picked. It's not a great solution, but it's the only one I have found for the time being.

Information for Curators

After adding the resteem option, I switched to the intended focus, which was adding some information for curators. Most of the fields are described here. In addition to those fields, I have now also added a summary of votes from the Steemit curation accounts, and a per-feed payout value (which was prompted by this suggestion from @denmarkguy). Here's what the overlay looks like now (in my dev branch):

Dark Mode	Light Mode

The new "$ / feed" field is the one where this post gets its name. From browsing with this extension in place for a couple of evenings, it seems that this is broadly similar to the "pay per click" or "pay per view" models that we see on other platforms.

Of course, no metric will ever be perfect, but I think this one has the potential to be very useful in our ecosystem. There are, however, already some known drawbacks:

1. As previously mentioned, followers can be double-counted, triple-counted, or more if they are also community subscribers and followers of a resteeming account.
2. As soon as an unscrupulous author knows that they're being evaluated based on value per feed placement, they'll start creating alternate follower accounts in order to increase their feed-reach score.

This second point is where the Follower Network Score comes in. It occurs to me that similar scoring can be applied to community membership and resteeming accounts in order to detect the large-scale addition of inauthentic followers.

Now we encounter a new problem, though. Calculating the Follower Network Score is slow. It's far too slow for inclusion in the browser extension's overlay. So far, I see two potential solutions to this:

1. Add a button to each article summary where the browser operator can click and wait patiently while the score is calculated.
2. A separate standalone program with one or several dedicated accounts could calculate the score whenever a top-level post is published or resteemed and then it could vote on the post as a form of inter-process communications with the percentage set to a very small value that matches the score (Most likely, 1.41% or less). Since the list of voters is already available to the browser extension, this information would then be easily and quickly accessible.

Anyway, I'm getting ahead of myself. The bottom-line is that no metric will ever be perfect, but I think there's good future potential for this "value per feed" concept. In browsing, I've seen the blockchain paying returns that range from $0.00000 to $9+ for each potential feed placement.

Hiding resteems in blog links

In conversation with @the-gorilla, it came to light that - in addition to feed links - I should also add the capability to hide resteems in blog links. So, I did. But that raised a new problem, because the lower-left corner, where I had the checkbox, is utilized in our blog pages. So, I moved the check-box to the top-center, inside the floating header section. Here's what it looks like altogether now for both feeds and blogs (again, in my dev branch).

Link	Dark Mode	Light Mode
Feed
Blog

@the-gorilla mentioned that he's adding the "hide resteem" functionality to condenser, so I'll eventually be taking it out of the browser extension, but it's available for the moment.

Looking ahead

I don't see much change from what I wrote last time,

From now until 2025, I think my focus will be on 3 areas: The Steem Curation Extension, the Steem Conversation Accelerator (SCA), and the word search game that I discussed a few weeks ago.

So you can see that post for more details about the long-term direction for these projects. This post is already getting overly long.

Next Steps

For this next interval, my main goal is to issue a first release in github using the semantic versioning label. I'll be testing today and tomorrow, and maybe I'll do that on Monday. The AIs said that I should also add the version in the extension's manifest.json file, but I'm not actually going to do that. I like having the release date in that file. Finally, I'll start with version 0.1.0, not 1.0.0 as Claude suggested. I don't feel like this should be considered a "stable" version yet (if ever).

Beyond that, I'm not sure. I'd like to integrate the network follower score into the browser extension to complement the "value per feed" metric, but I'm torn about how to move forward on that. I think that's also going to take longer than two weeks.

Maybe I'll let the first release "burn in" for a couple of weeks and shift my attention back to the Steem Conversation Accelerator (SCA) or the wordsearch for a while. I might also look at tag-following in one or both of those extensions. There's a lot that I want to accomplish, but after the unexpectedly quick progress of the last couple weeks, I also feel sort-of aimless at the moment.

Reflections

In the "Reflections" section of my previous post, I talked about the phenomenon of overvalued posts. I have thought for a years that the solution to this problem will eventually be a next-generation version of paid voting services which would outcompete the current iteration. I was having a hard time imagining what that might look like, though. All I had was that: (rewards + audience) > rewards alone.

Now, with the emergence of this "value per feed" metric, I'm starting to have some ideas about what a next-generation voting service might look like.

I still don't see a full picture, but here are some basic points:

Eliminate the need for daily posting

Instead of receiving daily votes, authors receive and bank daily credits. When they cash in the credits, it can be multiple times per day or it can be spaced out multiple days apart.

Vote sizes are awarded based upon feed-reach (with controls for inauthentic accounts), not just delegation/payment size

It is clear to me that authors should not be expected to be curators. Some authors may want to be curators, which is fine, but an author's primary contribution to the blockchain is their creative output. If they're spending their time curating, it might actually make them less useful to the blockchain.

So, it makes sense for authors to delegate their rewards to paid voting services in order to bootstrap and sustain their content creation activities. In my opinion, this should not be discouraged - provided that they're producing worthwhile content.

If voting services award votes in proportion to feed-reach, then the authors will be properly motivated to build their audience. Ultimately, that's what the blockchain is designed to pay for - people who create content and put it in front of other people.

In this case, the voting services will still draw revenue from delegations, straight-out vote buying, and from curation rewards, but the clients' incentives will be properly aligned with STEEM value growth.

Obviously, this is still not a complete picture, but I'm starting to see possibilities.

Conclusion

And that's a wrap. I had much more progress than expected in the last couple of weeks, and I'm very grateful for the feedback that I received from commenters with regards to changes in the Steem Curation Extension.

The two big improvements during this iteration were (i) the ability to hide resteemed posts; and (ii) addition of numerous fields in the curator's overlay.

In particular, although problems remain, I think there is a lot of promise for expansion and utilization of the feed-reach and "value per feed" metrics.

Personally, when I access condenser web sites from my cell phone, I find that I miss having some of the features that the curation extension provides on my desktop - so I know it's providing me with useful information. I hope it's useful for others who have been trying it out too.

If you haven't tried it out, I invite you to give it a try. And if you're a developer, I invite you to contribute. I'm figuring this out as I go, so no particular expertise is required - just a willingness to learn.

---

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.