[Bitobi-arch] ordre des posts, plonkage, et remarques diverses

[Estian]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Je snip comme un goret, pasque ça devient dur à suivre ;)

Xavier MAILLARD wrote:

| >|
| >|
| >| 3)
| >|
| >| > Pour l'ordre chronologique, on s'en tape un peu, en fait. Le
| >| > premier node à recevoir le post l'horodate, les nodes sont tous
| >| > 'synchronisés' sur un même ntp, et c'est marre. Comme dit plus
| >| > bas, l'id unique de chaque post est (est dérivé?) d'un hash
| >| > quelconque, par exemple de l'horodatage + l'id du node d'origine,
| >| > comme ça on retrouve quelque chose de presque chronologique, et le
| >| > cas (rare) de 2 posts à la même miliseconde ne posera 'problème'
| >| > que s'ils se produisent sur le même serveur (sinon le hash sera
| >| > déjà différent). et là, ben on rajoute un suffixe genre 00, 01, ..
| >|
| >|
| >|
| >| bon, je prends un exemple : j'ai trois messages : "pika" envoyé à
| >| 42:42:42.000 depuis le noeud A, "plop" envoyé à 42:42:42.001 depuis
| >| le noeud B et "coin" envoyé à 42:42:42.002 depuis le noeud A j'ai
| >| mon coin coin ou mon browser sur le noeud C scénario : * le noeud C
| >| reçoit les messages du noeud A, mon coincoin affiche : [1] 42:42:42
| >| : pika 42:42:42(-2) : coin * je réponds (via le noeud C) au second
| >| message : 42:43:00 : 42:42:42-2 pan * après un laps de temps
| >| nécessaire, tous les coincoins affichent : [3] 42:42:42 : pika
| >| 42:42:42(-2) : plop 42:42:42(-3) : coin 42:43:00 : 42:42:42-2 pan
| >|
| >| çà risque de faire "désordre" une solution pourrait être de demander
| >| au noeud qui reçoit un message en premier de parser les horloges et
| >| de rajouter les infos nécessaires pour être sûr de retrouver les
| >| liens de "causalité" entre les messages plus tard par exemple, pour
| >| le message de 42:43:00, le noeud C ajoute [42:42:42-2
| >| --> 42/42/2042-42:42:42.002-0/A]
| >| comme çà le coincoin peut se rendre compte que le post de 42:43:00 fait
| >| en fait référence au post de 42:42:42(-3) et activer la surbrillance,
| >| ... correctement
| >| éventuellement il peut même se permettre un s/42:42:42-2/42:42:42-3/
| >| dans le corps du post de 42:43:00 (mais là il faut que le match des
| >| horloges soit plus strict qu'actuellement avec les c² (pour éviter de
| >| remplacer des horloges qui n'en seraient pas) et aussi que les
| >| utilisateurs en respectent la syntaxe)
| >|
| >| il reste quand même une source d'incohérences : si l'état de mon
| >| noeud (C) est [1] quand je commence à écrire ma réponse ("pan") mais
| >| est passé dans l'état [2], composé des 3 premières lignes de [3]
| >| quand il reçoit et traite ma réponse, il ne va pas interpréter mon
| >| horloge correctement et associera à mon post le lien [42:42:42-2 -->
| >| 42/42/2042-42:42:42.001-0/B] !
| >| --> solution possible : pour les messages datés de la même seconde (en
| >| arrondissant), ils sont insérés dans le backend/html dans l'ordre dans
| >| lequel ils arrivent sur le noeud
| >| quand je poste ma réponse, le noeud (enfin l'interface
| web/coincoin) est
| >| donc dans l'état
| >| [2']
| >| 42:42:42 : pika
| >| 42:42:42(-2) : coin
| >| 42:42:42(-3) : plop
| >| et donc l'horloge de mon post est bien interprétée
| >|
| >| bon au final çà peut paraitre beaucoup de bordel pour pas grand
| >| chose, mais je pense que c'est un mal nécessaire
| >
| > Je pense que tu as raison, mais euh.. on n'a pas non plus des mouling
| > agents trans-luminiques.. il me semble (amha et tout) que le cas
| > serait très rare, faudrait que le coin² rafraichisse pile-poil au
| > mauvais moment et tout.. du coup, est-ce vraiment la peine de
| > compliquer, ou peut-on accepter le risque comme 'raisonnable et non
| > bloquant'? à voir, en tout cas
|
|
| Ah non pas d'accord. Bitobi doit être gruik, c'es entendu mais doit
| être blindé pour ça AMHA.

Alors, remarque : le distinguo entre posts de même horodatage est une
feature coin²-only, c'est pas prévu dans la version html de la tribune.
en fait, c'est géré dans wmc², mais je sais pas pour les autres mouling
agents, en fait. soyons donc bien conscient que si on essaie de blinder
l'ordre des messages, c'est une modification fonctionnelle à la tribune.
~ Et plus j'y réfléchi, plus le seul moyen de garantir qu'on fait bien
référence au même post, c'est d'utiliser l'id plutôt que la norloge, et
ça ça puxorerait grave pour les moules-broutteur. Alors si quelqu'un a
une autre idée.. (en fait, on pourrait imaginer une sorte de buffer, qui
permettrait de limiter les risques.. genre, au temps t=42 on n'inclue
dans le backend que les posts jusqu'à t=41, pour laisser le temps à
d'éventuels retardataires.. et ensuite on classe les posts
arbitrairement en fonction de l'id.. mais ça me parait plus gruik
qu'autre chose.

[snip, encore]

|
| >| 7)
| >| Signature des posts
| >|
| >| Je pense qu'il pourrait être intéressant de rajouter une signature
| >| GPG sur les posts : - vérification par les noeuds de confiance que
| >| la signature est bonne (si elle est présente) pour les utilisateurs
| >| enregistrés (non anonymes) - en mode bunker, seuls les posts signés
| >| sont autorisés
| >|
| >| la signature est effectuée : - par le coincoin avec la clé de
| >| l'utilisateur - par l'interface html (noeud de confiance) avec sa
| >| propre clé pour les utilisateurs enregistrés qu'elle connait
| >|
| >| même remarque que pour le 1) mais après tout, il vaut peut-être
| >| mieux penser à blinder le système dès le début ?
| >
| > alors, quand je parlais de signer les posts, je pensais aux noeuds,
| > pas aux agents.. à mon sens, l'authentification par cookie est
| > suffisante, on n'a pas eu, à ma connaissance, de cas de vol de
| > cookie.. et attention ~ à l'overhead que ça entraine pour des posts
| > courts en particulier. Je pense qu'il est plus simple que les noeuds
| > s'authentifient lorsqu'ils démarrent auprès de leurs pairs, et
| > qu'ensuite on n'accepte de messages que depuis des pairs connus,
| > charge à eux d'authentifier les utilisateurs postant depuis leur
| > interface, et de n'accepter que les authentifiés en mode 'bunker'
| >
|
|
| Euh je sais pas si j'ai tout compris mais les anonymes ne pourront pas
| exister ou je fais fausse route ??

