P2P Protocol

IT is necessary for OT Clients, eventually to go PEER TO PEER.

Why?

1. The OT peers must "compare notes" on the public minting files (for untraceable cash) in order to keep the server from secretly tracking them by substituting a different mint file for one of the users. The users thus have an incentive to compare notes on the mint file.

2. The OT peers must communicate when they wish to negotiate key exchange, or to send each other a list of the server IDs and asset type IDs that each accepts. (Allowing their wallets to negotiate a mutually acceptable asset type, or otherwise satisfy any requests via other avenues such as Bitcoins, or Ripple.)

3. The OT peers will implement some Ripple-like scheme, if not Ripple itself. The idea is for the peers to have rules about what percentage cut they charge for converting one asset type into another. This way, payments can "ripple" across the social web, the 6-degrees of separation from one party to another, and even changing asset type at each hop along the way, so that two people can pay each other even when they do not even deal in the same currency types.

4. As Ripple is already p2p, so are Bitcoin nodes also p2p. Bitcoin is special because there is no central issuer. As a result, it will operate as a glue between OT servers, with users converting to BTC (on OT markets), taking the BTC to another server, and converting back again. Bitcoins are thus the "Universal Medium" and good wallet software for OT will probably have Bitcoin client software built it, along with the ability to convert in and out easily from real Bitcoins into OT accounts backed in BTC.

Why would Bitcoin users do this? Instant finality of settlement, untraceability, and to gain access to OT instruments such as MARKETS (such things are already being built in the Bitcoin world anyway, to serve legitimate needs, so therefore OT is also of value in the same way.)

---

Thus it is clear to me that OT has a p2p future on the client side, and federated on the server side (see FAQ for more discussion on this.)

This leads me to... implementation of the p2p clients. Preferably this is not done within OT, although certain additions to the OT API may become necessary to support this functionality.

Preferably some new component would do the job of making those OT API calls, in conjunction with calls to a P2P communications library (SUGGESTIONS?) -- this new component would be the core of the OT P2P universe, and preferably would be incorporated into many different actual client software implementations.

Are there any P2P experts who might pitch in here with some thoughts?

I think it would be cool to design it such that swapping out the transport layer is really easy. Like, for example, to use Speakeasy as the "p2p library" but to be able to swap it out for another lib with ease.