First, I'm really glad to hear that it's open-sourced. As I mentioned in another comment, I haven't had a chance to research even Hive's apps much, so I made an unwarranted assumption. Right now, I mostly only know about the Hivemind dApp, as I'm managing one of our two teams that works on it.
So, from what you've described, there's three things that could potentially be done to decentralize it more: one is easy, one is mildy challenging, and one is hard.
The easy one is make sure there are several API nodes operated by different people (and maybe this is already the case, for all I know).
As a mildly challenging task, it would also be nice to provide some way to allow users to verify that the different nodes are supplying the same data. This is actually going above-and-beyond what API nodes normally offer on 1-st layer blockchains, but I think it would go a long ways towards increasing trust in dApps.
And for the hard task, it's a problem specifically related to the Hive-Engine application, which is in some cases handling tokens on multiple blockchains. However, it should also be emphasized that this problem doesn't apply to tokens which only "exist" on the dApps 1st layer blockchain. Such "single blockchain" tokens should be safe to trust, because they don't require a trusted gateway operator.
BitShares, a decentralized exchange that many people here will be familiar with, suffers from the same problem, where individual API operators have to run the gateways between the blockchains. Such gateways between blockchains have to be implicitly trusted, and this is a big weak point, which has led to user losses in several cases that I know of, when a gateway operator didn't properly fulfill their obligations.
The only potential solution I know of to this problem would be to put code into both blockchains that allow movement of the token between the blockchains in a trustless manner. This can theoretically be done using proofs based off the same types of hashes that allow a blockchain to verify its blocks. But this is something of a "holy grail" for blockchains, and it gets particularly difficult when trying to bridge tokens between blockchains that are implemented differently in terms of their consensus mechanisms.
As a final note on this subject, it's also worth pointing out that smart contracts don't offer any advantages over 2nd layer apps in terms of decentralized apps that manage tokens that can move between blockchains. A trusted gateway is still required, unless you can solve that hard problem above to allow trustless interblockchain transfer.
Thanks for this reply. As far as I know there were a few people who ran their own API nodes, but I'm not sure if that's still happening. There's really no incentive to doing that at the moment which is a problem.
Regarding verifying that different nodes are supplying the same data, I believe this is already possible since Hive Engine actually makes its own blocks that include the transactions in a single Hive block that are related to Hive Engine and their result. The Hive Engine blocks have a hash which includes the hash of the previous block, so you should be able to compare the hashes of the same block number between Hive Engine nodes to easily and quickly verify that they are the same. I'm not 100% certain about that, but pretty sure that's how it works.
Finally, about moving tokens between chains in a trustless manner, I agree that this is a "holy grail" and I know of projects like Cosmos that are implementing that across a number of chains that support custom smart contracts on the base layer. I don't know too much about the details of that, but I think it would be amazing for Hive if we could add something to the base layer that would allow the trustless transfer of HIVE to external chains. I would be open to supporting that type of project via the DHF or otherwise assuming it's feasible and there was someone who could actually build it.