The Trust-Forum project

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, I then simply uploaded releases here below.

Sorry, the Test installation is no more working now.

 Start of a user documentation.

More details of this project are described in this page and other pages linked there

The Todo page of July, 2008 as compared to the last release of code

Search for new programmers + October 2009 : Proposition of reorientation of the strategy, into an integration with Google Wave

This project has not made any progress for years because nobody was ever interested to work on it, because it was "not notable". Now, a small subset of the concept has gained huge notability and thousands of programmers, in the form of Google Wave. This seems to be the chance of a new start. Contributors are welcome to contact me !

Existing versions

The release Trust-forum-1.3.1, January 15th 2006, installed, 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.

Short description of the project

The aim of the project is to make a new combination of more or less innovative functionalities at web servers, to be the basis of a new internet experience with a decentralised network of independent servers :  

Already done:  Partially existing:
Not existing yet, to be added soon:
To be added after a long time

Registration

The system admin can choose whether the invitations form is either In any case, inviter and invited should automatically appear in each other’s contacts list.
Invitation tree is recorded, to be tracked by administrator for finding out the inviters of spammers or of those making other problems, and to blocking their invitation right. This should give a final end to spam.

Global Login System

We have a network of independent servers (with separate domain names and independent administrators) with some common functions (but each can develop its own supplementary functions), each having the list of all other sites of the network with their respective PGP public keys. New hosts will join the network by invitation by users of existing hosts, with invitations tree tracked by other admins.

Each user has only one account defined by login/pass on only one of the servers (because he won't need more as explained below), that is called the home site of this user (other sites will be called remote sites). 

Once connected to his home site, the user access his user board that centralises a number of functions. In his account, the user can own several pseudos (well, we could limit this to 10 or 20 pseudos associated to the same account so that it will largely suffice), and choose any of them to perform operations and to visit any other site of the network, identified as "pseudo@host" where "host" is his home site, automatically without typing any more login or password. This ensures the possibility of anonymity from a public point of view, while allowing operations that concerns a user independently of the site visited or the pseudo used (the different identities of the same user appear to come from the same home site but only the home site knows that they belong to the same user). (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).
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.
Why OpenId can't be the right solution for this project

Remote authentication techniques

Several methods might be considered as possible technical ways to reach the same goal: to let a user U of a site A to authenticate as U@A to a site B, after all public keys had been properly exchanged between them. In other words, to let A certify to B that the online user U truly possesses some identity pseudo@A.
Here are 2*2=4 possible techniques.
One can either:
Have the link be a request to home site that redirects with key to remote site
OR
have the key already prepared in the link in page from home site to remote site, even though the user might decide to not use it. Problem: if copy of web page is stored in browser cache and then reused, keys should be made invalid for security reasons (someone else may be using the browser). In other words, it must be valid only for current session.

The key can either:

Be a random number, while the useful info will then be directly transmitted between servers
Or
Be a signed or symmetrical-crypted message from home to remote host.

If I understood well what was done, it was using a link to home site that redirects using random number.

To tell it in more details:

Once the public keys of servers A and B are correctly known to each other since they both existed in the network, we have the following: User browser U logs in to his home site A while exchanging key with it. Well, this first requires U to have got a correct key of some site of the network prior to anything, that will provide him with the correct public key of A, by which he logs in to A and gives A his own public key. Then, for visiting site B, user U first gets from A the public key of B.
The authentication of U to B goes along the following lines: U expresses the will of connecting to B by an SSL request to A. A generates a random number N, and gives it as a respond to this SSL request. This way, U has the privilege of knowing this number N. He includes the data of N and A in an SSL request of session opening to server B.
Then, a direct SSL communication between A and B happens for checking number N and exchanging other useful info. After this, the session of U in B is recognized by B as being of the authentic U@A user.

An equivalent "simple formulation" of the same idea

User U registered at site A wishing to visit and interact with site B, requests this operation to his account at A. So, U requests A to automatically make a registration of "U@A" at site B with a hidden password (which needs never be typed nor displayed). Then, A bounces back to U an already-filled login request that U's browser automatically sends back to B. Authentication of U@A at site B is done.

Links and bookmarks

Links diplayed for a user U@A aiming at a remote sites B, such as the bookmarks from the user board in A, as well as links from any site C to any other site B, will be processed to technically consist of different possible things according to context. These possible contexts are:
- User already has open session in B (problem: how can C know it ?). Direct normal link can fit.
- User will need to authenticate under some pseudo for accessing B. This is done by link to A redirecting to B as described above.
- User will visit B anonymously in read-only mode, while having his visit of B still technically enhanced with his open session in A; this could be considered to be technically operated, as well under a "temporary pseudo" authenticated by the same process as normal speudo, or without authentication but with only the unverified information of which is the home site A of U (as long as user does not have a special GLS enhanced browser that manages this itself so that B needs not know what site A is the home of the user).

Forums

A forums system with such functionalities that it would serve as a good alternative to email (by making private forums with different rights to read and write for each forum), therefore making the email protocol obsolete: each forum would have its own rights table (or even different rights systems) for communication between users registered at separate sites through the global login system.

The forums system is made of 2 components :
At any forum space, access right of any level (read, write, admin) is obtained either as creator of this space (anyone can create a forum at his home site), or by invitation by a user with at least this right to this forum. Limitations of access rights to a forum are edited by users with admin right to that space.

Folders

Currently, it is organised in the following way:
There are 3 folders: MainBox, UserFolder and Public Forums.
User can create subfolders of UserFolder, for having more folders.
Each subfolder can be renamed, deleted, moved, and can contain more subfolders.

Normally, a forum in should be present in at most 3 folders:
- "Public forums" if it is public
- MainBox if one is subscribed to it and there is a new message
- The folder that it had been moved to (which is MainBox by default, i.e. when one was invited to the forum and did not yet move it somewhere else).

The initial idea was a bit different. See there what it was.

User rights in forums

(A person that has no right to read a forum, cannot even know its existence nor make any operation to it).

Subscription

Subscription to a forum, means that one will be warned whenever a new message will be posted to the forum. This warning will take the form of the appearance of this forum in the "Main Box" folder. Later, it will also make a visible warning by an icon at visited remote sites.

Forums are created by any user, who gets the maximum right in the new forum (so, admin right if it is a forum with admins, as has still always been the case); it rights are transmitted through invitation.

Deletion of messages (yet to be implemented)

Each message should, like a wiki, have its own history.
This way, the author of a message can hide it by putting an empty new version, but users can still find out what had been written by exploring the history.
Everyone can put the deletion mark on a message to stop seeing it.
When all subscribed people have put the deletion mark on a message, it will be physically deleted.

Email and invitations

With the contacts list, some contacts are users of the network, some are only email addresses. Therefore, there are 2 different functions to add contact, according to whether it is a user or an email.
Clicking to an email address in contacts list, leads to a page to compose and send a message to this address.
There, a checkbox says "Would you like to add invitation ?", with a menu to choose the invitation language (this choice is not implemented yet, but invitations messages in different languages exist). 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 key to let the user register.
It should be possible to re-send the invitation message and code (or a new code) if it was lost.
Something not yet well done: to choose the pseudo under which to send an email message or register a new user; this pseudo will then be the one by which each will be in the other's contact list. The new user invited by email should have its login added to the same line as the email address that was in the inviter's contacts list (and not in a new line)

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.


Who I am : see my homepage.
E-mail : trustforum at gmail dot com.