Messaging

Open Transactions is agnostic to transport. Meaning that libOTLib.a, the actual library (containing the bulk of the code), includes no transport code at all. Zero. At its core, Open Transactions is a financial crypto and digital cash library, not a transport library.

Thus, the OTMessage class, which OT uses for all of its messaging, simply serializes itself into string form (like any other OTContract-derived class), and then you can transport that string using whatever form of transport you wish. When you do, a single OTMessage is sent out, and a single one comes back in reply from the server. (That is, OT operates on Request / Response model). This means that OTMessages can be sent over email (if you’re willing to wait for the email reply.) They could be sent even through snail mail. They can be sent over anything.

Using the OT Library, I have written a server, as well as a command-line client for testing it. (As well as an API for writing software that uses OT.) All of these pieces obviously do implement transport. Currently, OT transport in these pieces is written to support two modes: XmlRpc, which is connectionless and runs over HTTP, as well as TCP, (which requires maintaining a connection, and in current implementation, runs over SSL).

Transport is implemented as a callback function—meaning that new modes are very easy to add, simply by writing a new callback function. However, I expect development will focus around the preferred mode: XmlRpc / HTTP.

What is going on inside these OTMessages? First of all, you can’t tell if you’re snooping the wire: whenever a message is sent to the server, it is first encrypted to the public key located in the server contract. The OTEnvelope class is used for doing this — OT simply adds the message to an OTEnvelope, and then seals it using the Server’s public key—now only the server can open it. And when it does, the plaintext OTMessage is loaded up (from string form) back into memory where the server can process it.

Eventually the validation of these messages should occur in a “perimeter service” before being passed to the main server, in order to lessen risk. (TODO.)

One of the central features of all OT contracts is that they are self-verifying. For example, the server contract itself is signed with the server’s private key—and the public key appears in the contract. This means that any user can load up the server contract, read the key out of it, and then use that key to verify the signature on the contract. The user can also encrypt all communications to that key, knowing that only the signer of the contract will be able to read those communications. The user also has pretty good security that any messages he receives, signed with the same server key, are coming from the same entity who signed the original contract. And so on.

Since OTMessage is derived from OTContract, these features are also true of OTMessage. When messaging the transaction server, a new user includes his public key *in the message so the server can verify the signature and encrypt the response message**. Thus, the early messages are self-verifying. If you look at the below “Check Server ID” message, you can see that the user has included his public key so that the server can send a reply back:

-----BEGIN SIGNED MESSAGE-----
Hash: SAMY

<?xml version="1.0"?>

<OTmessage
 version="1.0">

<checkServerID
 nymID="7d1cff65a7febacaa0bbab73fd65032e6620e6501f41961b2be3ad556d891d4f5cab52acc87c07da91fbdc940da865249cb6e0b3a6fe7d66f6b3f8eb94591b5d"
 serverID="4cc4dd50cb6a7d9c7d05240e09daf2befcd189331d69a07f7dd11ed86967de12c9ffd4e3c2d70d0d7a02891e280f2df1fdf05543586840f2bf7b37d4299ad6de">

<nymPublicKey>
- -----BEGIN PUBLIC KEY-----
LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUlHZk1BMEdDU3FHU0liM0RRRUJB
UVVBQTRHTkFEQ0JpUUtCZ1FEZThQMTg3aWkvanpuZ3Z6QmV1QisvYTJXMApQUFNK
NVd0TTFJdTdMWEc1REp2Ly80ekJuUVJqQzd5TXd4Q3VwdFJwZ2JyTHpNbTdmYklF
cXNFMDgvQW41OGtUCjYxK0JXRHpyUjBaVnZBeDNncUdtUXEybWtsZVpsb2FvdXE4
UXRwZHJoVEQwM2VxRDk5cVBRMHdRTWdHRy8rMFAKOEhsVHJtOGY1VFFtVkVuVHVR
SURBUUFCCi0tLS0tRU5EIFBVQkxJQyBLRVktLS0tLQo=
- -----END PUBLIC KEY-----
</nymPublicKey>

</checkServerID>

</OTmessage>
-----BEGIN MESSAGE SIGNATURE-----
Version: Open Transactions 0.40
Comment: http://github.com/FellowTraveler/Open-Transactions/wiki

y0c9qAp9xS7f9/r9HokY70ajoAO92/LhNXvDOqg1Td0TtsvndNX4+rfahat+w2Y5
fbFn9ZAZkFUOqjNE4zPwazRSm93W0SIj1rCyOjWkCYfSFLsGm+YS5oMwRColAqu1
FmdO3SSTMVzLnUGpt4BKGPSct0xr48Rh0l5o6Za0XDI=
-----END MESSAGE SIGNATURE-----

The user registers his public key so that it can be stored on the server side. He might register with many different keys, depending on his level of paranoia. He might also go “cash only” and therefore not register at all, but this isn’t necessary for untraceability (only for anonymity), since even the pseudonymous accounts are untraceable when you are using digital cash.

Your public key is a pseudonym. You will see the words “User ID” and “Nym ID” and “Nym” and “pseudonym” used interchangeably. They all mean the same thing: a public key, (or an ID used to look it up.)

Below is an example of an OTMessage where the user is requesting a copy of his inbox (for one of his asset accounts.) Once you have registered a public key with the server, it does not have to be passed back and forth. Notice the user only includes his Nym ID this time, instead of his entire public key. The server will use the ID to look up the key and verify the messages. Only messages signed by the appropriate key will be processed.

-----BEGIN SIGNED MESSAGE-----
Hash: SAMY

<?xml version="1.0"?>

<OTmessage
 version="1.0">

<getInbox
 nymID="7d1cff65a7febacaa0bbab73fd65032e6620e6501f41961b2be3ad556d891d4f5cab52acc87c07da91fbdc940da865249cb6e0b3a6fe7d66f6b3f8eb94591b5d"
 serverID="4cc4dd50cb6a7d9c7d05240e09daf2befcd189331d69a07f7dd11ed86967de12c9ffd4e3c2d70d0d7a02891e280f2df1fdf05543586840f2bf7b37d4299ad6de"
 accountID="174a6a0be57a8afcb8a8a3be0a0dc85181c1f6266b4d813056ef5b5f9825b6d9e353e0144ecd83ba493ce02fb7d9c4125acbd5caec7cbf69a41c7ddb73f79bbf"
 requestNum="269" >

</getInbox>

</OTmessage>
-----BEGIN MESSAGE SIGNATURE-----
Version: Open Transactions 0.40
Comment: http://github.com/FellowTraveler/Open-Transactions/wiki

mu6uLNV/OVL42bZbuD5lfUQLKfUcsLqyfy5dGfjPiQ3hzuhge4RXqzs1t0wnuS2F
AarWXdxO5+wlu5ZUW/7uJj0IP5dMJcxjWYh/ZBRDInBTH8zXbg6ZvPp+0Ia4nJOx
dsvwNyizqbSnidI5knjaJmusknFWA4r3Cp00fvZQWHg=
-----END MESSAGE SIGNATURE-----

Notice a few things:
1) The above message includes the ServerID. Why? To prevent the message being intercepted and sent to a different server, since the signature itself will verify.
2) Notice also that the message above includes a “Request Number”. This number must increment with each message. Why? To prevent the message being intercepted and sent multiple times. Once a message has been used once, it can never work again, since the request number is now invalid.

Click here to read about transaction-specific messages on OT.