Note: If you change something, give your change a number (1), add number to
      changed place in text and add a new entry to CHANGES section below.
      E.g.: bback on ...: changed processing logic (3)

-------------------------------------------------------------------------------
CHANGED:
---------

- bback on 2003/06/05: added stuff for private message boards <(1)>
- bback on 2003/06/04: inital version
-------------------------------------------------------------------------------

OK, about the XML format:

A XML format for messages is already designed. There will be 1 XML file per
message thread, multiple threads per board.
To not show old Messages, the whole XML thread will disappear if the latest
RECEIVED message of the thread is older than ? days.
Old threads will be saved in an archive, wich holds all old threads per
board. Users can search in archives (in board, too) and send (manually)
a whole archived thread to the source board (or even to other boards). Users
can also export threads from archive (xml file) and delete it from archive.
Therefor its also possible to import xml thread to archive. Users can also
decide wich thread should be shown in archive or board.
If a new message is received, the xml thread file for this message is
searched (also in archive) and thread is updated with the messages contained
in received xml file. If thread is not on local disk, its created.

If a user creates a reply to a message, the reply is appended to the parent
message the user replies to. All messages from this reply up to the root
reply,
but on only the direct path to root, no other branches, are inserted in a
new xml file, and this file is send to freenet.

So the behaviour of receiving messages is the same for archives and
messages: just complete - or build the local xml thread file.

And yes, we need a way to track the already received messages: best way is
to keep saving files to disc, thats the most transaction save way.
We should save 1 file per received file, a file conaining only 1 byte, no
real content is needed. This file is saved to local disk if the received
message is successfully inserted in local thread and the local thread is
saved.

Each ROOT thread and each message get a unique ID to easily separate them
and to find threads/messages quickly.
ID will be some SHA1 hash of date, pubKey of user, ...) see format for
details.

With current xml format it will be easy to implement attached board, files,
identities and more. We also had the idea to add file filters to a board
(and also send this filters with attached boards) that allow users to set
the filetypes to search for (in search table) per board, e.g. .mp3 for music
boards, this would allow to hide unwanted extensions per board.

We need a way to search in choosed boards (not only in 1 or all), maybe all
board below a folder. The search function should be fixed to be fully
shell compatible, means the unlimited use of * and ?. special search opens
should be implemented using dialog options.

Identities will be a xml file, in the gui the identites are either GOOD,
BAD, UNCHECKED or NEUTRAL. User can choose the state in a dialog
which shows all identities + their information (e.g. blocked count, ...
whatever).
User can also choose wich identities to see, or chooses to see all but BAD,
all NEUTRAL, ... every combination is possible.
Maybe there will be a way to send messages encrypted to more than 1 other
user.
encryption/signing behaviour keeps as now.
And it will be possible to maintain more than 1 local identity and to assign
a local identity to a board.

Attached is the xml format for the threads and for the identities. This
should be the base, and please pay attention to the tag names: not pubKey,
but publicKey !
I already used 'publicKey' in boards.xml and we should not change this from
file to file.

TO Zlatin: we DONT need a <status> tag in the xml file on disc, because we
decide dynamically which
messages to show or to block on receive. This is done using the Identities
list. When an identity state is changed, this reflects immediately the shown
messages and maybe blocks messages on receive.

This is a first draft, we need to specify things clearer. Please comment.

@see: messages.xml
@see: identities.xml

<(1)>
If an encrypted for ME message arrives on private message system (internal board),
add message (maybe after checking the sign) to
the identity  of sender in identitiesTree. If person is not yet in tree, do something configurable:
1. ignore, 2. ask, 3. auto-add

Here a part of the mail that explained private message board (changed):

..., but i thought what the user in the long mail meant
was to have 1 single frost board (internally) for the personal messages. All
messages in this board are encrypted for someone and I see only the messages
that are intended for me, and i see this messages as new in a 'board' which
is the user that sends me the message.
So because of the single board all frosts would receive the messages in this
board and therefore spread them. Of course, you could disable the private
message board to avoid the masses of messages that are not for you, but you
would download. If disabled, you can't use the private messages and others messages
are ignored by your frost, and frost will stop receiving private messages from the internal board.

We should add a spam detection (x new msg. from 1 user, or x msg. from x new users are blocked, ...)
and disable private board update for some time of spamming is detected.
</(1)>
