BGP is essentially a fully-trust based flood fill algorithm, these days with some manually-maintained filtering rules to make it not completely trust based. It's not really applicable to something like Ripple.
I think for Ripple it's best to give up on the idea of decentralized routing. Just do a Satoshi and scale it through brute force. Every node has full knowledge of the trust relationship graph. You can then use one of the well known graph routing algorithms on it (A* or whatever).
Actually, maybe it's really simple. You could pull a satoshi in the sense that you're broadcasting most things throughout the p2p network, but I don't think you necessarily need all nodes to maintain a global view of the trust network…maybe it's as simple as this:
What you want to implement is a p2p "Market" (as described on the proposal), but I prefer to leave that for later.
I'm reading about zeroMQ and it seems very interesting. Maybe it would be a good choice for implementing a simple prototype.http://www.zeromq.org/
The more I think about this, the more changes I want to make to this draft. It still has lots of holes. I'm going back to specification and later to design.
I also want to support chains as timestamper and accounter without acting like Minters. A chain that allows users to issue their own tokens. We could call iouChain or somethign like that. But scalability and DoS attacks scare me there.
Anyway, there would be three types of tokens:
1) Tokens: Issued and accounted "centrally".
2) TokenCoins: Issued "centrally" (by anyone) and accounted by a chain.
3) Coins: Issued and accounted by a chain.
*Better ideas for the names are welcomed.
Any combination of them should be tradeable atomically. When a chain is involved, the protocol should be able to "compile" to a bitcoin transaction the part that needs to be solved in that chain.
When one of the "currencies" involved is not a basic token (but some of the two type of coins), its chain must be the timestamper (maybe a timestamper is needed if we consider "green addresses" transactions, but I'm not sure we should).
When more than a chain is involved, contracts are needed
. I can imagine a trade with more than two chains by adding more secrets, but maybe there's problems I fail to see.
Would an atomic trade like this be possible and secure?
A gives btc and gets nmc
B gives nmc and gets usdCoin
C gives usdCoin and gets btc
SecretA enables B to gets the usdCoins by revealing secretB, which enables C to get the btc's if he reveals secret C, which enables A to get the nmc's using secretA (which is already public).
A must sends his secret to C for him to sign his payment, etc.
Mike, do you see any problems with a trade like this?