Ah non, pas du tout efface (ou plutôt, relis le wiki ;)
Donc je recapépétetitule l'idée du moment..
on a deux modes pour le bouchot : un mode normal, où on peut poster
avec, ou sans authentification : et un mode 'bunker', en cas de boulay,
où l'authentification est exigée pour que le post soit pris en compte
par le premier noeud (et conséquemment par le bitobi). Mais ça, c'est
juste __l'authentification__
Ensuite, y'a un autre concept : les posts anonymes, ou 'signés', et ça
c'est très différent : une moule non-authentifiée ne peu bien sûr poster
que anonymement, vu qu'on sait pas qui c'est. Une moule authentifiée, en
revanche, a le choix. Soit de poster 'signé', et je ne parle pas de
signature gpg là, hein, auquel cas son post apparaitra dans le backend
avec son login, comme c'est le cas aujourd'hui sur le bouchot; soit de
poster anonymement, auxquel cas le premier node, après avoir vérifier
que le post était 'légal', par exemple authentifié en cas de mode
'bunker', va 'oublier' le login de la moule. On retrouve donc le
fonctionnement du bouchot anteboulayien, mais avec la sécurité des
gateaux. le choix se ferait soit avec une préférence attachée au gatal,
soit avec un champs dans le formulaire de post, un truc comme ça..
Donc, bien au contraire, le bitobi va réssuciter les anonymes, sans pour
autant ouvrir la porte aux boulets. Et ça, c'est le deuxième effet bitobi ;)

