Re: [Bitobi-arch] Pré-requis, phase 1: la base.

[Olivier Lourdais]

> > Quelqu'un a un protocole, un scénario ou n'importe quoi à proposer pour
> > l'authentification ?
> >    
>
> Moi :) Enfin, juste pour l'implémentation de base, un truc tout simple,
> pas sécurisé. Enfin, pas sécurisé du tout quoi. Perso, je vois bien, pour
> commencer les tests, une méthode "à la main". Chaque admin de noeud
> calcule/génère une chaine, qu'il envoit à l'admin de l'autre machine. Le
> reste, je te laisse deviner (indice: MD5 toussa). C'est basique, mais à la
> limite, c'est extensible.
Bah je devine pas vraiment.
Pour moi un md5 c'est du domaine du hashcode et du checksum, pas de la 
signature.
Si il s'agit juste de reconnaître les noeuds, l'url de base du noeud ne 
suffit-elle pas dans le rôle de la chaîne dont tu parles ? Je pense 
qu'il s'agit d'un bon identifiant ;)
Enfin je m'attendais à ce que chaque noeud ait une paire de clés 
publique/privée gnupg. Et comme ça quand je veux identifier un noeud que 
je connais, je lui envoies une chaîne en claire, il me la renvoit codée 
avec sa clé privée, et si j'arrive à la décodée avec sa clé publique, 
c'est que c'était bien lui.
Bon après, je ne sais pas si c'est facile à faire, si les bonnes libs 
sont dispo, mais j'imagine qui oui, y'a pas de raison.

> > Mouais, je suis pas franchement convaincu qu'une implémentation over
> > HTTP soit plus facile à créer qu'une implémentation over TCP.
> > Et surtout il ne faut pas oublier qu'une des raisons d'être du bitobi
> > vis-à-vis d'une tribune normale est que chaque noeud ait une charge
> > moins forte à supporter. Il ne faut pas non plus oublier que le mode de
> > fonctionnement d'un noeud est de fournir à tous ses voisins chaque
> > message qu'il produit ou qu'il reçoit, symétriquement chaque noeud
> > reçoit donc chaque message depuis chacun de ses voisins. Si on utilise
> > une surcouche à HTTP, chaque noeud aura à traiter un sacré paquet de
> > requêtes. Je crois que là on passe un peu à côté de l'objectif initial.
> >    
>
> PAs dans le cas d'un réseau maillé complet.
Voir mon aute mail.

> Le problème, c'est que là on
> discutte qu'à deux, et comme on est pas 'forcément' d'accord, ça va pas le
> faire.
Ouaip ça c'est vrai.
\o_ ohé on est là, viendez donc discutailler avec nous.
(j'ai déjà fait un peu de recrutement sur la tribune tout à l'heure ;)

>  
>
> > > Je propose également de choisir des fonctions mandatoires (FOUTAISES!) et
> > > des fonctions optionnelles. Dans ce qu'a proposé Olo, certaines choses
> > > pourraient être implémentées, mais je ne pense pas qu'elles soient
> > > nécessaires, tout du moins dans les premières phases de dev.
> > >
> > >
> > >      
> > Ma position : pas de problème pour ne prendre en compte qu'un
> > sous-ensemble de fonctionnalités dans un premier temps (normal), mais il
> > faut que chaque implémentation gêne le moins possible les
> > implémentations qui prennent en compte plus de fonctionnalités (et donc
> > normaliser ces fonctionnalités dès le début).
> >    
>
> Pas d'accord. Si tu veux faire du XML, c'est pas dur, tu mets les tags
> quand même, mais ils ne seront pas compris, donc pas traités par les
> implémentations plus 'simples'. Si tu fais autre chose, pareil, faut pas
> que les implémentations soient bloqué par le non traitement de ces
> messages.
>
> Autrement dit: les propagateurs ne doivent pas être tributaires de ces .
> fonctionnalités
> Autrement dit: la non implémentation de ces fonctionnalités ne doit pas
> être bloquante en quoi que ce soit.
euh oui, jusque là on est d'accord, c'est grosso-modo ce que je disais.

> Pas d'accord donc pour les normaliser.
Bah si, il faut au moins les normaliser comme "options" ou "extensions", 
sinon ça va être le souk (surtout si on utilise une dtd ou un schéma xml).

> Encore une fois, pour avoir un truc qui fonctionne relativement assez
> vite, faut faire simple, pas vouloir tout faire tout de suite.
>  
Faut un truc assez robuste quand même.
Et puis faut faire gaffe à pas être obligé de se trainer des casseroles 
plus tard à cause de problèmes qui auraient été sous-estimés.