Main Description

Project hosted at sourceforge.

Short description of the project

This aim of the project is to make a combination of different more or less innovative ideas:

- To unify the concepts of forum and webmail by making private forums with different rights to read and write for each forum, first for members of the same host, then for members of different hosts (this includes a new method for private communication between users of different hosts).

- A system of multiple pseudos per login ensures the possibility of anonimity from a public point of view while allowing operations that concerns a user independently of the pseudo used. So this relation between a user and his different pseudos remains internal to the server, only the necessary information is revealed outside.

- A multilanguage system with translations produced by the users themselves

- To avoid spam we will have a system of invitations between users, and invitations of new hosts to the network by users of existing hosts.

- Between different hosts we will have a public key certification system based on the trust declarations of users, to handle the public key infrastructure problem with no need of a heavy certification authority. A user of any site can be automatically authentified as such when visiting any other site, with some useful information, still ensuring a relative anonimity. On this will be based the communication in private forums between users of different sites.

- Have user web pages and wikis where the author of every page will be identified by his pseudo of his choice (to allow for micropayments, sending messages, complaining...).

- A calendar system with ways to record or publish events, and display them on time on each user's board

- There will be an open database dating system by which users can publish their ads and review those of others. Later, any other kind of small ads can be considered. The database of these ads will put in common by all sites of the network.

- Between users there will be a system of trust declarations, and trust computations (with rules of trust transitivity). This will probably come together with a payments system so that people will be financially responsible for their declarations. But this is not necessary to ensure a minimum level of trust, as some kind of trust comes from the invitations sytem which may be enough to get rid of spammers.
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 that one can send against a message to the people who are responsible for it (we don't know who but the computers can forward) by their direct or indirect trust declarations to the sender, so that they can respond or revise their declarations.

 

Some practical information : PHP programmer wanted

Demo site

A test installation of the present version of the program (with many defects that must be fixed) is here. Now, there are only logins, pseudos, forums, boxes to display forums, and contacts.

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. But other languages can also be considered, like Python, or eventually as someone advised me, Common Lisp (with
bknr), or OCaml. It will depend on what language programmers will be ready to use, provided that it is well integrated with the rest ot the project.

Programmers needed !
This project contains several parts, so it is possible to participate for only a part of the work and let the others work on the other parts. Here is the
TODO list .
I need programmers to participate but not I have not the money to pay for a reasonable salary from a Western viewpoint. Other advantages to do this work: it is a promising projet, I intend to find some hosting for installing the result, use it for myself and recommand the use to others, publish the reference of the programmers who contributed to this project, and make plans for further developments to make this software famous.

Contact information

If you are interested with this project, to share ideas or participate, please write me at the address spoirier at lautre dot net. Thanks !
Also, you can write your thoughts about all this to my
public forum.

Detailed description of the project (in the short term)

The system includes:

together with the below described relations between all this.

Relations between users and private forums

- Preexisting or given  by others:

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.

More details of the short term specifications for "relations between users and private forums" and "user interface configuration" are in the
todo list.

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.

Bookmarks page and inter-site authentication system

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. The URL of the link to host2 can contain a randomly generated &parameter to recognize the session that needs this authentification.

Another possible way that may add more security to this connection while keeping it simple is to have the link to host1 that redirects to host2. So host1 will be contacted first in an authenticated way and establishes the authentification with host2. Then he connects to host2, being authentified 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 what I ask is a tool by which the second site can recognize visitors as authenticated as a pseudo from another site.

Someone told me that it is not difficult to make a php program doing this.

A possible idea 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.
4) A generates a random number N and sends it to B in a crypted way, possibly together with other session informations to identify U (like U's IP), and possible parameters about him and what he wants to do (unless this last info appears in the URL below).
5) A sends U a redirection (maybe in a new window) to an address at server B together with the parameter N.
6) B checks that the number N in the request is identical to the one sent by A, and the conformity of U's IP and other parameters.
7) If all is OK then U is logged in in B.

Another possible idea is:

1) U logs into A
2) U requests A his decision to visit B.
3) A crypts the authentication information (U's IP, U's pseudo and other info) in a compact form to send to B with its symmetric key with B, but does dot itself send it to B
4) Instead, 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 (if it's not enough for B to identify A from the request, I have another idea, just ask me)
6) If all is OK then U is logged in in B.

Another idea is, in the case the access to B is in https, that the certificate of B is accessible on the server A and can be downloaded from there before the first connection to B.

Another idea, 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.
Details to make this possible naturally come from the specifications of the boxes and forums databases as described in the
TODO list.

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.

Personal web pages

Let users publish their own web pages in html (not their own php code for now) attached to one of their pseudos, with the possibility to restrict the viewing to https mode and eventually to authorised readers according to parameters. The important point is that we should establish a general systematic way so that whenever a visitor finds a personal page, he can also access an automatic info page associated to the author (his pseudo and thus the possibility to write him, and other features that will be developed later, like his rate of trust and evental complaints against him). For example, things can be presented in a frame where the top (or bottom) bar gives the pseudo of the info page on the author. A method to let these pages link to each other has to be defined. Another way would be to have the personal pages of a user (pseudo) in the subfolder named by this pseudo, and the index.php file reserved for the system so that just cutting the URL at some / would be sufficient to access the info page on the author.

