Re: [Bitobi-arch] commentaires sur http://reziztanzia.free.fr/wiki/index.php?pagename=b2bScenarPostPropag

[Aurélien DEHAY]

Estian <address@hidden> writes:

> Olivier Lourdais wrote:

[...]

> | > Déjà,je pense qu'il faut arrêtre de modifier les pages du wiki pour
> | > discuter.. [...] Des objections?
> | nope

Pareil.

> |
> | 1)
> |
> | > Sur le boitakonnage, et la proposition de garder un historique des
> | > noeuds par lesquel un message est passé : est-ce nécessaire?
> |
> |
> |
> | j'avais compris qu'il pouvais y'avoir plusieurs types de noeuds : des
> | noeuds de confiance et d'autres. Et que seuls les noeuds de confiance
> | pouvaient s'échanger la liste des utilisateurs/cookies. Si je me suis
> | trompé, effectivement çà sert à rien de garder l'historique.

Pareil. Je pense pas que ce soit necessaire.

>
> Il me semble que les noeuds 'pas de confiance' ne devraient avoir que
> des rôles passifs, et donc ne pas être capable de relayer des messages,
> donc ne devraient jamais apparaitre dans la liste des propagateurs.. des
> opinions divergentes?

Non.

2/3) Ordre des posts:
[...]


Et hop, un gros snip violent. Voila ma propal a moi que j'ai:

On recoit les posts des autres noeuds de confiance. On le balance
comme ils arrivent dans la base ou quoi que ce soit d'autre. C'est a
la generation du backend xml ou de la page web que l'ordre est
important.

C'est a cette generation que on trie sur le MD5 du post (en plus de
l'horloge). Comme ca, tout les nodes ont les meme posts tries dans le
meme ordre.

[...]


> Je disais 10, à la louche hein.. je suis plus ennuyé par le risque de
> 'split', avec un algo simple comme ça..

Meme 10 c'est pas enaurme. Enfin, deja quand on aura 2 noeuds qui
pourront communiquer correctement...

[...]

> |
> | 6)
> | Proposition d'architecture
> |
> | - les noeuds ne savent communiquer qu'avec les noeuds
>
> [+], les mouling agents (coin², brouteurs) se contentent du xml/html je
> pense

C'est meme l'hypothese de depart qui a ete choisie a l'unanimite pour
faire un truc relativement simple.

>
> |
> | - une catégorie particulière de noeuds : les noeuds passifs : ils savent
> | parler aux noeuds mais ils ne propagent pas les posts
>
> qu'entends-tu par "passifs"? il me semble qu'on était parti sur une
> archi en 'push' : chaque node informe ses copains qu'il a une info.. un
> noeud passif devrait donc être inscrit dans la liste de pairs, ça
> implique de prévoir deux types de noeuds au moins dans les tables.. pas
> impossible, mais est-ce nécessaire? les noeuds 'passifs' ne
> pourraient-ils pas se contenter du xml/html comme les mouling agents?

A voir. C'est plus vraiment des noeuds, mais des similis mouling
agents alors.

>
> |
> | - chaque site a un noeud et (a priori) une interface web/coincoin qui
> | est un noeud passif
>
> L'interface ne pourrait-elle pas être comprise dans le noeud? et aller
> chercher les posts à afficher directement dans la couche persistente, ou
> à defaut la recevoir 'programatiquement', plutôt que comme un message de
> noeud à noeud?

Depend de l'implementation du bouzin. On peut tres bien imaginer
plusieurs programmes qui feraient chacun une tache. Mais encore une
fois, c'est de l'ordre de l'implementation du truc.

>
> |
> | - on peut imaginer des coincoins de seconde génération (cc2g) qui serait
> | des noeuds passifs et qui ne passeraient plus par une interface --> plus
> | besoin d'ouvrir une connexion toutes les 30 secondes, et les posts
> | arrivent en direct
>
> ça en revanche ce serait mignon, et justifierai le principe de noeuds
> passifs, mais demanderai une évolution significative du coin². En plus,
> le coin² devrait ouvrir une socket en écoute, ce qui, derrière un
> firewall, deviendrait problèmatique. çe me gène un peu, je dois dire. Je
> pencherai plus, comme évolution, vers un système d'évaluation de charge
> des noeuds, et une redirection automatique des coin² vers les noeuds les
> moins chargés..

Oula. AMHA, ne grillons pas trop vite les etapes.

>
> |
> |
> | et après on peut ajouter des antigones (noeuds passifs "muets") et plein
> | de jouets dans ce genre
>
> cf supra, il me semble que ceux-là pourraient utiliser le xml.. en même
> temps, d'un point de vue réseau ce serait mieux qu'ils s'abonnent pour
> recevoir les nouveautés que de refresher tous les X.. c'est peut-être là
> que les noeuds 'passifs' seraient une bonne idée.. je pense cependant
> qu'on peut prévoir ça dans une seconde phase, ça ne me parait pas
> prioritaire pour le moment, si?

Le truc du antigone, ce serait hypersimple a faire a partir du moment
ou le truc fonctionnera. Le truc de la recherche , par exemple,
pourrait tout a fait etre inclus dans le noeud. Encore une fois,
implementation.

>
> |
> | penser aussi à une interface d'admin (noeud passif "sourd") pour les
> | plonks, passages en mode bunker, ...
>
> ouais, clairement, à priori une interface ouaibe je dirais

Ou telnet ou etc. etc.

>
> |
> | 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'

Signer les posts demanderai de connaitre la passphrase et de la taper
a chaque fois :) Ou alors de mettre des passphrases vides, mais c'est
moins top. Ou alors on fait du SSL entre les noeuds. Avec certificats
et tout et tout. Deja si les noeuds se reconnaissent comme noeuds de
confiance, ca ira bien pourl 'instant je pense.

[...]