Stéphane Bortzmeyer a écrit 664 commentaires

Mais je ne crois pas que les créateurs de SeenThis l'aient jamais présenté comme un Twitter-Like, complet avec toutes ses fonctions, y compris la porte vers PRISM. La dépêche originale de cette discussion parlait effectivement de Twitter mais c'est maladroit et cela ne se retrouve pas sur le site de SeenThis.

Oui, ce serait un vrai truc intéressant. Yakafokon.

Non, pas du tout, l'objectif n'était pas de copier Twitter. Déjà, c'est du shortblogging, pas du microblogging. Ensuite, c'est plus orienté Web qu'API. Et il doit y avoir plein d'autres différences. À commencer par la plus énorme : les conditions d'utilisation. Lisez-les avant d'utiliser Twitter.

Un article de chercheurs intéressant, qui explore les mêms thèmes : http://arxiv.org/abs/1202.4503

L’article « A Critical Look at Decentralized Personal Data Architectures » est un court résumé des problèmes que pose la conception d’un rézosocio décentralisé ou réparti. Les auteurs notent à juste titre que le problème est difficile et que les projets issus d’un bistrot et spécifiés en cinq minutes sur un coin de table n’avaient aucune chance d’affronter réellement Facebook ou Twitter. L’article décrit bien ces difficultés et les problèmes que cela pose (dans mon exposé à Pas Sage en Seine, je mentionnais uniquement le problème de la découverte mais il y en a d’autres). Ils notent également que les propriétés qu’on attend d’un rézosocio sont souvent contradictoires et qu’il va falloir faire des choix.

Les auteurs critiquent à juste titre la confusion fréquente qui est faite entre caractéristiques techniques d’un système et les valeurs qu’on défend.

L’article étant assez court, pas mal de points ne sont traités que sommairement. Par exemple, les auteurs critiquent les systèmes décentralisés comme obligeant M. Michu a installer et à gérer son propre serveur, oubliant complètement qu’on peut parfaitement utiliser des serveurs gérés par d’autres (associations, entreprises à but lucratif, groupes de copains, etc). Tous les systèmes décentralisés (à commencer par le courrier électronique) avaient pourtant cette possibilité depuis longemps.

L’article erre aussi parfois vers la caricature lorsqu’il explique qu’on ne peut jamais avoir un contrôle complet sur ses données, laissant entendre que, dans ce cas, autant laisser tomber et aimer Facebook. L’idée qu’on puisse vouloir limiter les dégâts (sans pour autant avoir un contrôle complet) ne semble pas mentionnée.

Autre manque, l’idée d’éducation et d’évolution. Pour les auteurs, la mentalité actuelle de M. Michu semble une loi naturelle, non susceptible de changement (« M. Michu s’en fiche de la vie privée »).

« On est sur le web, il faut faire court » On n'a pas la même conception du Web. La page « Seenthis, c'est quoi » fait 5500 caractères. Si c'est trop long à lire, c'est que l'humanité est foutue et doit être remplacée par une espèce supérieure.

Non, SeenThis a une architecture centralisée. Il n'est pas prévu de communication, à part celle que permet déjà le Web (les liens). Le cahier des charges de SeenThis n'était pas du tout de faire une Nième tentative ratée de rézosocio décentralisé.

Excellente idée (XMPP). J'attends le code source avec impatience.

J'attends avec impatience les superapplications Web libres qui vont, je n'en doute pas, être développées avec ces merveilleuses technologies.

Comme je ne programme pas du tout en PHP, je ne vais pas répondre sur la technique mais sur le projet : SeenThis est avant tout un projet éditorial. Son but est le contenu, l'interaction, etc. Les auteurs disent ouvertement que ce n'est pas le code qui les intéresse.

À mon humble avis, il serait donc bon de ne pas discuter que de la technique mais aussi des choix sociaux, de l'interaction etc.

Notez qu'il y a une discussion (critique) de cet article et surtout de ses commentaires sur SeenThis http://seenthis.net/messages/154404

Une très bonne analyse juridique, montrant notamment que l'avocate de Linkeo ne s'y connait pas mieux en droit que Linkeo en sites Web.

Non, les URI "ni" ne sont pas forcément des URL. Ils peuvent l'être (si on met l'autorité) mais ce n'est pas obligatoire.

