The Trust-Forum project
Updated April 23, 2008
Project was
hosted at sourceforge, but since sourceforge is now making worse
and worse advertising banners, and it is some fuss of formality to put
something there.
Start of a
user
documentation.
Existing versions
The release Trust-forum-1.3.1, January 15th
2006, is simply here.
It contains a first version of datings.
Here is Trust-forum-1.4.0,
February 1, 2007 (still beta version). It has Global Login System
integrated, that makes it good to replace email between users of
separate implementations. But datings has been separated. It is much
more documented but has some remaining bugs.
Search for more programmers
The programmers who worked until now have stopped, so new programmers
are needed to continue. So if you are or know a programmer ready to
contribute
without requesting a Western level salary, please contact me. Thanks !
Required skills (in draft):
1. Project leader
Required skills: analysing, cooperating, investigating, listening,
written communication, creative problem solving, numeracy, organising,
client-handling skills.
Languages/technologies:
- PHP
- Javascript
- MySql
- familiar with other technologies like XHTML or AJAX
2. Programmer
Skills: Teamworking, analysing, investigating. attention to detail.
Discovering new facts or concepts. Problem solving. Logical reasoning.
Creativity. Good technical knowledge. Ability to work to deadlines.
Determination.
- working in team 3 years or more
Languages/technologies:
- Javascript
- C++
- PHP or C#, ASP.NET
- Mysql, Sql Server
- AJAX
3. Designer, flash theme programmer (may be later)
- Flash
- Adobe Photoshop
- HTML
Later we need:
4. Database Analyst/Designer:
Skills: analysing, cooperating, planning & organising, problem
solving, logical thinking.
Short description of the project
(not all details are here; if you consider getting involved and have
time to spend entering more drafts and details, see here; also there is a standard forum
for discussing the project here).
See user documentation that describes
what
has been done from the user's viewpoint. But it has some remaining
bugs.
Description of the Global Login System (first and core feature that
makes all possible)
- We have a network of independent web servers (with separate domain
names and independent administrators), with each its PGP key pair, and
list of public key of the others (and possibly, to make encrypting
faster, a symmetric key to every other site). All will have some common
functions; each is free to add to it its own supplementary functions.
- Each user has only one account defined by login/pass on only one of
the servers, that is called the home server of this user. The user
always first connects here before visiting any other place that
requires authentication. For a given user, a site that is not his home
server will be called a "remote server". Connecting to his home server,
he accesses his user board that centralises a number of functions,
especially bookmarks, and the list of current open sessions at remote
servers, according to the functionalities described below. Each server
knows the list of all peer servers as we said, but not their respective
users lists, except for those users that came to open a session here
for particular functions (such as forum participation), so that some
options and useful user data concerning these functions can be saved.
- By this same account, the user manages at the same time the data and
operations that he does under several pseudos. (well, we could limit
this to 10
or 20 pseudos associated to the same account so that it will largely
suffice). This ensures the possibility of
anonymity from a public point of view while allowing all operations
that concerns a user whatever his pseudos involved. So this relation
between a user and his different pseudos remains internal to the server
where the account is hosted, while only the necessary information is
revealed outside. This will then let the possibility, for the trust
system, to combine trust and anonimity, by the fact that the graph of
trust considers the different pseudos of the same person to be the same
node.
- Bookmarks from the user board, as well as links from any site to any
other site, will technically consist in a link to the home server of
the user in order to process an automatic authentication of the user
under one of his pseudos, to the target remote server, in a triangular
procedure (home-browser-remote)
- On a remote server, the user is know by an identity like an email
address (pseudo@home).
- The different identities of the same user appear to come from the
same home server but only the home servers knows that they belong to
the same user.
- Registration of a new user in a site happens by invitation from an
existing user of the same site and the invitations tree is tracked by
the admin of this site; inclusion of a new site in the network, is by
invitation, with invitations tree tracked by other admins.
- In later development, this can be complexified to make it possible to
have several pseudos that look like they are not from the same
home. This
ensures a relative anonymity, as the other sites do not know which
pseudos from a given site represent the same user
This way, having one account on one site is enough for doing anything
all over the web without "registering" anymore. With the connection
between home and remote site,
can come some other useful information (like prefered language).
What has been done
- Global Login System has been done and integrated.
- A multilanguage system with translations produced by the users
themselves
- One important goal is to make email obsolete by developing private
forums to replace it, where each forum would have its own rights table
(with even possible variants in the rights systems), that would allow
for communcation between users registered at separate sites through the
global login system.
- In the last version: possibilities of communication by
email (so, with people not yet registered to some site of the network):
email messages can't be received but email contacts can be invited to
participate to private forums. (there was considered to be a webmail
but it had to be restricted and replaced by an added functionality to
contacts system, that can send messages but not receive nor store,
because php programs are not able to access the unix function of
opening new mailboxes).
- invitations system between users in a forum; and invitation by
existing users for registration of new users. Now there is an option in
admin panel to choose whether registration is free or restricted to
invitation by existing users.
The aim of the invitations system for registration, is to avoid spam. This invitation would
happen
in two ways: either directly from one's account, or by email where
messages can include a code for registration. The tree of invitations
inside each site will be recorded to analyse the origin of possible
spam and warn or exclude the inviters responsible for it.
What exists in a first version but should be revised and completed
(This Todo page
is
a bit obsolete).
- Translations system
- Datings system (a new, much optimised kind of dating system, to be
free and will be
able to cope efficiently with millions of users while saving the time
of users. Later, any
other kind of small ads can be considered. The little problem that
remains to be discussed: what exact list of parameters and their values
should be included in this system; in particular, develop a list of
possible interests). The specification is here
See here my
explanations of the reasons why this sort of specification would be
best
Further develpments in plans for the long term
- User web pages and wikis where the author of every page will
be identified by his pseudo of his choice, and with handling of rights
to read and rights to edit. (this will be closely related to global
login system, and will probably be done by the team already at work).
See Wiki specification file for more
details.
- Invitations of new hosts to the network by users of existing
hosts, to play the role of a web-of-trust that handles certifications
of keys with no need of a central certification authority.
- A calendar system with ways to record or publish events, and
display them on time on each user's board
- Between users there will be a system of trust declarations, and
trust
computations (with rules of trust transitivity).
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).
- Then, 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.
Programming langages :
As a software for web servers and also to let people the possibility to
run copies in their websites, the programming language used until now
was PHP/Mysql.
It is open to possible development in other languages if it is not
difficult to find hostings and
if it interfaces well with the rest of the project.
The next step will be the trust system, which will have an aspect of
web interface (now in php), and an aspect of internal computation of
the transitive relation (preorder) generated by a given relation (in
database) between thousands of points. What language would be good for
this ? Thanks.
Detailed description of the project (in the short term)
Relations between users and private forums
- Preexisting or given by others:
- Right to read
- Right to write (stronger than to read)
- Admin right (need not exist) to control the parameters of the
forum, rights to read and write, practice censorship...
A person that has no right to read a forum, one cannot even know its
existence nor make any operation to it.
One can choose to subscribe or unsubscribe to a forum, if one has the
right to read it. This has only a
little use described below, that only makes sense for a discussion
between a closed set of a few people.
Forums are created by any user, and rights are expanded through
invitation:
Everyone can open a new forum he is had admin rights to (if he decides
that
the configuration is with admins, else just rights to read and write)
Everyone (with reading right) can transmit this reading right to anyone
else, with or without subscribing him to that forum (subscribing
somebody else will be called "sollicitation").
Everyone with writing right can transmit it to anyone else.
One can also have a blacklist of people from which one
refuses sollicitation from (depending on their login whatever their
pseudo), and of pseudos he refuses to read messages of.
User interface configuration
Everyone can reorganise as he wishes the visual appearance and
structure of the forums and threads he can access, including
classification of messages (by date or threads), with folders and
subfolders.
More precisely, we can imagine that once logged in we see a list of
boxes in the left margin, like
Inbox
box 1 (429, 2 new)
box 2 (231, 10 new)
Folder 1
Folder 2
all forums
"Inbox" is what is immediately displayed in the main fraim.
"box x" is in fact renamed anyway, the same for "Folder x"
Each box is like a forum organised in threads.
Each Folder is a list of more boxes.
But the description above is just the user interface, that each user
can organise as he likes. Underlying this is the "real set of forums",
each of which has its parameters, and the "reading rights" relation
with
the users. Each user builds his configuration on the set of forum he
has
the right to read, and whose list appears in his "all forums" folder.
He
can configure each forum he as access to, to appear in the box he
wants.
He can also configure each new forum that others will invite him to, to
appear in one or another of his boxes according to his public identity
involved and the state of the trusting relation he has with the inviter.
We could also study the possibility to link conveniently a reference to
another forum or message inside one message.
Later, if there is nothing more important to do, a possible way to
improve the features (but may be difficult) would be to allow anyone to
choose the editing conventions and list of smilies he wants, whether it
be for forum messages or for wikis (admittedly, a given wiki page could
hardly be edited in other conventions but...).
Deletion of messages
Everyone can put the deletion mark on a message to stop seeing it, or
on the contrary a saving mark to keep it in all cases.
The author of a message can censor it or replace it (a replacement is a
censorship of the previous version together with adding the new
version), and those who did not put the saving mark on it cannot access
it anymore.
A message will be physically deleted in 2 cases:
- When the author censored it and nobody put on it the saving mark
- If the configuration of the forum allows it, when all subscribed
people have read and deleted it. (the difference is for the case there
would be newly subscribed or unsubscribed readers).
Email and invitations
Have a webmail integrated in the system, to exchange emails with the
outside by one's pseudos that are also email addresses. Needs no
sophistications, just a simple thing but what is
important that it is integrated, which means that the access is
included in the menu and does not require to log in another time, and
the name before @ in the email address will coincide with a pseudo of
the user. So there will be 2 kinds of pseudos:
- Some serve as an email address to send and can receive mails, and an
inbox will be created for it (unless we include programs of selection
and redirection of messages). So for each such pseudo one has the parts
: inbox - write - sent. These links should appear on a page "my pseudo"
which is being worked on now. Unless we let received message to
different addresses appear in the same list, but then how to still
choose the From: address ? What is simpler to implement ?
- Other pseudos cannot be used as email addresses.
A list of contact email addresses must be included, and when writing to
any of these contacts, a checkbox should say "Send invitation to this
person", with a menu to choose the invitation language. This means that
at the end of the message, the system will add an invitation text in
this language, with the URL for registration containing a randomly
generated code, to let the user register (the registration page already
exists, it just needs to be protected this way).
So it should be possible to re-send the invitation message and code (or
a new code) if it was lost.
And once the person has registered, its main pseudo will appear aside
the email address in the email contacts list, and also in the internal
contacts list.
Another invitation procedure will be to register inside the account of
a user.
In both cases, the new member will appear in the inviting person's
contacts, and the info of who invited who will be stored.
There must be a function to let the admin view the whole chain of
invitations that comes to one or more given user. (This will be useful
especially for the protection against spammers, to see who invited the
authors of different spams).
Links
to webmail components
Multi-language
Let users themselves produce translations into their own language. For
this we need:
- Language files labeled by not only language as parameter but also
pseudo of the author of the version.
- Possibility to display the list of languages which have a version and
list of versions for each language in chronological order, together
with the date of creation and pseudo of author.
- Possibility to display in a table some chosen versions to compare
them (with languages as columns and items as rows - the first
"language" column simply displays the item number)
- As each item (occurence of an expression in the site) has a number
used in the program to call this expression in the desired language, we
should have an option to let this number appear with the item when
using the site, in order to facilitate the work for the people to find
the correspondence between numbers and what they see.
For example, if "subject" is in the variable $item5 then in the site,
instead of "subject" we would see "(5)subject"
Editing mode:
1) There will be a form to enter language editing mode, with :
- checkboxes for existing languages and versions to be displayed as
above
- moreover, what language to edit - under what pseudo, and eventually
what model to re-use. Once clicked "edit" we vould access the editing
form:
2) An editing table like above except that for one language we will
have forms to fill with appearing default values from the model.
When the result is stored, it overwrites only and precisely the
preceding version by the same author in the same language.
When there will be a network of sites, different sites in the network
may need to exchange those data, for example, each time when a user
registers a new language file, this file will be automatically sent to
all sites in the network that has the same items structure (for sites
with another items structure we cannot do this so let us disallow this
possibiltity until we make things more sophisticated).
Trusted network and PKI
Each site will have a pgp key pair, and the list of all other hosts of
the network, with parameters
- Name of the site
- Public key
- A symmetric key just for this pair of hosts, to let secure
communication go faster
- URIs of where to post information (may depend on what kind of
information; for example, authentication requests from a user as below)
- Identity (host and pseudo) of who invited this host.
- date and signature of this declaration
Here is the method to develop the network and maintain this list,
though invitations of new servers into the network by users of existing
servers :
The software to install to a new hosting will contain some public keys
of existing servers already running the software, to initiate the
secure communication with them.
Every declaration once done should be forwarded to all other sites of
the network
Regularly, each site will produce a confirmed updated version of all
the declarations of its users (either separately or globally signed ??)
and send it again to all other sites or leave them available upon
request (what is best ??). The certification of each server B will be
available from any given trusted server A in the form of a chain of
certifications by existing servers from A to B if it exists.
At the start of the above invitation procedure between servers, the new
server C will request from A or B a certification of the key of the
server B hosting the account of C's admin's friend, through such a
chain of certifications from A to B where A is one of the well-known
server whose key came together with the software.
Therefore, the new server C will know correctly the key of B, and can
send a crypted message to his friend in B, that will
recognize it according to content and invite host C to the network.
Later in the development of the project, we could replace the
invitation by the following recognition in two parts:
- Certification of authenticity of the public key, or
equivalently, the authenticity of a message received from a user of the
other site, if the message was received crypted and signed: "I certify
that this message was really written by this user", therefore his key
is authentic because as it is a crypted message, third parties
could not have read it to know what it says and sent another message
with similar content with another key. So this should be easy to
establish.
- The trust to the root of another site, as a trust to the fact that
this other site runs the program correctly and the root makes a fair
use
of his admin right.
Global login system and bookmarks
Each user can put on his account a list of bookmarks. Some are simple
bookmarks. Others bookmarks are those of sites that share the following
protocol, and are associated to one of his pseudos (so
for each pseudo he has a list of such bookmarks). Once logged in in his
usual host1 that contains his main account, he can click there on one
of his bookmarks to host2, so that host2 getting in the request the
previous URL containing the name of host1, establishes with host1 an
authentification procedure of the user.
Technically, the link will be to host1 that redirects to
host2 with crypted authentication request. So host1 will be contacted
first in an authenticated way and
establishes the authentification with host2.
Then he connects to host2, being authenticated there as "pseudo@host1".
More precisely, to relate to the rest of the project: there are two
different kinds of login: the fundamental one is
login as a user, at the user's main account at host1 (in general, each
user has only one main account at one particular host), which gives
access on this host to all functionalities of the project including the
use of one's different pseudos. Then, taking one of one's pseudos, be
authenticated to another site host2, only as
this pseudo "pseudo@host1" and not as a main user, without using the
keyboard, by a request from host1,
that gives access to some restricted set of functionalities that is not
defined yet, and that would anyway remain open to development by
anybody that wants to open a new site that offers new services. These
functionalities may depend on information given by the first site. So
here is a tool by which the second site can recognize visitors as
authenticated as a pseudo from another site.
The method proposed now goes along the following lines:
Denote A = host 1, B = host2, U= user.
1) U logs into A
2) U requests A his decision to visit B.
3) A crypts the authentication information (maybe U's IP, U's pseudo,
time of request, prefered language and what page one wants to access,
and possibly more info in the future) in a compact form to send to B
with its symmetric key with
B
4) A includes this crypted information in the redirection
request for U to connect to B
5) B receives the request from U and decrypts the information, knowing
that it is from A to know which key to use thanks to the info of the
previous URL that goes with the request.
6) If all is OK then U is logged in in B, with session variables
containting info from the crypted data.
Another idea for the future, that would probably require a plugin to
the browser:
when the user logs in to A, he creates a private and public key pair,
sends the public key to A, then A makes a certificate and sends it to
U, so that U can log into any site he wants by signed automatic login
requests with this new key and this certificate.
When U wants to log out, the browser will send logout requests to all
the sites which were logged into by this certificate, then destroys the
private key and certificate.
After this, a next development of the project would be to make a
secondary login form: once authenticated at host2 by the procedure
above, one can create at host2 a new password to be able to log in
directly next time at host2 with no need to request host1, by typing
pseudo + new password. Host1 need even not be aware that such a
secondary pass at host2 is made.
Private forums mixing users of different hosts
The method to "send messages" to users of other hosts will be based on
a combination of the private forums and inter-site authentication:
forums are hosted at the host of their creator, and people can be
invited and contribute to it whatever their host is. Each user will
find it his local box the list of forums he has access to and whether
they are unread (have unread meassages) or not, wherever these forums
are effectively hosted. If they are hosted elsewhere, the link to it
will behave like the above "bookmark", making a user authentication
request to the host of that forum.
Events information (calendar)
I think about organizing events data in a different way that the
scripts of "calendar" I usually see available. What looks closest to
what I am thinking of is PHPMyEvents. The
idea is to not make big tables with days, hours, weeks and months as
rows and colums, but simply make a list of events of interest to the
user, in chronological order with the closest coming ones displayed on
top of the window at each login.
Here are the specifications:
Not all events will be registered in the same table because they would
be too many (with many users), so they will be split into different
tables:
First, there are tables where events will be registered. These tables
will be called "sources".
There are two kinds of sources: "personal" sources and "official"
sources.
With each user account there is exactly one personal source, which
belongs to this user.
Each user can create and manage any number of official sources.
Attached to each official source are the following configuration
parameters:
- Identifying name and title of the source
- A list of admins (to start with, the admin of a source is its
creator). Admins can modify the configuration parameters.
- A list of other people that may write new entries (events) into the
source, and edit only the entries they wrote. (we can consider the
possibility that the people not in this list can still write entries
but it needs validation by an admin or another allowed writer)
- Are the info of this source public or private (reserved for
authorised users). If private, list of those users.
- A default title or non-restrictive list of possible titles for events
(can be empty)- The same for places, times, and categories.
Each source is a list of events with the following fields (the default
values defined above appear in the form of writing a new event, and can
be modified):
- Author (pseudo)
- Title
- Date
- Time
- Place
- Category (ex: concert, theater, rendez-vous, party, exam...)
- Comment
Then, there is a list of pools. Each pool belongs to exactly one user,
but each user has a list of pools.
Each source is a pool.
Each pool has a table of events (the same as above in the case of a
source). And also possibly a table of archived events where events are
moved when they are past by (an amount of time to be configured), else
they are simply deleted.
Only in sources can events be edited. In other pools, events can only
be deleted (forgotten).
Each pool which is not a source has a list of other pools that it
receives new entries from.
If an entry is modified in a source, the modification is also made in
the corresponding pools. Comments are not copied, they will be taken
from their source at each display.
The table of events of a pool that is not a source contains:
- A copy of the parameters from the source (date, time, place,
category);
- Titles of events in pools that may be modified for display
convenience. Or there can be both an official title and a reader's
title.
- The identity of the source (if an official source) or the pseudo of
the
author (if a personal source).
Each pool also has configuration parameters:
- Id and title of the pool (the same as above if a source)
- private or public - if private, possible list of other users that can
receive its entries in their own pool (this contains the users that may
write in it if a source - all newly invited users receive this
invitation of this pool into their pool at their next login and may
subscribe to it or delete it).
- If not a source, selectivity in categories (for each of above pools
or globally, blacklist or whitelist of categories of events).
Each user has his main pool, which is the only private pool that has
his personal source in his list of sources.
- The main pool is the one displayed on the user's board at each login.
This display can be configured with the maximum of time from present,
and number of entries. It can present as columns of the display:
source, title, place, date, time, category. Here, comments are
displayed only in popups by clicking. There is also a link to the full
list of entries that includes their comments, as:
- The contents of any pool can be displayed in chronological order with
all its data including its full comments, and an editing link if one
has the right to edit it.
Each user can forward an event from a pool to another user, so it will
appear there in a pool that may not have the source of this event in
its list of origin pools or sources.
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
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
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.
General links that might be useful
http://php.resourceindex.com/
http://www.phpscriptsdirectory.com/
http://www.hotscripts.com/PHP/Scripts_and_Programs/index.html
http://www.hotscripts.com/PHP/Web_Sites/index.html
User Authentication
User Management
http://www.hotscripts.com/PHP/Scripts_and_Programs/Virtual_Communities/index.html
http://www.hotscripts.com/PHP/Scripts_and_Programs/Email_Systems/Web-based_Email/index.html
http://www.hotscripts.com/PHP/Scripts_and_Programs/Email_Systems/Web-based_Email/index.html
http://px.sklar.com/section.html?id=58
http://php.resourceindex.com/Complete_Scripts/E_Mail_Utilities/
http://php.resourceindex.com/Complete_Scripts/E_Mail_Utilities/Web_Based_E_Mail/
dmoz:
http://dmoz.org/Computers/Programming/Languages/PHP/
http://dmoz.org/Computers/Software/Internet/Servers/Message_Boards/
http://dmoz.org/Computers/Software/Internet/Servers/Collaboration/
http://dmoz.org/Computers/Software/Internet/Servers/Mail/
http://dmoz.org/Computers/Software/Internet/Internet/Clients/Mail/Web-Based/
Classified ads:
http://php.resourceindex.com/Complete_Scripts/Classified_Ads/
http://php.resourceindex.com/Complete_Scripts/Classified_Ads/Matchmaking/
http://www.phpscripts-fr.net/scripts/scripts.php?cat=Petites+Annonces
http://www.hotscripts.com/PHP/Scripts_and_Programs/Classified_Ads/General/index.html
Other programs, projects or works that have some common subject
with this project
DEM project: An open
source micropayment system based on Java, JXTA, XML, OpenPGP and SSL -
it list other projects of
online payment
Central
Authentication Service at Yale University; other single sing-on
solutions
Qare
Ripple : project of a
peer-to-peer money system
Alfarez
Abdul Rahman's Research Documents on trust
(Poblano, a distributed
trust model for p2p networks)
www.p2ptrust.org
Slashdot:
Distributed trust metrics ? (for forums)
Python Trust Metrics.
Implementation of Ford-Faulkersson Maximum Flow algorithm and
mod_virgule's Trust Metrics code, in python
Open Source Applications Foundation
and their Chandler project (of a user-friendly portable communications
sytem in python)
Livejournal and its trust
metrics community and Trustflow
system (with FAQ).
http://www.identitycommons.net/
The PGP Web of
Trust
Linkfilter.net
The
PlaNetwork Consortium
One-of-us with its newest project One-of-us.org'ster
A wiki listing
all trust metrics
In this list, there is Openprivacy.org
that focuses on combining anonimity with reputation by special complex
cryptographic algorithms when exchanging trust certificates to clients
softwares, without any help of central servers.
IM2000
: proposal for a new protocol of mail system in which messages would be
stored in the sender's box instead of the receiver's.
More email protocols here and there
The
Free Haven project
The
Augmented Social Network (html version of
the whitepaper here)
thetransitioner:
an interesting web site including TikiWiki
Cordance : creating the
Dataweb
(The Chaordic Commons)
Inter-site login (??) :
phpBB
Passport (1.0.1) First Official Release : NOT an open source
project as concerns the "server" side which is not released (central
database of all users) - moreover, it looks like the way it works is
too different from what we need to be useful
(Liberty Alliance Project : not a good partner according to what is
explained at the Augmented Social Network project)
(ODP Passport
identification stuff ??)
The FOAF project (Friend of
a friend) points out the use of the RDF format for dating files. A discussion
on this subject continued as a wiki page.
Who I am : see my homepage.
E-mail : spoirier at lautre dot net.