Project
hosted at sourceforge.
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.
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.
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.
The system includes:
together with the below described relations
between all this.
-
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.
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...).
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).
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
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).
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.
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 ¶meter 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.
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.
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.
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 ?
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.
(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).
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
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).
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.
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
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 ??)