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 ?):
- those where both oneself and him has writing right and he posted a message
- same but he did not post message
- Those where I can only read and he posted a message
- Those where I can write and he can only read
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.
Translations
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).
Notes:
- 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.
Summary
- 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