Todo list for the Trust-forum project

Checking and correcting bugs 

About registration

The secret question/answer could be eliminated. (the recall password functionality did not check anything, so it had to be disabled; anyway I'm not sure there should be a recall password functionality at all...).
In invitation by email, the email field should disappear, as the system already knows the email address.
The secret invitation link should be made secure: the URL should not carry the data of the inviter id, to let no possibility to modify the URL to pretend to be invited by someone else.
The same way, ensure the key to a forum gives not access another forum, and a wrong code (as random number) will not be accepted.

Some known bugs

The name of the local host for user identity display, should be normalised
Error when editing a message
Some ponctuations/accents make error while posting messages
Long threads (more than 10 messages) are divided into pages; posting more messages should diplay the last messages of the thread, not the first.
In display of translations file or creating new translation, items numbers do not appear as they should

To be tested

Special characters (punctuations, accents) in all text fields.
If global login system works properly, especially as concerns invitation to a forum at a remote site
Any possible perverse effects of the Refresh and Back buttons

For installation

A question (especially concerning how the global login system should be implemented) is to have a solution not too difficult to install by many
people (one every some hundreds or thousands users) to new hosts, and still reliable and secure.

in admin panel

Lots of stuff missing from the forum settings: for each forum there should be posted somewhere (even without possibility of changing) the nature (public, private, semipublic), its owner, its table of invitations.

Uh, in fact it should not be "displaying the nature of a forum", but rather to display different lists of forums according to their nature.
For it you can put in the top bar, instead of "forum settings": "public forums" (including semipublic ones), "private forums"

For each message it's status: valid or not, read or not.

In the user folders, displaying their contents (lists of forums).

It seems to me that the "PublicForum" has no place in folder settings, since the list of public forums is common to all users (who, if they want to put order, can do it by putting a copy of the link in their UserFolder)

From the contacts page, it should be possible to request the info page of a user (pseudo entered by hand), without adding it to the list of contacts.

In the admin panel there should be more direct access to the relationship between logins and pseudos, as well as a display of the e-mail address associated with each login.

In the list of forums of admin panel it is an empty box: it is probably a forum with empty name, then the corresponding box of the html table does not exist!
In my opinion it is necessary to make an error for an empty name forum, and demand to put a name not empty.

There seems to be a pseudo empty. It must be banned.

The forum info must show the date of creation of the forum.

In the list of forums of admin panel, which will become 3 lists, it should be columns displaying the owner and the date of creation.
The present columns are a little silly, always repeating the same words. They can be replaced by a checkbox by placing actions at the bottom.

I was talking to display the invitations table, in fact it is already in the form of "edit denies. Inside, I find the table a bit absurd: the creator, invited by "system" should have for invitation date the date creation of the forum.
The second column "deny level" is used to modify the data of the first.
We could replace it with checkboxes, with choice of the new value at the bottom: it would save a column.

User info page - list of private forums in common

List of private forums that a user took part in:
Distinguish (does all that make sense ? are all these useful ?):

Something transverse

In most cases, the user has only one identity under which he can perform an operation, therefore the menu to choose a pseudo is not needed.
Wants to make invitation to a forum: You can invite
* Either by hand
* Either from contacts ---> if it is the forum with a remote host, it is necessary to make a pop-up to home site because remote host has no contact list.


Translation of the interface into different languages can be created by user themselves.
This is currently operated in one method.
This method should be modified, and a new method should be developed, so that there will finally be 2 available methods

Modifications of the present method

The present method is having distinct translation files where each file contains one translation of all items of the interface in a given language.
One of the reasons for keeping this method is that one given langage can have regional variations.

A translation file is labeled by not only language as parameter but also version label/number, pseudo of the author, creation date.
It can be made public or private. It should be possible to switch from private to public (or conversely) later.
Letting it public means it will appear in the list of available possibilities for the others; however if it was public and one used it, then it is made private, the user can keep it.

There should be no way to overwrite a translation file (possibly except if nobody else is using it - would it be good to let the possibility to overwrite the preceding version by the same author in the same language ??).
But, dating should be excepted from this and have separate translation files (and more generally for the future, new components would have
their own separate translation file)

 Instead of making a new version based on only one existing one, do it based on the selection of 2 existing ones :
- the first to display above each field
- The second (possibly blank) to prefill the fields.

New method

For any page in the system there should be the option to activate or inactivate translations. And before this, in user configuration, the user could choose the list of languages he wants to see in translations.
Activating translations, means that for every word (or item) present in the page, will appear a sign to deal with its translations.
Clicking on this sign would open a pop-up displaying the list of all translations of the item in selected languages, together with their popularity. In each language, translations are ordered by decreasing popularity.
The popularity of a translation of an item is the number of users that selected it.

So for each user and each item (no matter whether translations system is "active" or not), the translation of the item that appears in the interface to this user, is:
- Either the default, defined as the most popular translation of the item in the user's most prefered language where a translation exists.
- Or the selected one. Selection is done by the user in the list as described above, or the user can add a new translation. By doing it, he is considered to be selecting it.

Other remarks

Maybe, 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"

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).

