The Trust-Forum project

This project is for a set of several new open source Web applications, to be integrated in independent Web servers and make them work between users of different servers as well as if all were members of a unique server.

Short presentation headlines

The first purpose is to get rid of the need for a user to create several accounts, then enter login several times for using independent servers !!!!!!!

I already wrote this beginning of sentence on this page since a long time, but despite of this being read by hundreds of people, they seemed to not grasp any meaningful purpose of this project. Usually nobody even writes me back for any discussion and explanations. I heard that this page was not clear and not attractive. And even, trying to discuss with someone who read this page, that very first purpose of the project was completely ignored, and the person just implicitly assumed that "of course like everybody on Earth" I still also myself wanted to become the owner of the world and bother people complicating their life with the need to create one more account on one more server. How the hell can I tell it so that people grasp that I really have a new kind of proposition here ???


But, what the heck do I mean ?
That nowadays there is a big trouble with the Internet (hey, I'm going to explain this here for those who didn't get it, but please don't assume it's the only thing I have to say, there is much more, but.... please wait a moment before going away!!!!! I have much more solutions to other problems too !!!)

So one trouble is:

Gmail is quite good... but for it to be of any good, and especially to use its convenient chat system with your friends, they must all be logged in at Gmail too. Which is owned by Google.
Problem : does/should the whole world belong to Google ?

Facebook has its qualities. You can organize things by facebook, chat there with your friends too... but for it to be of any use, all of them need to be logged in at Facebook too. And you must have all the things you do there and all your data ultimately owned and decided by the Facebook company.
Problem: does/should the whole world belong to Facebook ?

Same with Twitter, and so on.

You may like to exchange ideas with many people, join many discussions all over the web on some topic, and for example announce something there (not spam !), or say anything. You just have to say one thing here, one or another thing there. Maybe because a false rumor has been spread worldwide, has been mindlessly repeated by many, and you want to bring it a correction. Get in touch with many people, not just invest yourself a lot of time with a random but fixed small group of people that happened to have registered somewhere, among all existing ones. But there are dozens of such spaces.
Problem: when browsing for this, you find yourself the need to create dozens of accounts, fill many registration forms with their respective captchas, and wonder if you are going to create different passwords (but never be able to remember them) or just repeat the same password (despite the resulting insecurity) in order to be able to do this. Is this a sane Internet ?

There needs to be a solution: a single sign-on. Something decentralized. Not one more social site but a FREE (social) SOFTWARE FOR WEB SERVERS.

Some will say: this already exists, it is OpenId.
Sorry but I think OpenId is not good. Because it is just an isolated piece of code. If it was good, everybody would be using it now but they don't. Because it does not come with other needed integrated functionalities for being a really convenient system. And such other functionalities are what my project aims to provide too.

Others will say : there is Diaspora, there is...
Well, a lot of things could catch mediatic attention because they were not really ideas. They were slogans such as "Let's make a new facebook, peer-to-peer". Me too, but.... they had the most catchy slogans, and the random chance to make their mediatic bubble. People are usually only interested with mindless slogans, with what the media already reports to have made mediatic buzz (no matter that there was no good reason for it) and they will give $$$ of donations to them for nothing.
But I have a real idea. A new method to combine the advantages of centralization (efficiency and convenience for users) and decentralization (freedom, flexibility, diversity, fair and open competition, the world not belonging to one super-big business anymore). And much more solutions to diverse important problems !!! Including the problem of how to initially attract people to use the new software... once it will exist !! (I only don't know how to initially attract programmers before this, without demo )-:
A chance for really thoughtful programmers, ready to bother understanding (for 1 or a few hours) the details of concepts (rather than just mindlessly follows the "existing" nonsense currently followed by many mindless people), to make it and change the world.

So let's continue the other necessary parts of description. (If it will still not be clear but you would be motivated to work if it was clear and you were convinced, well I know it is not obvious, so let's contact and discuss !!!)

....what's next :

Let us resume from the interrupted sentence.

The first purpose is to get rid of the need for a user to create several accounts, then enter login several times for using independent servers, whether or not he want to be known as being the same user from a server to the other.

The second purpose is to make use of this functionality for developing a forums system able to replace email. Some similarity of use can be found of this concept with Google Wave, but as for technical details it will be simpler and more open and flexible, as it will not require the contents of conversations to be shared and interpreted by different servers.

Other interesting applications will follow: online trust, very efficient dating, and more. The supplementary applications will be developed progressively after the first ones would be adopted.

The focus of the innovation here is on the better understanding of what is the problem, i.e. the economic structure of the people's needs and what structures of data and interactions connecting people across large populations, can most efficiently satisfy these needs, before considering the question of what is the solution from a technical viewpoint to best serve these ends (how data will be stored and shared between independent hosts), and which turn out to be relatively simple once the true nature of the problem is understood, and false problems (endlessly hypercomplex solutions disconnected from the reality of needs) are dropped. Sorry that this better understanding of what is the problem, cannot easily be summed up (some aspects have similarities with functions of Facebook or other systems, others still have no decent equivalent...).

This presentation page might not seem very clear; the system once implemented will probably seem simpler to use than to explain what makes it work; please don't hesitate to contact me for clarification (by skype...), as I think I can convince most people once a rational debate is done (except mainly some fixed in a predefined ideology, like those so obsessed with privacy and security that they cannot understand anything else - while this project will satisfy privacy and security but by unexpected means that such people may not easily understand).

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

Still nobody is actually working on the project at this time. Developers needed !

October 2009 : the Google Wave mediatic bubble

For a moment, the Google Wave project attracted all mediatic attention. It was claimed to be very innovative, though the main interesting concepts were already in this project several years earlier, but people were not interested, because they don't like to bother understanding new ideas unless it is already "in the trend". While my project was never "in the trend" though it convinced most people I explained and debated my project with. Also there are major design flaws in Wave that did not affect Trust-forum. Still, nobody seemed to be interested to understand this. As if people did not care what is true, they judge things according to reputation "this is Google so it must be good"...
Now that a small subset of the Trust-forum concept has gained huge notability and thousands of programmers, in the form of Google Wave, one could have expected that it would lead people to pay attention to Trust-forum, which already contained the good points earlier without much of the useless technical complications and other flaws, in order not be stalled on the way like Wave was. Unfortunately, it did not happen...

Existing versions

The release Trust-forum-1.3.1, January 15th 2006, is simply here

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. (a datings function, previously mad, has been inactivated). It is much more documented but has some remaining bugs. Problem : while it had been successfully installed long ago (with bugs, but it could run so that the functions could be tested), the people I recently found to try to install it again (just as a way to figure out some intended purposes, even if this code itself is not good as a basis for further developments) did not succeed. If you can find out how to run it again, and provide the instructions for this, I will be grateful !

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 (but with many errors and maybe not reusable): Partially existing:
Not existing yet, to be added soon:
To be added after a long time

Registration

The goal will be to restrict registration to invitations by existing users of the same site (from inside account or by email); but in a first term until success, the system admin has the option to allow public access to registration. In the case of invitation by an existing user, 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.