ITES - The Trust System Theory of Operation

The system is by nessesity a decentralized system. Each element within it operates autonomously. The elements themselves are individual units possessed by their holder. They have two modes of operation only one of which is chosen at the time of initialization. The modes are Element Mode, and Witness Mode. Element Mode is the main mode of operation. It is a combination of different functions. The core function is the same as the Witness Mode function. This has a database of transaction histories for trust verification and reporting, a communications protocol layer for the sending and receiving of Trust validation requests, and the the storing and forwarding of Value exchange packets for itself and other Elements and Witnesses in it's immediate environment and vicinity. These core functions operate independently of the operator's use, with the exception of the communications channel(s) open and close. Comm channels, when open, are automatically utilized to provide the functionality of the Witness Layer.

All Elements are Witnesses, but only Witnesses are dedicated to the task of Witnessing. Witnesses will be explained later, but they are important for long distance communication of Trust and Value, and exist as repositories of transaction history for the community they serve, and are the local sources of exchange rate and time information.

An Element is the same system with a communications interface for the User combined with a simple double entry accounting system, a plugin system of accounts, all on top of the Witness layer. The big difference between the accounting system of an Element and an accounting system such as is in general use is that the Element uses gold by weight to store value, and computes time and material goods value relative to the gold. The gold is not real gold, it is the Idea of gold. This is the same as the backing of fiat currency, in that the currency is backed, not by something real and tangible, but by the Idea of Debt. Normally, an accounting system would store and compute value in the native currency, but ITES assumes gold as a standard of value and will compute the value in the native currency based on current market price of gold in that currency. The assumption is that gold, as well as the user's assets and time are of a stable value over time, and that the currency is fluctuating.

Currencies issued by central banks are not stable, by design, and so make very bad standards of reference especially in the long term. Gold on the other hand varies only slightly with supply and demand, and the Price at any given time could be anything, not because of the gold and it's intrinsic value, but rather on the current value of the currency it is being compared to. The more inflated the currency, the higher the price in that currency for a given amount of gold. But the value that the gold represents does not change with anything but the gold's weight.

The most important layer is the Witness layer and the transaction protocol. An ITES transaction is simply a request for quote, goods, service, funds, validation, . A typical transaction might begin with a quote. A quote request is sent from the buyer to the seller. The packet is received by the seller's Element and the Seller responds with a value. If the Value is accepted, a request for goods or service is made by the buyer in the form of a Transaction Packet containing a value to be debited from the buyer's Element, as well as the quote ID so that the seller has a record to match the request to. The Seller then delivers the goods or service, and closes the transaction. Both Elements debit and credit the appropriate accounts and the values are transfered.

But where was the Trust? This is the function of the Witness Layer. The Witness is a database of the outcomes of transactions. The data stored is simply a 1 for the buyer and his Element name.number and the a 1 for the seller and his Element's name.number if the transaction completed without trouble. If there is a problem, one of the Elements denies the transaction while the other says it is good, or Both elements deny and the deal is off and unrecorded. Only 0:1 and 1:0 represent a bad transaction with unresolved outcome. 1:1 is a done deal and good, 0:0 is no deal and left un recorded.

The date and the transaction numbers used in the transacton are recorded by both Elements. The Error condition or Flag condition is a bad mark on Both Elements. It is best to resolve such conditions, and that can only be done voluntarily by both parties, otherwise, both parties carry the flag. Any request for verification for either party in the future, will report these flags.

Flags will happen, and ITES is not concerned with why they happen, only that they happened and weren't resolved. Resolution is possible any time after the fact. As long as both parties agree to the resolution, the state can be changed to 1:1 and all values are transfered in full. A flag state can be changed from good to bad after the fact as well. Shoddy work that falls apart some time in the future can cause a user to flag a transaction until the problem is resolved.

Flagging causes the flagger to accept the consequences of a bad mark, but he recovers automatically half the balance of the transaction until resolution or reversal by the other party. The other party reverses the transaction simply by flagging his portion as well. Now the rating is 0:0 and the the other half of the value is returned and the deal is off. The record is cleared of bad deals and both parties have good trust restored.

Some flags will be carried by all Elements as time goes by. Some people are just prone to flagging. They may be difficult buyers, shoddy sellers or both. They may just be foolish or dishonest. They may be just normal people with a couple of bad deals with people who are dishonest or shoddy or difficult. They may be the victims a bad circumstance. ITES doesn't care one way or the other. It simply reports the facts as they are presented to it.

But this rating is not the only thing recorded. The relative risk or investment in the transaction is also recorded for both parties. This is simply the ratio of the transaction value to the Elements total capital per annum. How large a value compared to the total value exchanged in the last 365 days. This ratio would be quite small for a bucket of paint and quite large for an automobile or a house for the average person. But the bucket of paint would be small for a paint company and somewhat small for a car company. But for either the paint company or the car company to carry an unresolved flag is not good. The more of these flags that they carry, the less trust they have to potential customers. Flags can alter a seller's value assessment. If a seller caries flags, the price negotiated will go down or may not happen at all. Those flags are a historical record, and the ratio of flagged transactions to good transactions over the lifetime of the Element is a measure of it's Trust.

Witnesses are Elements that carry a backup copy of a transaction, and as such are repositories of Trust history that can be queried by any Element looking for verification of the Trust values passed to it from another Element that it wants to transact with. Any time a transaction exceeds a value, predetermined by the user, validation is requested from a Witness or Witnesses that have known transactions from that Element in the past.