About forum and wiki

Some parts of the forum are already more or less working, but have bugs, so the problem is to make a list of bugs and fix them. But it may not be necessary to correct the part "forum messages" as such because they will have to be replaced by more sophisticated functions: it will have to be rebuilt upon the wiki part of the project, and a unification with instant messaging should be considered.

So, for this you should focus on the wiki spec first.

This other table is a copy of the first one that, according to what she said, was reduced by selecting all what speaks about wiki/PWP (PWP= Personal Web Pages) (but also other things) with her comments in French. However this is not the most relevent information about wiki, since I never really cared to explain the specifications for wiki in that previous conversations, as I did not request the belarusian programmers to make it. 

An idea for forum containing subscribed email users is: to let it possible to configure the forum to send posted messages: immediately; or: after ( ) minutes or at closing session (this is to let the chance to make the message invalid again, which would not be possible if the email was sent).
The importance of this question of when to send message, comes from the fact that, as valid messages are waiting to be read by someone else and, when they are read, they cannot be made invalid anymore, so when the message is sent by email, they will be read without modification, it is must be marked as already read.

ideas to unify Forum with Instant Messaging

(I had some discussion with Andrew about this question, you may like to contact him to ask for his opinions...)

For merging 2 concepts you have to make a list of differences between them, and see for every difference what you can do to keep the best possibility or let the option to do according to the needs.

I see the following 3 differences. Tell me if you see other ones.

- In IM, as soon as the other posts a message its content appears on my screen, even if I'm writing something else.
I see no reason to refuse this, except for bandwidth problem if I'm not watching here. The regular connexion involved here can also be used for regularly (every 5 or 10 seconds ?) automatically saving (in the sense I defined in the project) what I'm writing.

- In IM, message is posted at every press of return button. This is still in principle an independent option that every user could choose and switch at any time independently of the other users.

- Some mere display differences for the same type of content. Can we define a display style that will be always the best, or should we let users the option of the display style they choose ?
Consider the following idea for a display style:
Draw a horizontal line for the separation of days
In the left margin, put on the left of every message the author and time.

Another aspect of IM: when we are not looking to the discussion we are warned when there is a new message.
For this, I had the idea that the home site sends signals to all sites with session of user so that he is warned and can call home site to know more. But there is the problem that for privacy reasons, the info should not be sent to other servers. I wish there would be a solution where the pages from remote sites would include a way for the browser to connect to home site and display the signal directly to the user. For example the display of a little image from home site, that would be different whether
the user has new message or not.

Develop trust declarations in contacts list

We begin with a first step, already something that can be implemented tough in itself not very useful: to make declarations without yet using them. This makes sense only by the fact it is the first step towards further developments that I will specify later and that you don't need to know yet at this point.

Here is the simple specification of functions to be added as a first step:

In the contact list, add 2 columns, to fill separately:

- Trust Declaration (yes or no at the moment; other values may be added in the future)
- Reporting of contact through one of my nicknames (if I choose several): I add myself in the other's list of contacts. This entry associated with a contact is either empty or the data of one of my nicknames (including my login).

However, the other may choose to hide me from his list. It's one more question in the contact list: does the contact appears in my normal list, or is it just a contact made by others and reported to me, that I hide from my list and that I see only if I request for the list of people who have put me in their contacts letting this visible to me?
In this last list, I can see who declared trust to me and who did not.

