

Just guessing, it likely failed due to:
- Being relatively unknown
- I2P being relatively small
- Java being a non-standardized language
- No data verification (malicious host can corrupt data)
- Poor UI and UX
- The main developer leaving
These are killshots to this type of service as people need to develop/extend/use it - for it to be viable. It is in the right direction, but (similar to many cornerstoning attempts in FOSS) is not handled gracefully.
You make great points, and I will not necessarily refute any of them. This is why I said prior that I wanted a bunch of mathematicians to work towards a solution to this. There are many small and careful considerations that have to be made.
I think a heuristic (simplified model) may work better than trying to flat out solve it. As I said, this is not to refute, just a thought.
First, the problem is fundamentally chaotic (as you’ve said) there is no point in trying to accurately predict (solve) the outcome. Choosing “properties” that tend to be consistent, and then basing “success” off of those may be the more practical option. What these “properties” are would depend on consensus - models have elements you deem important, which may not actually be (as you’ve said). This is just something that needs RFC - hence needing a group of mathies.
Secondly, whatever the solution turns out to be needs to actually be do-able for the average joe. If there is a straight up solution, and it turns out to complex, I think it would be less valuable than a simple-to-do heuristic. If people don’t follow up it’s just worthless - and seeing how long it takes people to do very simple things, we’ll be waiting hundreds of years.
I’ll read the two articles you linked (I’ve read the abstracts) but it’ll be a slow burn.