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:
- 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
- Forum
- Admin panel (with
its own different parts concerning the different components);
- Contacts list
(will later include trust declarations);
Partially existing:
- Translations of the interface in other languages produced by the
users
themselves
Not existing yet, to be
added soon:
- Dating system (see specification, and explanations why
it 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
details
- News
and calendar
To be added after a long
time
Registration
The system admin can choose whether the invitations form is
either
- publicly accessible (unless denied by system admin,
which should be done soon)
- or accessed by invitation from an existing user of the
same site
(from inside account or by email).
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 :
- 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)
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
- Right to read
- Right to write (stronger than to read)
- Admin right (need not exist) to control the parameters of
the
forum, rights to read and write, practice censorship...
(A person that has no right to read a forum, 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.