I am concerned being someone who knows ecency inside and out, and also Keychain, and it I cannot comment on PeakD or other apps about this.
"Node Globe Pics" by Dan Zen is licensed under CC BY 2.0
Because running a full-node of any blockchain is expensive, most people don't run one. And if we do, which one? Bitcoin is supposedly the cheapest to run. Then there is Ethereum. Most of us would only be able to use one chain or none at all if we had to run a full-node. It is an unreasonable expectation but it has lead to centralization.
A Single Point of Failure in Ethereum
So many Ethereum apps run via Infuria. In fact, a lot of what Metamask does is connect to some standard RPC node in order to give you "Defi". But is it really Defi when we know if this specific RPC node goes down our coins are as stuck. This is preventable if applications curators run their own full-node.
A Single Point of Failure on Stellar
Stellar applications will tend to go through an interface called Horizon.
There is only one public mainnet node that applications connect to. All it takes is this domain or server to go down and your lumens are stuck. Like with Ethereum, this is preventable if applications curators run their own full-node.
Other blockchains
The incentive structure is similar on all chains. I have the expectation that one node might be run by the devs in order to support the ecosystem but as there is no mechanism to support nodes in the blockchains themselves it seems like we end up with one-chain one-server problem where we have no real decentralization with most end users.
"single point of failure" by maywind72 is licensed under CC BY-ND 2.0.
Hive's Points of Failure
If we have hundreds of nodes that communicate in a decentralized network, then that is the strength of Bitcoin or Hive or whatever blockchain network. But if all of the applications are communicating through some specific server or even a small handful, then we have a real danger of a state actor being able to freeze 99% of all of the accounts on a blockchain.
There are 12 RPC nodes according to 
Libraries Underneath Mitigate things
"Library" by Geoff Coupe is licensed under CC BY-NC-SA 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by-nc-sa/2.0/?ref=openverse.
Hive-JS and DHive mitigate a failure with the default node your application is set to via a "fail-over". It will try another node, should one fail. Now, while you may not use Hive-JS and D-Hive directly. The front end you are using will likely use one of these and automatically this means that a site will switch from one node to another. As application developers, we have to explicitly set these lists of nodes. The list is something that should be in a configuration file rather than hard coded in the source code.
How Did We Get Here?
What we refer to as "Full nodes" on Hive are nodes with public RPC/API access. A person can run hived with the history API if they have a computer capable of that. Should I decide to run one of these things, I would have to cash in quite a bit of Hive Power, Hive Dollar, other cryptocurrencies, and perhaps sell other property. Then buy the necessary equipment. This is money invested that would be a loss in terms of interest I could be earning or mining I could be earning. In short it is costly. These witnesses and node public node operators run these computers at a loss. They could simply run a witness and not accept any traffic from front ends and collect their block rewards.
Whereas it is good for Hive that these users run these public RPC nodes, it is not really benefit them personally. The benefit makes Hive more reliable and they may have significant stake in Hive. Perhaps an unequal distribution of wealth aligns incentives so that there are public RPC nodes. The users running these public nodes include 
What you can do
You could witness vote for those that run and maintain public RPC nodes. Consider that without these votes many apps could not go through a stage where they could run without generating profit because the apps would require a larger investment to start up.
You can vote here https://www.proofofbrain.blog/witnesses . You can also set me as a witness voter proxy if you don't want to bother to think about who to vote for.
We are stuck curating RPC node lists. Perhaps some blockchain solution could be thought up in order to give libraries a more secure access to an automatically updating list. We already have a blockchain for publishing posts and it turns out it can be used to publish structured data. So, suppose I write these functions.
I propose I add the following functions to hive APIs (the client JS and Python library):
store_public_rpc(method : 'hivekeychain' | 'whalevault' | 'privatePostingKey', privateKey: string | null) : void;
get_stored_public_rpc() : String[]
The first stores the list of public RPC nodes to the blockchain via a comment operation. The same permlink can be invoked each and every time. The other one retrieves the list order by the best one first.
If this post gets sufficient support, I'll create a Hive proposal. I will ask 150 HBD/day in order for the proposal for 25 days.
Sources:
https://gitlab.syncad.com/hive/hive-js/-/blob/master/src/api/index.js
https://gitlab.syncad.com/hive/dhive/src/client.ts
https://developers.stellar.org/api/introduction/streaming/