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
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
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
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
Sorry, the Test installation
is no more working now.
of a user documentation.
More details of this
project are described in this page and other pages linked
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...
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):
- A global login system, by which one account on one site
gives the possibility to own several identities and use them to
be identified across the whole network
- Registration by invitation
- Admin panel (with its own different parts concerning the
- Contacts list (will later include trust declarations);
Not existing yet, to be added soon:
- Translations of the interface in other languages produced by
the users themselves
To be added after a long time
- Dating system (see old specification (the new
specification is not disclosed yet), and explanations why
would be much more efficient than existing dating sites, to
cope with millions of users while saving their time).
- Userís or collective web-pages and wikis; see Wiki specification file for more
- News and calendar
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
Why OpenId can't be the right solution for
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
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
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
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
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
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
- 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).
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 (at the user's home account to list the forums
that can be at remote sites)
- Forum itself (to be accessed by users of different sites, and
even by email users that did not register to the network)
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
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
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).
- Right to read
- Right to write (stronger than to read)
- Admin right (only needs to exist for public forums or large
conversations with many members) to control the parameters of
the forum, rights to read and write, practice censorship...
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
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
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
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"
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
- 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
- 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)
- Category (ex: concert, theater, rendez-vous, party, exam...)
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,
- Titles of events in pools that may be modified for display
convenience. Or there can be both an official title and a reader's
- 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.