Nice article and I 100% agree on the importance of RPC (API) nodes but I must take issue with a number of facts and conclusions.
The cost or running a full API node (or RPC node) has dropped by orders of magnitude as the Hive code efficiency has increased, RAM requirements have been reduced dramatically and fast NVME storage has become dirt cheap.
I have posted here about how an API node can be built for around $750.
The issue is not cost but technical complexity and lack of idiot proof documentation.
It IS NOT the role nor duty of a Witness to run and maintain a RPC node.
While technically correct - it is not a mandatory requirement - it is something that is increasingly factoring in who people vote for witness and this is a good thing.
Changing the reward balance to have the blockchain pay people for running API nodes is fraught with complexity and controversy.
In my view it is just better to create a voter expectation that high ranking witnesses (or anyone hoping to become one) will run an API node.
As a backup witness I am receiving a producer reward or either around 1.3 HP every time I witness a block (it varies slightly above or below for reasons I don't understand). A top 20 witness receives 0.258 HP.
The fact is that running a RPC is still much higher a cost than running a Witness node.
When we look at the distribution of printed HIVE it is clear that part of it is dedicated to the needs of the chains infrastructure.
So the precedent to the fundamental roles of the distribution of printed HIVE is there.
There is absolutely nothing preventing a Witness from running a RPC node. That option is open to anyone.
Why anyone would run one, is up to the individuals own reasoning. As you stated, it could be a part of their witness campaign, in the hope of getting "more witness votes".
We have seen in the past 3+ years that RPC nodes are constantly up and down and their up time could be a "measuring stick" for any such distribution of HIVE (as suggested above). Will not go further into the metrics of something that is not yet on the drawing board.
As for the figures, I pulled them up from old files I had. If they are not spot on to the cent, my bad, they are there to give a rough figure so that anyone who is not familiar with the generalities of how printed HIVE is distributed and for what.
Once again, the starting point for the above topic is "not leaving things to chance" and "covering all bases".
Once upon a time, in a distant centralized poophole that got pimped and sold out, there was a very shallow and extremely selfish mentality among so many people.
We now see that mentality being cut off slowly and the vision is not all about the "here and now" but rather the long term of things and it should include (but not be limited to) the long term requirements of our infrastructure requirements. Ensuring what is/shall be required for the days when there are millions of transactions per second.
& thanks for putting in the current figures, guess the inflation has somewhat affected some of the figures I listed. I must be getting "old" :)
It would be possible for witnesses to produce a feed of which API nodes are up (like the price-feed) based on automated API calls like @fullnodeupdate.
This could then be used to create a 22nd position in the witness rotation that went to witnesses running API nodes that were up according to consensus of these feeds.
Many things are possible, but I will emphasize again that there is no reason to restrict this to witnesses only.
Decentralization is also a key factor.
One example, simply for arguments sake:
A person may decide to run an app and have a node up and running with their app being primarily hooked up to their node (with an option to utilize a different node if theirs is down temporarily).
Yet that same person may not want to be a witness.
Decentralization calls for options to be available which are not restrictive. "Options are good" and diversification is a must for decentralization to be nurtured.