Et le but est justement de faire mieux que les URN. Ceux-ci ne sont pas « actionnables », on ne peut pas s'en servir pour récupérer une ressource. C'est bien pour cela que les URN ont eu peu de succès en pratique. (Avant les "ni", il y avait eu une proposition de faire la même chose avec des URN, draft-thiemann-hash-urn, mais elle n'avait pas abouti.)

L'article de l'Usine Nouvelle est médiocre. Il s'attaque à une exagération (fin de l'Internet, on va tous mourir) pour passer à une autre (il ne s'est rien passé, tout a été inventé, on vous ment).

La réalité est sans doute plus simple mais apparemment trop nuancée pour certains : il y a bien eu une attaque de grande ampleur, elle a impacté Cloudflare et donc ses clients, le reste de l'Internet a continué à vivre. Et le marketeux de Cloudflare a trouvé malin d'exagérer (exagérer, pas inventer) pour rapporter du business à sa boîte.

Google, ce ne sont pas des tanches. Oui, ils connaissaient le problème et ont documenté leurs solutions :

https://developers.google.com/speed/public-dns/docs/security

Et après, il se moque de M. Michu qui a mis son courrier chez Gmail ? Pas très cohérent.

Cf. la discussion sur le DNS dans l'article de départ (très intéressant, cet article). Évidemment, si on active le service de courrier électronique, le logiciel mettra un MX dans la zone. Évidemment, si on active le service de messagerie instantanée, il mettra un SRV dans la zone.

J'ai quand même un peu l'impression (arrêtez-moi si je me trompe) que pas mal de gens qui commentent n'ont pas lu l'article de départ.

Je n'ai jamais envisagé comme unique solution l'hébergement à la maison, avec un ADSL lent et une adresse marquée comme "résidentielle". J'ai au contraire longuement détaillé l'autre possibilité, celle d'un hébergement sur une machine d'un fournisseur IaaS. Le problème de l'adresse IP disparait, dans ce cas (ainsi que plusieurs autres répétés ici).

Il ne fait apparemment que serveur de fichiers et blog (pas courrier ou IM).

Je comprends cette motivation, je suis pareil :-) Mais la fiabilité et la sécurité d'une machine peu administrée nécessitent une politique plus restrictive. (Après, les hackers pourront toujours faire ce qu'ils veulent, c'est du logiciel libre. Mais il faut que ce soit clairement dit que ce n'est pas le fonctionnement normal.)

Non, je ne pense pas qu'il faille connaître la différence entre SMTP et IMAP. On ne parle pas d'apprendre le courrier, ni de fournir un service pour une grosse organisaton dépendant fortement du courrier pour son activité. On parle de permettre à M. Michu d'avoir du courrier électronique sans vendre son âme à Gmail.

Il me semble qu'un bouton « Activer le service de courrier électronique » devrait suffire. Le logiciel doit ensuite démarrer Postfix et Courier, mettre ce qu'il faut dans le DNS. et hop. Bien sûr, ce n'est pas aussi simple, il y a des pièges mais je ne vois pas de raison pour lesquelles il faudrait comprendre SMTP et IMAP.

Faut se demander pourquoi les trucs bâtis par les hackers ne sont pas utilisés, alors…

Pour l'intégration à Debian, je ne suis pas du tout convaincu. Les cahiers des charges sont trop opposés. Par exemple, la solution d'hébergement doit être robuste et cela veut dire qu'il ne faut pas permettre d'installer des programmes supplémentaires (sinon, vous imaginez le cauchemar pour le déboguage).

Utiliser Debian comme base serait certainement un bon choix technique. Mais cela n'implique pas de s'intégrer au Debian « officiel ».

Je suis preneur de plus de détails sur les NAS en question. Sans même parler de leur licence (beaucoup sont des boîtes noires), il y en a vraiment qui font le courrier, la messagerie instantanée, le blog, et tout ce qui fait une "présence en ligne" ?

FreedomBox est loin d'être prête. Et puis, ce n'est pas sur le même créneau : c'est moitié client et moitié serveur, et ça met surtout l'accent sur l'ultra-sécurité (chiffrement, routage en oignon, etc).

NSEC3 est normalisé dans le RFC 5155 et n'est pas du tout un "certificat de révocation". Une introduction en français à NSEC3 : http://www.bortzmeyer.org/5155.html badfe11a n'est pas un hash mais un sel.