If I have a nickname A, and I have in my contact list the name B of a different user, and that he decided to use this pseudo B under which to let me know the presence of my nickname A in his contacts, then, automatically, in my contact list, with the contact B appears my nickname A, exactly as if I had chosen A under which to report to B his presence in my contact list.

So, in my contact list, each entry is just one of the following types:

1) I put B as contact without report, he did not report under B whether or not he put any of my nicknames in his contact list, I do not declare him trust.

1 a) (I hesitate on the relevance of such a possibility, perhaps it is necessary to eliminate): same as 1, but in addition I have declared trust

2) We are in reciprocal contact: I have contact by my nickname A to B, that symmetrically has contact by B to A.
This comes in 4 possibilities: mutual trust, no trust, or one-sided trust in either way.

3) Contact hidden by the other: I have mentioned this contact, and declared trust or not, but he hid it in his list (see 4 that is the view of the other on the same situation)

4) contact hidden by me (but not by the other): he put me in his contact list and mentioned it to me, I do not declare him trust, I chose not to see it in my normal display, but I can still see it if I ask specifically that list, I can see if he declared trust to me.
If both hide each other, the contact is eliminated.

Warning: when I want to add a contact, avoid duplication! For example, if I want to add a new contact, but it is already in the list 4), it should not be added but simply move to the list 2). If it is already in another list, it remains there, and nothing is added.
However, there is a risk of duplication: where he has in his contact list, 2 of my nicknames. I fear it must then admit 2 lines to the same contact in the contact list (fortunately, you can still hide one of two).

- Further information will still be added in the future in the contact list.
- Remember that all this must operate through GLS, among users of different sites.
- Trust declarations should perhaps enter into a separate table so that in the next development of the project they can be used for complex combinatorial calculations, which will probably be programmed in a language more efficient than PHP to better perform them.
- Trust declarations must be dated and can be canceled, but even if they are cancelled they should be archived with date of declaration and date of deletion. We can re-declare and re-cancel, this shall be stored in the archives. With each operation, the system should seek confirmation. To avoid multiply data too much, we may decide that a trust shall be declared valid only after 24 hours, and by then may be deleted without archiving.

Let's say it will be the end of these 24 hours (or even 48 hours) that the declaration will be forwarded to the combinatorial table and be archived; hand cancellation affects immediately. To fix ideas, let us say that there will be a fixed time such as 3 am GMT, where all statements made for at least 24 hours will be archived and forwarded to the use of combinatorial future program.

The future development of the trust system, that things should be prepared to

The perspective may suggest you how the forums system should be prepared internally:

There will be trust and complaint declarations. You can see some aspects described in the /trustedforum.html web page.
For any division "with parties" will be a forum where happens the trial about it. This will contain an automatic invitations system that is not an invitation of someone by someone, but an invitation by the system to "spread the conflict", one more person to participate in the debate and take part until the situation becomes "logically stable", that is one part will be isolated and must abdicate something to recover relationship with the rest of the world.
Nearly the same trial system by forum, will be also used for monetary conflict, in relation with my credit theory.

Therefore, I don't know how it is now, but in forums invitations table (for rights to read, write or admin) I think the invitations should be known by invitation id (incremental), together with pseudo/host. The invitation id is what is important to authenticate the user to the forum (for working with GLS, see below); it should also appear in the folders database of the the user's account, to make this authentication possible.. This will make it possible to let someone to participate in a trial because of his connections in the graph of trust without revealing any of his pseudos in particular : it would work without pseudo, only host and invitation id.
Another way to make it would be that he would have something like a temporary pseudo (but that can last several sessions), but keeping to possibility to turn this into a "known pseudo" later.

About registration by invitation

One more thought to prevent abuse: only allow a user to invite another if he is registered for at least 24 hours.
I also consider the idea of limiting the number of invitations by a person in a day ...

Make invitations of new hosts to the network by users of existing hosts, to play the role of a web-of-trust that handles certifications of keys with no need of a central certification authority.


- Integrate a wiki system, and rebuild the forums system on it (each forum message will be an integrated little wiki with its own history and rights
system; so that not all the bugs of the present code need to be fixed, but some parts will be just replaced by completely different things).
- Fix all other bugs, unless you rewrite everything
- (soon, once specification will be fixed) Make dating system (possibly reusing the code in either of last 2 releases that had many defects)
- Develop contacts list to integrate trust declarations