Currently, the transport interface guarantees that contact.id and contact.data will be transported. Additionally, the transport interface reserves contact.transport property for internal use.

The behavior, when transported, of properties used by the example arbiters, such as contact.vectorClock or contact.workerNodes is undefined.

It would not do to simply add these properties into contact.data, because the user might not give a crap that vector clocks or other magic are being used.

One approach would be to require the transport interface to guarantee that contact.arbiter property is transported and standardize around the arbiters using that much in the same way that transports standardize around using contact.transport. This approach allows the user to only care about contact.id and contact.data, while not preventing arbiters to rewrite contact.data based on information in contact.arbiter.