This document describes how a user might use another endpoint as a proxy for sending and receiving payments, as well as for setting further proxies to form a proxy chain. The purpose of this is to obscure the true source or destination of a transaction to other transaction participants as well as observers.
The recent protocol design allows for obfuscation of endpoints by onion routing, so there is probably no need for transaction proxies. Furthermore, tunneling gives an infinite number of possibilities for obfuscating the source and or destination of any message in the network.
The first step to setting up a proxy is to build a secure communication channel, either directly with the proxy endpoint's server, or indirectly over the trust network. The former reveals less information to the local trust network, but the latter reveals less about the proxy to the originating user. (It would also be possible to learn about the endpoint's server by requesting the information through the network, but that might not be that useful, since the proxy endpoint probably wouldn't want to reveal that to someone who didn't already know it.)
Once there is a secure channel in place, the originator can use it to send instructions to the proxy, which can then carry out those instructions. For example, to send payment through the proxy, the originator would tell the proxy the payment instructions. The proxy would obtain a commit key signed by the ultimate recipient and pass it back to the originator. The originator sends a promise forward to the proxy as though he was going to pay the proxy, but the promise is only redeemable by a commit message signed by the commit key known only to the ultimate recipient. Therefore, the proxy sends promises forward to the ultimate recipient, obtains the valid commit message, and redeems the payment back to the originator.
To chain multiple proxies together, the originator would request that the first proxy set up a second proxy, using a key provided by the originator to set up the secure communication channel, so that only the originator can send and receive messages to the second proxy. To send to the second proxy, the originator encrypts a message to the second proxy, and then encrypts that message, plus an instruction to relay, to the first proxy.
Note that the second proxy can't tell whether the first proxy is acting as a proxy or as the originator. Similarly, the first proxy doesn't know whether the originator is acting as a proxy or not.
The general name for this kind of setup is Onion Routing.
Originators would likely have to pay for proxy services. This could be negotiated when setting up the proxy.