Menage sur serveur
	? Network-Manager disable tunnel lxc
	Enleve sssd
	Desactive firewalld, ça ne sert pas puisqu'on génère nos propres règles. Remettre nos règles
		après, parce qu'il désactive tout en sortant.
	Désactive ModemManager
	Désactive/stop cockpit et cockpit.socket
	Désactive/stop gssproxy
	Désactive/stop mcelog

Un utilisateur a une page d'accueil et un fil de nouvelles et de photos.

Bolixo minimal
==============
Qu'est ce que ça prend pour publier ?

-inbox (probablement pas nécessaire immédiatement)
-talkbox
-liste des projets, répertoire personnel
-gestion des listes
-gestion des contacts
-Protocol de communication inter nodes
-Documents bolixo, au moins pour expliquer bolixo

Documentation
=============

Document de design. On indique le rôle de chaque composante et ses limites. Par exemple, bo-writed
est le seul à écrire. Comme il est critique, il faut très peu de validation sur le contenu. Il ne fait que
le transporter. Donc il ne valide pas le format d'un MP3. Par contre, il pourrait limiter la taille.

A faire
=======
Comment suivre quelqu'un en consultat sa page publique. Un bouton de demande de contact et interet
en un click. Possible ?

Message anonyme sur la page publique ? Inbox taille maximum.

FAIT: Dans la documentation, dans la section getting started, on pourrait inscrire des hyper-liens pointant
	à l'application. On se retrouverait alors exactement à la bonne place dans bolixo et l'aide nous
	aurait suivi dans un onglet à droite. Donc au lieu de sauter entre l'application et l'aide, les deux
	sont un à coté de l'autre.

bug securité variable jump. À vérifier.

Quand on sélectionne un document, ça ouvre un TAB dans la section de droite.
Si on visionne beaucoup de documents, on doit faire régulièrement ménage.
La programme devrait éliminer le TAB le plus vieux (sel_order le plus petit) et
non modifié.

Le tri des TAB utilise l'identifiant et non le titre. C'est difficile à comprendre.

Tester l'importation de chiffriers et autres documents pour que ça soit utilisable.

On peut savoir si un formulaire a été modifié. On encode une variable 'hidden' contenant le SHA256 de chaque
champ. On peut alors comparer facilement si un des champs a changé sans relire la base de données. En fait
ce travail peut être fait dans le WEBCONTEXT. On peut alors signaler qu'un formulaire dans un onglet
inactif est modifié.

FAIT: On peut utiliser les variables de webtabs pour mémoriser les formulaires actifs dans la section Profile.

Quand on affiche un video, on force l'utilisateur a tout le télécharger (dans talk) même s'il ne l'écoute
pas. Il faut pouvoir télécharger la première image et le bouton play fera le reste. Sinon, ça devient lent.


Il faut que les apis retournant les messages et fichiers retournent le nombre total
disponible. Cela pourrait etre entretenu dans une table à chaque ajout, ou encore
on utilise le mécanisme de MySQL permettant d'obtenir le nombre même si 'limit'
a été utilisé.

FAIT: Mini-photo d'utilisateur. Publique avec un API.

FAIT: Dans le fureteur de fichier, on peut transmettre un fichier lorsqu'on
      click sur un document. Dans la fenêtre, il y a un bouton
      pour copier le fichier vers une des liste talk.
      Ça prend un nouvel API pour juste faire un lien. Genre sendtalk_file.
*** Ça fonctionne, mais comme c'est un lien, on pert l'identité de celui qui
    a fait la copie. Il faudrait ajouter ça quelque part. C'est
    bien qu'on voit les 2 identités (propriétaire du document et
    celui qui a fait la copie.
    Il faut copiedby et modifiedby

Gestion des contacts. On peut refuser et plus tard accepter.

Validation des types de fichiers. Pour l'instant, on établi le type d'un fichier en regardant
le début. Il faut regarder l'ensemble. Il faut trouver des librairies de validations pour les
type image ete video etc... ffmpeg peut faire cela pour les vidéos.

FAIT: Dans le 'talk`, on peut envoyer des messages à des listes de groupes. On peut aussi avoir
	public. Donc on envoie des messages que n'importe qui peut lire. Ça marche alors comme twitter.
	Et c'est là qu'il faut un protocole pair à pair pour optimiser la distibution d'un message.

