Ripple is a big unknown for most people, so is Bitcoin. Combining them together is like unknown2. I don't see how this helps.
Ripple should be able to prove itself in the fiat domain first. In fact its usage should be growing fast with conventional currencies. Then it might be shown to complement Bitcoin.
It is true that this is a combination of two complicated concepts; I think we need some way for people to trust and accept the system without understanding all the details.
Ripple without Bitcoin is much less secure, since traditional currency is not "machine-verifiable" (you can not check with a computer program whether someone has a certain financial reserve). Bitcoin without Ripple is too slow for some applications (esp. POS transactions) and scales very badly.
This brings me to the reason why I can't see myself ever using Ripple:
money destroys friendships.
If I need to borrow money, I want that separated from my social life. So I go to the bank and deal with them. If I fail to pay the loan back then it is my problem with my bank. It is dirty washing which I do not need flapping in the faces of my friends. With my friends (people I might
theoretically trust with money) I play golf or go fishing. But as soon as money is
actually changing hands in the relationship, it is not much fun anymore.
Ripple is probably a killer-app in India and its satellite countries on the subcontinent, as they have Grameen (micro) banking.
http://en.wikipedia.org/wiki/Grameen.
In Western countries people want their financial affairs separate from their social life. I just can't see that changing.
You don't
need to make payment links with your friends; in fact, because of the reasons mentioned by you, I think it's reasonable to only make "business-related" links (with traditional banks if they want to join the system, or with Bitcoin exchanges, or with some shop, with your employer & so on). You're free to choose. Having said that: I think that, between responsible friends, a "shared property" construction is less stressful than a "debt" construction.
I've seen multiple times that people respond to this thread without realizing that my concept works with "shared property" instead of "debt". On the other hand: I just realized that allowing for "debt" will solve the deadlock problem I described earlier. I think both concepts can easily be combined in the same software; the user should be able to configure per-link what is allowed and what is not allowed. The trade-off between the "flexible but unreliable" concept of debt and the "rigid but reliable" concept of shared property should be made by the user, not by the software designer.