Even without a convention for which input/output is used, the car knows the last transaction that transferred ownership, so it knows which input/output to look at.

Yes. The smart car just looks in the chain to know its owner. That's why this use case cannot be implemented with the conventional ripple protocol, where the current owner is only known by the issuer (the car producer). But other smart property cases can i. e. bonds. It has the advantages and disadvantages mentioned before. I think both systems will be used for different purposes and users.

Is this the pybond project mentioned at the end of the State of the Coin 2012 slides?

That is one distributed bond effort, yes.

There is no Official Blessed Distributed Bond effort; each developer just scratches their own itch. In pybond's case, I am writing a basic distributed bond implementation, with no pay-to-policy stuff, just to prove the basics work.

So does it work? People willing to use command-line python script(s) can now issue bonds to each other and such?

Is this the pybond project mentioned at the end of the State of the Coin 2012 slides?

That is one distributed bond effort, yes.

There is no Official Blessed Distributed Bond effort; each developer just scratches their own itch. In pybond's case, I am writing a basic distributed bond implementation, with no pay-to-policy stuff, just to prove the basics work.

So does it work? People willing to use command-line python script(s) can now issue bonds to each other and such?

They will be able to soon, yes. "am writing" Right now the P2P network and DHT framework are being debugged. Once that works, it will be easy to hook up the rest.

I guess this would be a crazy fork and probably nobody wants something like this but me.

Um, I actually find this fairly interesting. It looks like you're continuing some mailing list discussion here, can you please point me to original discussion so I can learn more?

I believe that a ripple-like thing can be potentially more awesome that "colored bitcoins", but it would be much easier to get "colored bitcoins" up and running so that's what I'm doing now. But I want to return to ripple ideas later...

I have a sketch of a simple distributed ripple implementation which is based on message timestamping. It isn't designed to be compatible with blockchain in any way other than blockchain can be used to timestamp messages to get them into order.

But it looks like you've found some way to make it based on Bitcoin implementation, which might have some advantages, I guess, so I want to learn more...

I believe that a ripple-like thing can be potentially more awesome that "colored bitcoins", but it would be much easier to get "colored bitcoins" up and running so that's what I'm doing now. But I want to return to ripple ideas later...

Actually colored coins are also an implementation of ripple on top of bitcoin. My crazy fork, ripplecoin, is about removing the need to use satoshis as tokens. Let anyone issue as much as they like and separate the accounting of that issued credit (be it bonds, fiat deposits or e-gold) from the "hostcoin" accounting. Jgarzik argues that requiring satoshis is not a disadvantage but a good measure to avoid spaming, but I can't see why fees should fail.

I have a sketch of a simple distributed ripple implementation which is based on message timestamping. It isn't designed to be compatible with blockchain in any way other than blockchain can be used to timestamp messages to get them into order.

But it looks like you've found some way to make it based on Bitcoin implementation, which might have some advantages, I guess, so I want to learn more...

Your proposal sounds pretty much like the current main design for distributed ripple. A two-phase approach in which "registries" (or timestampers) provide the atomicity. The current design is very flexible and allows various commit methods. Here's the main protocol:

But the same concept of transitive atomic trades of credit tokens is also possible with colored coins. The A -> B -> C example I used before is a simple Ripple transaction, for the generic one you just substitute the number of arrows, 2 for n.I don't see any impediment to do it with the rules you have described, it's just about creating the transaction that includes the credit path and all participants signing it.

My only disagreement here is...why credit units need to contain satoshis at all? Why not making the accounting for the credit currencies inside the blockchain (enforced by the protocol) for free when the expensive stuff is hashing and fees must be paid in the host cash anyway?

It's great to have an implementation that doesn't require a fork though.

But can we go further and design p2p low-trust replacements for other parts of the financial system?

It would be a mistake trying to mimic current financial system in its entirety. 3/4 of it is just parasitic add-on built on top of fiat currency system. I'm pretty sure that future perception for bitcoin will change from currency to a broader meaning of transaction vehicle for all financial instruments. The idea for colored satoshis is good one.