Ryan, have you read this thing? What do you think?
It is really like the old protocol, or at least it shares the same problems and doesn't propose any revolutionary solution to any of them. The interesting part, however, is that it abstracts away the "intraledger" problems that the Old Ripple protocol was trying to solve -- the commit problem -- by assuming there are many different ledgers and each one of them can deal with these issues internally.
I really liked this abstraction (note that I am saying "I like it", not that I have any proof or 100% confidence that it will actually work), because it deals well with the idea I've had for a time, that perhaps a fully decentralized Ripple ecosystem and protocol would not be needed, but instead there could be many centralized ledgers (i.e., many Ripplepays) and, if they were successful enough, they would somehow find a way to make interledger payments (I didn't use the term "ledger", though).
The "somehow" part is tricky, but I've always assumed a certain amount of trust between ledgers (not between participants) could exist and that would not be a big problem if we reached a state in which there were many ledgers and these ledgers were big enough to be trustworthy (which is perhaps a little bigger than Mt.Gox).
The ILP, however, tries to do more: it tries to achive interledger payments between ledgers that do not even know about the ILP, requiring only that these ledgers provide an internal escrow system and that a connector is willing to act as a bridge between two ledgers. This is interesting and would work in a world of many ripplepays, but then the problem of the commit appears again, in the same shape as before. And they pretend they have solved it by two methods, AFAIK both already (somehow) discussed in the Ripple old protocol discussions and both imperfect: (1) notaries coordinating the commit, which seems to me like a poor solution, even though they came up with a Byzantine Fault Tolerance argument, that doesn't hold well against organized attackers; (2) backwards execution of transactions, which is perhaps better, because it assumes the escrows will guarantee the payment and the participants have the correct incentives to proceed with the transaction (namely: if they don't, they lose money), but there's always the problem of timeouts, honest participants losing money because of software problems in the middle of the transaction, and ledgers having to adhere to a specific escrow protocol (not so specific, but indeed an automated releasing of escrow funds based on cryptographic signatures, I can't imagine a normal bank doing this, for example).
Sorry for the previous paragraph, I was trying to organize my mind.
My (provisory) conclusion is: since the Interledger Protocol already assumes a lot of trust and is still complex and fallible, maybe, for people interested in the Old Ripple way, it is better to build many ripplepays, see if they grow, and then use trust to coordinate payments between ripplepays. The "use trust" part I'm referring to would be to use the same protocol specified in the ILP paper, but with each ripplepay server involved in an interledger transaction acting as the notaries and escrow at the same time, so eliminating a lot of the complexities.
I would like to know if this ILP is being read by many people and if someone is thinking about implementing it somehow outside of New Ripple, or if there are criticism or praise to it somewhere on the internet.