Conversely, the info page can contain a list of comments by th author and links to some of his pages he decided to link to.

The association hosting my web site is at the origin of the AlternC project, that is a free software of web hosting, on which its hosting is based. (I do not know of any other free software project for web hosting) Unfortunately, the explanations are most often only in French. I asked one of the programmers involved there whether the file browser part of this software can be re-used for the goals of my project. He answered it can, by deleting the unnecessary parts, or else we can take this software as a source of inspiration to make a software more adapted to our goals. Something that must be done for security reasons compared to this AlternC program, is to forbid the user to upload or directly edit the .php files in his account.
The files are in
http://debian.alternc.org/alternc_pre-1.0-20031009.025604.tar.gz.

The program that makes the operations on the file system is bureau/class/m_bro.php

The programs that display the browsing screens and forms are in bureau/admin/
bro_editor.php
bro_pref.php
bro_view.php
bro_main.php
bro_tgzdown.php
browseforfolder.php

Unless, of course, we want to make a version of our project that would be unified with the whole AlternC project, for the case of people that want to set up their own web server. (This is an option that anyway we should consider later in the development of our project, unless the AlternC developers themselves decide to integrate our project with theirs...) I said the information page would be at the (/index.php) entry of the pseudo's personal folder. In fact, we can let this page as other automatically made php pages, be made of a frame with automatic info on the one side (downwards) and some html page on the other side (upwards). Or would the html page pose a threat to the integrity of the automatic info page on the other side ?

The dating system

A system of open exchange of dating files is planned, to be implemented during the year 2004-2005. It is designed to be the best and universal dating system. Details not disclosed for the moment (they will differ from the description that was previously here).

Other kinds of ads can be considered in future developments of the project

The FOAF project (Friend of a friend) points out the use of the RDF format, that seems to be exactly the language needed for this task. A discussion on this subject continued as a wiki page.

Declarations of trust between users

(This description is a draft, more than above description; it can be revised and developed later).
 
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:

A text of explanation must be attached to any complaint, and can be attached in option in the case of trust (recommandation letter).

Transitivity computation

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.

The last one is trustworthiness, which is primarily not a quantity but a boolean information (yes/no) on whether the person is trusted. (Then it will be possible 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...).

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,y) 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 in Z(x).
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).

The problem is to do it so that it can still handle tens of thousand users without saturating the computer resources (cpu and memory). I note that 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. 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. Can we realistically hope to compute the shortest trust chain between two points ? I found an idea for this : 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 freely 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 site publishes (with signature) the subset of the ordered set defined by quotienting the set of users by the preorder generated by the trusting relation, where a class is published when one member of the class wants it.
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 answer questions of the form "what is the class of the user with public identity x" ?
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".
Such a declaration leads to the eventualility to be warned by others in case that there was a problem with the other site or one of its users.

Inspired by these ideas I thought of a method for the money system (affordability computation).
Details another time.

The complaint

The complaints against a pseudo x goes through the following steps, and requires to commit oneself. It requires to have the sollicitation right to x and to see a message or text (web page...) made by x (it is a complaint against this message or text).
A complaint cannot be strong immediately, it must first be weak, then average. Here is a rough description, that may need further developments:

1) Weak complaint against x means: Warning signal to x's user, with an explaining text, that will appear 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:

2) Medium complaint: this means extending the above weak complaint, in the form of forwarding the discussion, to the defenders = pseudos who trusted this pseudo (without knowing who they are - or a subset of this set, decided how ??), which means, a pseudo y such that C(y,x) = Trust, or that was such at the first time of complaint. It is necessary that at least some of these defenders answer or do something at one of their next logins, else it gives the right to forward this complaint to the people who trusted these defenders and so on (but this right may exist however...). Or maybe to do a strong complaint after a next warning...

3) Strong complaint = public complaining mark against the author, so that anyone that trusts the complainer reading a message by the same author can access together with committed explanations. Any chain of trust from a person that indirectly trusts the complainer and that passes through the person complained against will be ignored (more precisely, for this rule not to contradict itself, it will not apply to itself).


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
http://www.hotscripts.com/PHP/Scripts_and_Programs/Classified_Ads/Personals/index.html

But after searching for all dating sites softwares under GPL I could, I can say that the following list is probably complete:
-
AzDGDatingLite (but the copyright is not clear - a version for phpnuke exists for "members only")
-
sourceforge.net/projects/ltnetpals/ is a program in CGI format.
-
PHPenpals is a very little php program, not much worth anything.

Other programs, projects or related works that may be useful in relation with this project

Yahoo's Domain Keys: Slashdot discussion - a critics against it - More information comparing different technologies with the same purpose.
Qare
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

Trust my mail ? : Trust Metric Based Spam Filtering

( shared IMAP mailboxes ?)

The Free Haven project
The Augmented Social Network
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 ??)