[snip, encore, ça devient une habitude]

|
| >|
| >|
| >| 8)
| >| vrac
| >|
| >| tous les possesseurs de noeuds signés peuvent plonker/passer en mode
| >| bunker/... qui ils veulent ou il vaut mieux imaginer un système de
| >| vote ?
| >
| > ah, ça.. je dirais, vu qu'on pense partir sur un relativement petit
| > nombre de nodes de confiance, que chaque admin pourra plonker un
| > utilisateur/un node. on peut imaginer que ces commandes soient
| > signées avec la clef de l'admin (ou celle du node qu'il admin du
| > reste), et que chaque node aie une liste des clefs autorisées à
| > l'administrer, pour donner plus de choix aux différents admin. Dans
| > l'idéal, c'est vrai qu'un système de vote serait plus mieux, mais à
| > mon avis très (trop?)  lourd à mettre en place, sans parler de l'algo
| > à trouver pour déterminer le résultat du vote.. peut-être à ranger
| > dans la catégorie 'évolutions'?
|
|
| Hmmm. Je suis pas tout à fait d'accord avec ça. Le fait que les noeuds
| 'admin' seront en nombre restreint me fait craindre qu'une sorte
| d'élite sorte et fasse un peu tout et n'importe quoi. Je suis pour le
| plonkage par les noeuds 'admin' mais que si une majorité l'a décidé. Le
| plonkage devrait faire l'objet au préalable d'une sorte de plébiscite
| et que au moins un certains nombres de noeuds 'admin' en ai fait la
| requête.
|
| Qu'est-ce que vous pensez de ça ? Euh je sais ça fait un peu politique
| mais enfin qui a dit que les bouchots ne devaient pas être
| 'démocratiques' ?
|
| Par exemple imaginons un cercle de noeuds admins N=6, on part du
| principe que au moins 3/4 des noeuds 'admin' ont demandé à plonké tel
| node.
| Ainsi on s'affanchit d'une éventuelle dérive et que les plonks ne se
| fassent de façon systématique 'a la tête du client'. Souvenez-vous par
| exemple des nombreux conflits entre personne. X n'aime pas Y qui
| voudrait qu'il dégage, etc....

ouais.. là y'a à réfléchir, c'est sûr. Je dirais, y'a deux pôles
opposés. D'un coté, le bouchot démocratique, ousque tout se ferait par
vote des moules authentifiée (du reste.. majorité qualifiée, des 2/3,
comment on évite les votes multiples dans un système distribuée...pas
simple tout ça). De l'autre, un bouchot qui dès qu'un boulet commence à
foutre la zone, ou pire trouve à exploiter une faille dans un noeud de
confiance, puisse se défendre très rapidement (une seule personne
vigilante suffit). J'ai pas de réponse toute prête, là, va falloir
causer je pense. Je remarque cependant que, parmis les moules, on n'a
jamais eu de demande de plonkage, sauf à l'encontre de boulets
'consensuels'. Je pense donc que les problèmes de personnes ne seraient
pas trop un problème, maintenant c'est vrai qu'il y aurait un risque
quand même. Un vote convergent de plusieurs admins à mon avis n'est pas
une bonne solution : c'est pas plus démocratique, on remplace une
dictature (bienveillante? ;) par une oligarchie, et on perd la
réactivité du "1 admin vigilant trébuche le boulet".
Enfin, vu qu'on a déjà un présimoule à vie, et un dictamoule
démocratiquement déchu, je suis sûr qu'on trouvera bien un système ;)

|
|
|
| Noyeux réveillon et bonne marée à toutes les moules :-)
|
| zeDek
|
|
bonne marée à toi aussi!

Vincent

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+D2275didzvdbnrURAnMtAJ93geIRCBo9uCeQ1Mo5u3mGaNXLQACdHYWa
PheVP83TO+pYUzKzNF48sq4=
=AeBp
-----END PGP SIGNATURE-----