Is anyone still working on this?
Yes I am! In fact, if I can find and secure the funding, I'm prepared to give up my job to work on this for a couple of years (going from prototype to production-level quality and features, and maybe some marketing).
For now, progress is stalled because my computer is broken and I'm being kept busy with other things. The following parts are implemented:
* Automatic connecting with peers, authentication of messages exchanged with peer
* Partial implementation of distance-vector routing
While my computer is being repaired, I've continued mentally designing the software. For the first prototype I'm going to remove routing altogether: the first prototype will simply try every possible route. This will scale very poorly with network size, but it will work reliably and it's simple to implement. Besides, routing can always be added later as an "optimization", so I consider it a valid trade-off, to allow the prototype to be finished ASAP.
I've also been thinking about the next steps in implementing this. I think the transaction sequence should be something like this:
payee->payer: description, amount, hash, {meetingpoint, ...}
payer->payee: OK(hash, meetingpoint)
payer -> node 1: makeRoute(meetingpoint, amount, hash)
link: state A
node 1 -> node 2: makeRoute(meetingpoint, amount, hash)
node 2 -> node 1: routeFailed(hash)
node 1 -> node 3: makeRoute(meetingpoint, amount, hash)
etc.
node N -> meetingpoint: makeRoute(meetingpoint, amount, hash)
meetingpoint -> node N: haveRoute(hash)
etc.
node 1 -> payer: haveRoute(hash)
link: state B
(same protocol from payee to meetingpoint, with -1*amount)
payer -> payee: haveRoute(hash)
payee -> payer: haveRoute(hash)
payer -> node 1: lock(hash)
link: state C
etc. to meetingpoint
etc. from meetingpoint to payee
payee -> payer: commit(token)
payer -> node 1: commit(token)
link: state D
etc. to meetingpoint
etc. from meetingpoint to payee
payee -> payer: OK
State A: amount is reserved for this transaction with a small timeout
State B: amount is reserved for this transaction with a large timeout
State C: amount is locked for this transaction by updating the link's "Bitcoin transaction"
State D: amount is unlocked for receiving side by sending the token (and signature, depending on concept)
I'm not sure yet whether the "small timeout" vs. "large timeout" difference is necessary.
Could a fork of Ripple be created where XRP is replaced with a less sinister crypto-currency such as Bitcoin? or are there big technical issues?
I'm not following in detail how Ripple is currently being implemented. What is this XRP thing? If I understand correctly, it's a pre-mined crypto-currency which is for some reason needed (needs to be destroyed?) to set up Ripple links. As far as I can see, we don't need something like that.
Links can be set up and destroyed at will, and if you use distance-vector routing there doesn't even need to be a global database of existing links. You need some sort of addressing scheme for the routing table entries (the meeting points); to avoid ICANN-like authorities, this can be a simple hash value. 160 bits should be sufficient for global uniqueness (otherwise Bitcoin is in trouble too). To avoid DoS attacks by route-table-spamming, a proof-of-work can be required for meeting points.