Il faut que les messages soient signés comme les courriels.
Comment faire pour les vidéos et audios. On pourrait ajouter la signature
dans un champs séparé de la BD (comme le contenu texte).
Il faut que la signature inclue plus d'information: date, destinataires.
Est-ce qu'on devrait mettre l'information sous forme d'entête dans le texte ?

FAIT public:
	Le répertoire/projet "public" d'un utilisateur est visible par tout le monde
	sans login. L'utilisateur doit pouvoir allumer et éteindre cela simplement. Une
	simple case dans son écran de configuration. Le projet public est comme un autre
	projet. L'utilisateur peut créer des groupes et controler les accès. Donc sa page
	publique peut-être entretenu par une équipe. Si il inclue le groupe #all dans la liste
	alors la page devient visible. Pas sure.

	En fait, c'est un sous-répertoire du projet public qui sera affiché. L'utilisateur
	pourra choisir lequel. Cela permet d'avoir une page pour un évènement qui sera allumée
	au moment propice. Le reste du temps, c'est une autre page.

FAIT: Visualisation de la page publique dans la gestion de projet, dans un onglet. On peut
      alors visualiser les différentes versions.

FAIT: L'utilisateur pourra aussi choisir un modèle de présentation. Il pourra décider
      si un sous-répertoire contient des messages ou encore des images qui défilent.

On pourrait avoir une page publique ou semi-publique pour chaque projet, pas juste
le projet public. Cela permettrait à un gestinnaire de publier l'état
d'un projet à tout le monde.

SPAM:
Comment limité le spam. Avec les API WEB, envoyé des messages à tous les utilisateurs
d'une node devient facile et automatisable. On ne peut pas obtenir de liste
d'utilisateur, sauf si c'est publié sur bolixo.org. Mais encore là, on ne pourra
pas extraire de liste, seulement chercher. Il faudra limité les capacités de recherche.
Sinon, ça revient à obtenir une liste complète.

Il faut limiter le nombre de courriel envoyé par un compte par heure ?
Il faut aussi trouver une solution pour limiter la création de compte. Techniquement, on peut
créer un compte en fournissant un autre compte bolixo et utiliser les APIs pour lire le courriel
de validation et y répondre. On peut alors utiliser le nouveau compte pour en créer un autre.
En accumulant beaucoup de compte, on peut alors envoyer des tas de courriels, même si chaque
compte est limité.

Réception de fichier:
	Lorsqu'on reçoit un fichier vidéo, image, etc, on utilise un autre serveur
	pour valider le format. Il faut trouver des librairies qui font cela.
	protocheck pourrait aussi faire les même validations, mais webapi
	ne passe pas par protocheck. Il devrait.
	Donc protocheck devrait filtrer l'envoie de fichier via webapi
	et formulaire HTTP.

	On devrait limiter les durées des vidéos et fichier sons. On évite
	que ça prenne trop de place et aussi que les problèmes de copie de matériel.

Protocole paire-a-paire

	Il faut supporter une personnne avec des millions d'amis.

	Il est anormal qu'un président d'un pays annonce une information via un
	réseau social étranger.

Pour optimiser l'interface, le programme bo-writed pourrait inscrire dans les sessions ouvertes
des dates de mises jour pour différentes informations: inbox, talkbox, .... Quand le javascript
fait du polling pour savoir ce qui a changé, il pourrait simplement faire une requête à bo-session
pour savoir ce qui doit être ré-affiché.

Pour accélérer la résolution d'un répertoire, on pourrait ajouter un bit
appeler shadow à dirs_content pour indiquer qu'une entrée plus récente
existe. Lorsqu'il n'y a pas de threshold, on peut très rapidement identifier
le contenu d'un répertoire, en montant ou descendant.

La table marks pourrait avoir un autre champs indiquant la visibilité ou pas. Cela
permet de d'effacer des documents dans des répetoires que nous ne possèdons pas.
Entre autre dans les inbox de projets.

