Details for the trust system

Ideas of possible technical details for the trust system

(The below description is a mere draft; it presents different possible ideas among which some choice will have to be made).
In a first step, is the question of how users can enter the data of trust declarations. Here is a description of a method based on the contacts list.

Declarations of trust between users

For the following, each user can decide for each of his pseudos if it will be a "protected" pseudo or not. The meaning and use of this is described below.
Each user has a list of contacts, that is, pseudos of people he corresponds with. (So a "contact" means a pseudo of another user). One can access an information page about a contact by clicking on it in the contacts lists, or when it is not yet listed, by clicking on it as the pseudo author of a message one reads (and this way one can add it to the contacts list).
This info page shows what oneself decided about this contact, and some information that the computer tells about it, as described below.

One can declare to the computer, then possibly modify later but archives will be kept, the following information:

A relation T of trust given, with two variables : x,y with values in the below set of trust values, where x is a pseudo and y is a contact, which says: "I, under the name of x, declare this trust to y".

The possible values of trust declarations are the following:

No declaration
Credit : see this theory of credit (prototype and classical interpretation model only for now): each credit is measured by a quantity of money. A little quantity of credit is near to no trust but opens the possibility of micropayment.
Trust T(x,y) by a pseudo x to a contact y: is a stronger trust than credit and trust reception (and thus implies trust reception). A trust declaration requires to have done a credit declaration of a nonzero value, and will carry a value in relation to this credit (the value of a trust must be strictly positive, else it is no trust. Or, we can require the credit to be higher than a certain value to allow for trust). The value of this declaration is defined as the minimum quantity between the credit given and the quantity of money the other can still afford to pay to oneself; to let this last quantity remain nonzero, one can make 2 kinds of credit: one can be normally used and the other ("trust reserved credit") is reserved for giving a value to the trust declarations, that will be used only as a guarantee given for the case the person is found dishonest.
Eventually we can consider the following option: "Trust receptions R(x,y) by a pseudo x from a contact y", which means: "I accept to let my pseudo x carry (= be guaranteed by) the possible trust declared by y's user (under whatever other of his pseudos) to whatever of my pseudos". This will be called the power of attorney that x gives to y (or their owners). (One of the implications will be that when R(x,y) and T(y',x') where x' is another pseudo of x and y' another pseudo of y, and someone complains against x, then y's user can become aware that x and x' belong to the same user). Note that there will be restrictions on one's right to reduce the R relation, especially if it has consequences to the "transitive relation" below.
Negative declarations: weak, average or strong complaint, or antispam complaint against this person. (Antispam complaint is not comparable with strong complaint, it is treated differently...)

A text of explanation must be attached to any complaint, and can be optionnally attached to trust declaration (recommandation letter).

Trust is primarily not a quantity but a boolean information (yes/no) on whether the person is trusted.

(Eventually one may consider to quantify it as computed from trust values, which would give a value lower than reliabilily, so if the reliability is zero then the person is not trustworthy relatively to oneself : this question may need further study...).

There are different possible definitions to be considered because conflicts mean there are contradictions in the logical system:
- One considers oneself reliable
- If A is reliable and declares trust to B then B is reliable
- If A is reliable and complaints against B then B is not reliable.

And it is the problem of how can a self-contradictory logical system provide answers anyway.

Solving contradictions is what complaints system is here for.
But the complaints system, by including automatically in discussion the truster of someone involved in a conflict, raises the question of how to ensure someone's anonimity, that is, not revealing the fact that different pseudos belong to the same person. Indeed, if you have two pseudos A and A', then a spy could discover this fact by declaring trust to A while making a foolish complaint against A'. The automatic involvement of trusters of A in the trial would be a way of revealing that A and A' are the same user.

First possible definition for an implementation

Define the trustworthiness relation between all registered pseudos, by:

