How do you know "what you want" when ranking nodes?
Say you're on a fork, in this process your node will rank all nodes also on your fork high on it's list because those forked nodes agree with your chain, where all nodes on the real chain are ranked low because they disagree with your chain.
Now, I'm not too keen on the technicals so please correct me if I'm wrong, but this sounds rather similar to the banscore system we currently have. If a node sends you invalid blocks (like blocks on a fork), their banscore goes up. If a nodes banscore reaches 100, then your node will refuse to talk with the banned node.
The major contrast I see with your proposal and the current system is that in your proposal nodes at the bottom of the list still hold influence over connected nodes (albeit a small influence). This sounds like it would help with forking (It might not, I really don't know), but it may leave the network open to a DDoS attack as those nodes still maintain a connection to each other even though they're at the bottom of each others lists.
I'd like to see some dev feedback here because I'm really not educated enough to know if this would work in practice.
Actually not, that's why latency takes important role. The node that's first on my list is going to have many disagreements with other nodes causing latency increases. Therefore, it's internal list of priorities is going to change. As a results, it's expected that node will have much higher latency due to overheat caused by rejected blocks with other nodes (that does not count as successful operations), and it will directly cause increase latency towards my node, putting it onto the bottom of the list.
The banscore system was one of inspiration for this, to be clear this is not from scratch. I went through the code in order to understand how we can improve, not replace. As for the Ddos, yes that method could be used to destabilize good nodes, but that's exactly why we are putting a small influence even towards those in forks, on placed on really bad ISP connection. Meaning, they are not necessarily on fork. In this scenario, these are actually helping network to heal until ddos stops. (at least in theory).
The another inspiration about this come from thinking on how to improve steem witnesses model.
And the third one is from real life experience of BGP routing implementation where I was able to confirm that this could be a working model. (Not necessarily for GRC and Steem, but for BGP shows great results so far).