FAIT: (C'est la section Talk)
En plus des boites de courriels, qui ont un caractère permanent, il y a la boite
qui s'efface tout seul pour les messages sans trop d'importances. Le système ne conserverait
que les 20 derniers par exemple. Il n'y a pas d'effaçage ou de "marqué comme lu". C'est
le pendant des réseaux sociaux. Les messages tels viens tu diner se retrouve là.
L'effaçage fait que les vidéos et photos ajouté là ne consommerait pas grand chose.

On peut créer des utilisateurs externes dans la base de données. Ces utilisateurs
n'ont pas de mot de passe (NULL). Mais ils ont un userid standard. Donc ils peuvent
faire partie de groupe comme n'importe quel autre. Voici des exemples
	bo:usager@node2.bolixo.org
	mail:quelquun@gmail.com
Donc on peut avoir des relations (amis) qui ne sont pas dans bolixo.

Courriel:
	On peut accepter des courriels si l'utilisateur est dans une de
	nos liste. Ou non.


FAIT:	La vue globale fonctionne.
	On voit les boites de courriels associées à nos projets
	et amis. Mais nous avons aussi un vue globale où
	tous les messages sont visibles. Ça évite de visiter
	tous nos projets un après l'autre.

	La vue globale est configurable. On peut sélectionner
	les projets qui y apparaissent. On pourrait faire "mute"
	sur un projet.

Agenda:
	On peut inviter une liste, un groupe, un role ou une personne
	a un évènement. Ce n'est pas explosé. Si on ajoute quelqu'un à un
	groupe, il recevra l'invitation.

tâche:
	Est-ce qu'on peut gérer cela comme les alarmes qu'on assigne
	à un document ?

Lorsqu'un paragraphe d'un message termine avec un point d'interrogation, alors
la réponse à ce message est automatiquement formattée pour qu'une réponse soit fournie.

Il y a des groupes définis par l'administrateur. Il peut en définir plusieurs qui
correspondent alors aux différents départements de l'organisation. Ces groupes ont
des noms qui ne peuvent pas entrer en conflit avec les groupes définis par l'utilisateur.
Genre, ils commencent pas un #. Et le # serait interdit dans les groupes d'utilisateurs.

FAIT: Un message est un fichier dont le nom est son uuid. Il y aura une fonction sendmsg qui
      retournera entre le uuid. Les réponses et attachements iront dans uuid.dir.

FAIT: Comment savoir les messages qui doivent être affichés dans la boite de réception d'un
      utilisateur. Il faut résoudre ce qui doit être fait lorsqu'un message est
      envoyé à
	-Un utilisateur
	-Un rôle
	-Un projet
	-Un fichier Voir Alarmes

Alarmes: Message associé à une action sur un fichier ou répertoire.

FAIT: Non ce n'est pas ce qu'on a fait. Le message n'est pas dupliqué.
	La boite de reception est un répertoire normal. Lorsqu'on envoie un message à un projet, il
	est copié (le lien dans dirs_content) à tous les membres du projet. Ils peuvent alors effacer le
	message de leur boite de réception, le marqué comme lue, etc... Donc il y a un processus
	de copiage. Mais on peut toujours consulter la boite de message d'un projet.
	>>>NON. La seule boite de réception qui contient des messages et le inbox personnel de l'utilisateur.
	Les autres pointent à des espaces partagés. À l'aide d'une table marks, l'utilisateur peut
	indiquer si il a lu un message ou pas.

FAIT: Ajouter un identifiant unique à la table dirs_content. Cela permettra de trier de façon
      précise en utilisant l'identifiant au lieu de la date de modification d'un document.
      Ajout de eventtime plutôt qu'un identifiant unique. C'est cela qui est utilisé comme
      threshold.

FAIT: C'est une table séparée. Cela permet de marqué des documents dans des répertoires où on
	ne peut pas écrire.
	markview: Permet d'annoter si un document a été vue par un utilisateur. Ça pourrait ajouter
	une ligne dans dirs_content avec type='V'.

Une sequence de discussion possède une conclusion que le gestionnaire de projet met à jour.

Un site central permet d'avoir un annuaire de tous les sites. Ainsi on peut trouver quelqu'un sur
une node. Chaque node est libre de publier dans l'annuaire ou non. Ça donne un lieu central
pour trouver quelqu'un.

FAIT: Un groupe peut contenir des utilisateurs, mais aussi des rôles.
FAIT: Sécurité de readmore et appendfile. On doit valider le sessionid. On pourrait tout simplement
	encodé le sessionid dans la table de handle. On verifie que le sessionid est valide
	et ensuite on s'assure que ce handle lui est associé.

FAIT: bofs. Un utilitaire pour faire des cat,cp,rm,mkdir,rmdir,mv
FAIT: copydir. Chaque répertoire et sous répertoire devra être répliqué.
FAIT: rename
FAIT: copy (uniquement pour les fichiers)
FAIT: Certains inbox/projet apparaissent en double a cause du concept de role.

A faire sécurité
================

Valider la robustesse du protocole de sérialisation.
	Terminer les séquences incomplètes après 5 secondes.
	Faire un programme de test qui envoie n'importe quoi.

bolixo:
======

Le principe de bolixo, c'est qu'un message/document peut apparaitre à plusieurs place
dans une hiérarchie de document, comme les liens symboliques. Mais en plus, on peut trouver
d'ou un document provient. On a la relation inverse.

Pour l'instant, il est très facile de trouver quels répertoires référencent un fichier parce
qu'ils ont tous fileid. On peut ensuite retrouver le parent de chaque répertoire jusqu'à la racine.
Ce n'est pas très rapide, mais ce n'est pas quelque chose qui arrivera souvent.

projets:
=======

FAIT: Ça ne fonctionne pas exactement comme ça. Mais ça fonctionne.
	Un projet est en fait un répertoire et une liste de groupe. On peut
	communiquer à chaque groupe séparément via les petits messages
	ou les courriels. Il y a un concept de INBOX partagé.	

	Il a des projets. Les gens peuvent s'abonner au projets.
	Ou aussi directement a la personne.

Un projet est transférable.

On peut envoyer un message a un projet. L'historique est conservé dans le projet. Les membres
du projet recoivent une copie. Dans le monde bolixo, ils reçoivent un lien.

Un projet a des règles de sécurité. Tout message envoyé au projet reste dans le privé ou on peut
faire un 'spin' sur le message et le propager plus loin.

Est-ce qu'il y a des sous-projets. Les gens utilisent les réseaux sociaux pour s'organiser. Ils pourraient
créer l'organigramme du projet avec les sous-groupes.

spin:
=====

Un spin re-publie le message ou le document. Les gens abonnés à la personne recevront le spin.

Ou encore, si le message provient d'un sous-projet, il est transmis plus haut, dont à tous les membres du
projet.

un-spin. Un utilisateur peut faire un un-spin. C'est un moyen poli de dire que ce message n'est pas apprécié.
Il est alors possible d'attacher un message à cet action (une explication) ou encore un message déjà fait. Le unspin
revient à celui qui a fait la spin. C'est privé. Donc le unspin n'est pas un broadcast négatif.

Évènement:
=========

On peut envoyer un message à un évènement.
	Quand quelqu'un consulte un document, le modifie ou le distribue.

	Quand on clique sur un fichier, on peut envoyer un message
		-déclenché par un certain évènement du fichier (accédé, lue, effacé)
		-au propriétaire du fichier
		-à la personne présentement propriétaire.

Pair a pair:
============

Chaque document possède une signature permettant de savoir d'où il vient.

Lorsqu'un document est transmis (spin), on envoie une copie aux pairs avec une date
d'expiration. Le pairs pourra utiliser la copie au début et pourra ensuite la purger et
conserver uniquement l'hyperlien. Donc si un document devient viral, la charge
sera distribuée. Après quelques jours, le serveur qui l'a produit sera capable de prendre la charge.

Comment savoir à qui envoyer le document. On le sait par les relations amis. Ce n'est pas un
broadcast.

Code utilisateur
================

Le code est un identifiant choisi par l'utilisateur. C'est comme un courriel. usager@serveurX.

L'utilisateur et l'administrateur pourront choisir si ils acceptent des messages de l'extérieur ou pas
(courriels).

Messages
========


Tout message possède 2 signatures. Une identifiant le serveur d'origine et l'autre l'utilisateur. L'utilisateur
pourra gèrer lui même sa clé d'identification. À l'aide d'un client, il pourra composer les messages et seul
lui pourra signer ce message. Cela évite les faux messages (vol d'identité).

Il faut que la signature deviennent simple à utiliser et valider, contrairement à aujourd'hui avec les courriels
(personne n'utilise PGP ou très peu).

TLMP
====