T'(x,y):= (T(x,y) and y is not protected) or (T(x,y') and R(y,x')))
where x and x' belong to the same user, and y and y' belong to the same user.

Compute the transitive relation generated by these declarations with status "Trust" between pseudos. Call T1 this relation between pseudos.
For each pseudo x, compute the set of pseudos z indirectly distrusted by x, that is, Z(x,z) if there exists a pseudo y with T1(x,y) and y made a strong complaint against z.
For each x, only consider the only declarations made by pseudos that have not the same login as a pseudo z such that Z(x,z).
Compute the transitive relation generated by the declarations of "Trust" among them. Taking the same x as origin of these trust chains, it gives the new relation T2(x,y) as "Clear indirect trust by x to y".
So, when x sees the pseudo y, the status of y is displayed, be it T1(x,y), T2(x,y) and the text of the complaint against y if Z(x,y).

Second possible definition

In his contacts list, each user A can choose to trust a contact B or not.
If yes, he does it under one of his pseudos, not for any public info but only for B's display. Then B will see it either from contact list (if he choosed to put A in its contacts) or anyway by clicking "Trust received" on the left margin of its contacts list, that will show the list of users that trusted him. He can validate or invalidate the trust received. He can choose what is default for new trust received: valid or invalid.
(invalidation may be chosen for anonimity reasons towards that person, for further developments).

When a trust declaration is not validated by the receiver, it should be still used only for computing trust from the viewpoint of declarer (for his display), without using it by those who trust him.

(This concept of validating received trust to protect anonimity might not be the best solution for this problem, we can think about it more - but to understand it, we must explain how will be the complaints system).

The above version will facilitate the working of complaints system, while not dividing a user into his pseudos and still protecting anonimity not bad. It will automatise the fact of disagreeing with the people who choose another party, while giving it a more anonymous form and updating everything all right every time someone changes his mind. It also makes complaint automatically symmetric.

Third possible definition

without requiring the formality of validating trust received, while preserving a reasonable anonimity. So:
Trust will be valid automatically, and it is not even necessary to choose a pseudo to declare trust under it.

The protection against anonimity breach is weak, and just based on the fact that the person called in a trial would not be informed of what is the trust declaration that is the occasion for this invitation, nor if it was made to the person directly accused, or just to a defender of any party, or anyone else taken by chance...

But this raises a question: will there be a possibility for someone to know if he received trust from someone, and from whom ?

Not knowing it can have an advantage: to prevent blackmails of the form: "You must declare trust to me, or...".
It has a disadvantage: someone who betrays, does not know who he betrays, that will be held responsible for having declared trust to him.

Additional remarks

Then, the computer will compute the transitive relation generated by the relation of valid trust declaration, for giving each user the possibility to see (when displaying someone's info) if he indirectly trusts someone or not. This question need not update every minute, but every day is OK. For this, it may be useful for the server to regularly (every day ?) make a map of all users by equivalence class, where 2 users are in the same class if one indirectly trusts the other and conversely.

We can consider developing the additional function to find the shortest paths between 2 points.

But we may be unsatisfied with this result if we want to have a means to find back the shortest trust chains between two points. A computation method of the shortest path is known along the following lines:

if N is the number of users, we can define for each user two tables with slightly more than sqrt(N) entries made of
1) the people he indirectly trust,
2) the people that indirectly trust him,
by chains of trust no longer than a certain number. Each table gives the parent and the length of the chain from the considered user. Then, to find some shortest trust chain between 2 users we just need to see (if one is not already in the other's list), what names appear in the two tables. But most of the time, what will be needed is not all the trust chain but the first and last elements of this chain. So, we can put in the table of user x, for each user y that has a trust chain of length no longer than () with x, what are the end elements near x and y, for the chain of minimal length. Unfortunately, it may not be unique.

For each message one reads one can see or ask the information of whether there exists a chain of trust (and what length) from oneself to the author of this message (or else existence of such a right for how many people) starting from the commitment of the author. (Or, consider other questions one can ask ?? to know whether a complaint can be efficient). One can also see if there is a chain of trust from oneself to someone who complained against him, and see the text of complaint.
The problem is to do it so that it can still handle tens of thousand users without saturating the computer resources (cpu and memory). It would be possible to have the result in a rather compact form made of the list of equivalence classes of users (or pseudos) so that two users are equivalent if there is each is trustworthy from the point of view of the other.

Complexification by network of independent servers

In short:
The trust system will work as a combination of the data of the local graph of trust between users of the same host (working inside the "black box" of the host, therefore with no need of electronic signature) and the web of trust between different hosts (with electronic signatures).

In details:
The site publishes (with signature) the subset of the ordered set defined by quotienting the set of users by the equivalence relation of the preorder generated by the trusting relation.
Hopefully this ordered set is made of only one element, so that there is nothing publicly revealed of the internal structure of the site.

Each server will first make the map for trust relations among its own users. So, for the subgraph of trust between its users it computes equivalence classes and publishes it for other servers, without saying how many people in each class, but only as the list of abstract ids of classes which contain users who received a trust by a user of another server (the classes who receive no trust by outside are known but stay invisible in the published map).
So it publishes a list of abstract ids with the info of the relation of indirect trust (by internal chains of trust) between classes, and of trust from its own classes to the classes of other servers. Then, when a user A wants to know the trust to a user B, A's server requests B's server about which class B belongs to, or if B is not in a published class, which classes trust B. Then uses the union of graphs of all inter-site trusts and local trust.

Declaration of any trust or anything else between members of different sites are published as "a member of this class here trust a member of that class of that other site".

Complexification by different types of trust

There will be standard trust, but other trusts will be handled in parallel according to the same logic.
Any user can create a new kind of trust, called membership.

A membership is another graph of trust which is computed the same way, with

- Only users who choose to be members of this graph

- Trust declaration for this membership, which is separate from usual trust (but I think it should be necessary to trust someone normally to be able to trust also this way).
A membership can be public or private. If it is public, it gives non-members the possibility to view this trust towards people from the viewpoint of some existing member (who accepted this).

Parties and complaints

Roughly:
A system of complaints declarations against someone, or someone in a forum, that will open a forum to discuss the complaints, and that will invite to the discussion the people who trusted the person target of the complaint (we don't know who but the computers can forward), so that they can respond or revise their declarations.

In details: A complaint requires to start from:
-either an existing private forum where the person was involved, which will be transformed into the trial
-or anything where the person made an action, that will be the object of the complaint; then the forum of trial will be created with reference to it.

First step is warning. It has an explaining text or message, that the accused person will see on his screen at his next login. This text is the first message of a new forum with a reference link to the original text complained against. After he logs in and received this warning, he will have one more day to answer, and can also complain back. If one is not satisfied, one can pass to the next step:

A pair of opposed parties is created. First each party has one member: the complainer and the accused person.
Each party must have a head and may internally define a membership among its supporters (see above) who can edit a wiki that presents the defence of this party.

The pair of opposed party has a forum where both parties can argue, with other people sollicited to support either.

It will induced a modification of the normal trust computation, in the following way.
For each pair of opposed parties, each user can choose to be either neutral (by default everyone is neutral) or supporter of (only) one of both.
Suppose there is only one pair of opposed parties (if there are several, the question of what should be computed would be problematic if one wants to avoid exponential complexity but I think of a relatively satisfactory solution).
The one graph of normal trust will be replaced by 2 graphs of trust to be computed independently: one G excluding the supporters of one party, the other G' excluding the supporters of the opposed party. Then, when A asks the computer whether he indirectly trusts B, the answer is defined by ((A indirecty trusts B by G) OR (A indirectly trust B by G')).
So, if A is not neutral but supporter of one party, he will only consider trust by the graph excluding the supporters of the opposed party.
If there are N pairs of opposed parties, it would not be rational to compute another graph for each of the 2^N ways to take parties. So, instead, for each pair of opposed parties there will be 2 graphs of trust as if nobody took any other party, and also a synthesis into one graph or relation, for computation by another server busy with another pair of opposed parties. But to make computation approach approximately the taking into account of an opposition when computing other opposition, we will consider as invalid any trust declaration between supporters of opposed parties.

The invitations to the forum, of the trusters (which means, a pseudo y such that C(y,x) = Trust ) (or a subset of this set, decided how ??) of supporters of the involved parties will happen progressively (at which rythm ?) depending on whether participants consider that they need to extend the conflict, or whether they are many enough and just need time to debate.

The conflict can run into the following states, to be chosen by heads of parties: to be weak (without effect on trust, but just for debating and clarifying problems), then medium (with this effect on trust), then strong (with public note on profiles of anyone in none of G and G'.
But we can also consider the possibly for a user to support a party weakly or strongly, in the same spirit (this complexifies the trust calculations as parties will have strong supporters and weak supporters).

A possible further development about credit

The following quantities can be computed about a user y for the account of a user x:

One is the affordability, that is, how much y could afford to pay to x at a given time as defined in the theory of credit, when not including the trust reserved credit as a credit. Note that this affordability relation is transitive, in the sense that the affordability of x towards z is always higher than or equal to the minimum between the one of x towards y and the one of y towards z.
One is the reliability, which is the same as affordability except that it includes the trust reserved credit among credits (so, it is higher than affordability). This quantity is also equal to how much x can obtain to be paid back for damages done to him by y once y will be complained against if x did not make mistakes in his own trust declarations.