Trusted Witness Lists are exchanged by the Elements wishing to do business. The Witnesses are contacted and those Witnesses now know the Ratings and Witnesses of Both Parties. If the Witnesses are already on the lists then the Transaction can proceed with only one of the Witnesses in attendance. If the Witnesses don't know both Parties, then a local Witness for one Party will contact a Witness for the other Party and the transaction will be conducted through those two Witnesses. The Witnesses do the store and forward routing between them and both record the outcome of the transaction. They also record the address of the other Witness and the Element that that Witness knows. They coordinate the exchange rates between the two Parties and the time stamp information.

By building Trust relationships between Witnesses, local communities grow in size and scope. For instance, Fred may be an importer of goods in San Fransisco, and Joe is a seller of goods in Hong Kong. Fred found Joe on the Internet or through a trade publication and contacts Joe. Joe give Fred his Element name.number and Fred gives Joe his Element name.number. They may also give each other the name.number of their local Witnesses that they do most of their transactions through. A preferred Witness can be specified in any transaction and the default Witness is the one most used locally. The Witness layer of the Elements themselves will do for a simple transaction, but a trusted community Witness is better. The community Witness knows more about the trust of the Element than the Element itself. It knows how that Element compares to other Elements in the community, and it knows most if not all of the Elements carrying flags on that Element. It's Trust rating is much much higher than the Element itself.

So Fred gives Joe the Witness name.number of the Witness in the community in which Fred does business most of the time. Joe does the same. They enter this info into their Elements when they open an account for each other. Then Fred contacts Joe by requesting a quote for an order of widgets. Fred's Element contacts Fred's preferred Witness and sends the quote request packet. The SF based Witness contacts the Hong Kong based Witness and forwards the packet. The Hong Kong Witness forwards the packet to Joe. But the SF based Witness also sent the Hong Kong Witness a Hello packet of it's own. This packet contains a summary of Fred's trust in the form of Fred's transaction history and ratings, including flags and the flagged parties Element name.number(s). The Hong Kong Witness responds with similar information. Then the Witnesses exchange their Witness lists. These lists are lists of other Witnesses they know, and the Trust they hold.

Witnesses carry flags too. They are Witnesses. They must store a flag if a flag occurs. But a Witness that carries too many flags/transacton-year is a false Witness. It has Witnessed a community that does not conduct fair deals or resolve issues. Witnesses and Elements both carry Lists. These lists are lists of Elements and Lists of Witnesses that the Element has had dealings with. They are Ranked Lists, with the list sorted by Trust Rank first, and by Recent Date second.

When an Element carries too many flags, the other party must enter a PIN to override a transaction pause and to allow the transaction to continue. When a Witness carries too many flags, there is no such option. It is dead. It is of no use any more to the community and should be re-set and allowed to grow a new transaction database. It has just seen too much bad business.

So the SF Witness and the Hong Kong Witness now know each other and they know of other Witnesses they did not know of before. This information is valuable to the Witnesses in their function as store and forward Routers. They have now learned of new networks of Trust, and with time, can establish a higher level of Trust between the two communities. Anyone else in SF who uses the same Witness as Fred, can now do business easier with someone in Hong Kong who uses Joe's Witness.

All a Witness needs to find someone is their Element name.number and their local area or a Witness in their community. Mary has a name.number of someone in Hong Kong that a friend of hers met on a plane. She wants to find them and send them a quote for some items they said they were looking for. She just does up a Quote, and sends it to the Witness in her neighborhood, which just happens to be the same one Fred used to do business with Joe. The Witness sees the name.number and the Area information and forwards the packet to the Witness in Hong Kong that it met in the Fred-Joe Transaction. That Witness checks to see if it has a record of that name.number and if it does, it forwards the packet to that Element. If it doesn't, it passes it on to the first Witness in it's list of trusted Witnesses. This process continues, with each passing eliminating a Witness from the list of tried Witnesses, and adding new ones that were not on the list before. As the packet makes the rounds, Witnesses are learning of new Witnesses by extending their own lists with the list that is growing in the packet. Eventually a Witness is found that knows the name.number and it forwards to that Element, and then sends a Hello to the Witness in SF. The community in Hong Kong got larger by the linking of Witnesses that previously didn't know each other, and the Witness in SF got a better list of Witnesses in Hong Kong back from the new Witness there that just said Hello.

The packet has a time to live. Once a Witness is found that knows the Element being sought, the clock stops and the Witness will store the packet until it sees that Element again, or learns of it's existence in another area through a different transaction by that Element.

Witnesses are the backbone of the Trust system. Their operation can get quite large and their power and maintenance needs must be compensated for. Every transaction that completes as good, exacts a fee. This is a nominal fee of .01% of the value of the transaction. It is payable by both parties and redeemable by the Witness operator 6 months after the transaction completes. The value is transferred by the Elements involved at the time of the transaction, but the accounting system within the Witness itself will not release the funds for 6 months. If a Witness dies from flagging, the funds are forfeit. A Dead Witness is no good to anybody, including the operator. A corrupt Witness is a drag on the community, and must be put down. This is done by either flagging, which takes a toll on the Elements themselves, or by simply Black Listing. Black Listing is the forcing of a Witness or Element in the List, to the Bottom of the List. The List itself is dynamic, but forcing an Element to the bottom is an act of denial of Trust in that Element or Witness. There may be no indication within the system of a failure for that Element or Witness, but news of the Corruption within that community may prompt the Owner of an Element or the Operator of a Witness to down-grade the trust in that Element or Community, so that it is not utilized in the future. This down-grade only affects the Element or Witness for which the owner/operator has control, but does not result in the reporting of the downgrade when the Element exchanges Lists. It simply excludes the downgraded Element from the List of known Elements in it's report, and will not do business through that Element/Witness in the future. In a sense, the downgrading is shunning. In a free and open society, forcing suspision is wrong, but shunning, or voluntarily not doing transactions is allowed.



The fees that a large Trusted Witness can generate are dependent on the trust given by the Elements that use it. If it is corrupt, then the Elements will find another Witness.