PROJET AUTOBLOG


Geexxx

Site original : Geexxx

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Réflexion sur l’accès au contenu pertinent de manière personnalisé sur diaspora*

mercredi 6 janvier 2016 à 23:34

Cet article de blog deviendra certainement une discussion sur loomio lorsque j’aurais le temps de le traduire. Pour l’instant, l’écrire en Français est plus facile pour moi. Comme mes réflexions peuvent tout de même intéresser (et qu’on peut préférer lire en Français), je les partage ici. Voir aussi cet ancien article sur le même sujet.

Il y a trop de messages dans nos flux

Un réseau social sert majoritairement à partager et à échanger. S’il est correctement utilisé, il peut même permettre une veille efficace et devenir la principale source d’informations. Il suffit pour cela de suivre suffisamment de personnes postant du contenu intéressant. Malheureusement, il peut vite devenir compliqué de faire le tri dans la montagne de messages qui s’entassent dans notre flux. Le nombre de messages qui nous semblent pertinent peut décroître, jusqu’à tomber bien bas, ce qui fait perdre un temps précieux voire nous fait quitter le service.

L’automatisation n’est pas la solution

La solution de Facebook (je ne sais pas pour Twitter, mais j’imagine qu’il y a une pratique similaire) à ce problème consiste à étudier notre usage et notre activité pour filtrer de manière automatique notre flux en nous proposant principalement les personnes et sujets avec lesquels nous interagissons majoritairement. Cette approche pose un problème de cercle vicieux : nous sommes bien évidemment moins susceptible de cliquer sur un contenu qui ne nous est pas présenté, comme nous n’interagissons pas avec lui il nous sera moins souvent présenté, etc. De plus, elle implique de faire de l’analyse des usages et des données, ce que nous essayons de limiter dans le logiciel Libre pour des raisons de respect de la vie privée. À cela, il faut rajouter le fait qu’un ordinateur peut se tromper. Finalement, personne mieux que nous même n’est capable de savoir si un contenu ne nous intéresse ou pas.

Les hashtags, une solution partielle

Nous avons vu que suivre des personnes intéressantes n’est pas une solution suffisante. Ces personnes peuvent parfois poster du contenu qui ne nous intéresse pas. Pire, certaines personnes peuvent parfois poster un contenu qui nous intéresserait, mais poster majoritairement du contenu sans intérêt. Nous pouvons aussi ignorer complètement l’existence d’une personne qui nous intéresserait beaucoup et ne jamais la découvrir. La solution de Twitter et diaspora* à ce problème est le système de hashtag. On peut ainsi se mettre à suivre non pas des personnes mais des sujets, ce qui résout le problème évoqué ci-dessus. Malheureusement, certaines personnes peuvent squatter un hashtag, voir en ajouter systématiquement des dizaines pour tenter de donner de la visibilité à leur message (cas moins régulier sur Twitter où les tweets sont limités à 140 caractères pour le moment). De plus, il est aussi possible d’utiliser un hashtag pour parler de son contraire. Par exemple, une personne postant un article parlant d’un problème sous #windows pourra accompagner son message d’un commentaire comme « Ca ne serait pas arrivé sous #linux ! ». Si nous sommes intéressé par les messages parlant de #linux et donc nous suivons ce hashtag, ce message apparaîtra dans notre flux, alors même qu’il ne parle que du système de Microsoft.

Les expressions booléennes, une suggestion pour diaspora*

Cette idée me trotte dans la tête depuis des années. En fait, je la décris déjà dans la première suggestion de cet article qui date de 2012 ! Il s’agirait de permettre à l’utilisateur d’écrire une requête avec trois entités différentes : les utilisateurs, les aspects et les tags, ainsi qu’avec trois opérateurs (en plus des parenthèses pour déterminer la priorité) : le ou, le et et le non. Un utilisateur pourrait ainsi rechercher #linux && !#microsoft. La réponse à cette requête serait un flux de tous les messages contenant le tag #linux et ne contenant pas le tag #microsoft. Si on se rend compte en plus qu’un utilisateur spamme le tag #linux, on peut aussi l’enlever de ce flux en rajoutant && !@userSpammer. Et voilà, un flux tout propre avec juste ce qui nous intéresse !

Ces requêtes doivent ensuite pouvoir être épinglées pour se retrouver dans la colonne de gauche de la page des flux, afin de pouvoir être sélectionnée facilement sans avoir à réécrire la requête. On pourrait même vouloir lui donner un nom et la définir comme flux par défaut, et, pourquoi pas, combiner les requêtes entre elle toujours avec les trois opérateurs.

Les questions qu’il reste à trancher pour avoir des spécifications complètes :

Github, langages et trahison

lundi 3 août 2015 à 22:00

Avec un ami nous travaillons actuellement sur un bot IRC en Go (Goxxx).

Quelle ne fut pas ma surprise en constatant qu’après avoir ajouté des fichiers HTML (pour les tests), le projet était désormais considéré par github comme un projet « HTML » au niveau de ses statistiques !
Ce problème peut également se produire sur les dépôt ou sont présents des fichiers/librairies « vendored », développées par des tiers mais inclus au projet pour plus de facilité.

Suite à cette trahison et à quelque recherches sur le web, il y a une solution simple: Il suffit d’ajouter dans le fichier .gitattributes du dépôt une des directives suivante pour les fichiers/patterns à exclure des statistiques :

Exemples :

# Traite les fichiers .rb (ruby) comme étant des fichiers Java
*.rb linguist-language=Java

# Ignore les fichiers présents dans le dossier "project-docs" (Considérés comme de la documentation)
project-docs/* linguist-documentation 

# Ignore les fichiers présents dans le dossier "special-vendored-path" (Considérés comme des fichiers "vendored")
special-vendored-path/* linguist-vendored

pour plus d’informations et de détails: https://github.com/github/linguist#overrides

diaspora v0.5.0.0, deuxième

mercredi 27 mai 2015 à 20:14

La sortie est encore récente, et j’ai depuis mis à jour framasphère. Je me suis dit que ca pouvait être sympa de contacter la presse tech francophone pour essayer de faire un peu de bruit autour de cette sortie, alors j’ai écrit un petit mail aux sites que je connaissais. Comme je ne garde jamais rien pour moi, le voici :

La communauté des contributeurs au projet diaspora* est fière d’annoncer la sortie d’une nouvelle version majeure, la version 0.5.0.0. Diaspora* est un projet Libre d’un réseau social décentralisé et respectueux de la vie privée. Il a été lancé en 2010 par 4 étudiants américains. En Août 2012, ils cédaient la gouvernance du projet à la communauté. Cette nouvelle version est donc la cinquième version majeure publiée par la communauté.

Elle contient de nombreuses améliorations, dont notamment des grosses améliorations de l’expérience utilisateur tant sur desktop que sur mobile, beaucoup de refactoring et de changements sous le capot pour de meilleures performances, de nouvelles actions pour les administrateurs, et toujours des efforts pour améliorer la protection de la vie privée de l’utilisateur (voir ce précédent billet pour des détails sur ce point). L’annonce de la sortie est disponible sur le blog officiel (en anglais).

Avec 785 commits changeant 1336 fichiers, 31671 lignes de code ajoutées et 34509 lignes supprimées par 20 contributeurs différents, cette version est la plus grosse jamais sortie par la communauté. Le dépôt github vient d’ailleurs de dépasser les 10.000 stars, ce qui en fait le 3ème projet Ruby on Rails le plus suivi sur github.

diaspora* a connu un regain d’intérêt en France ces derniers mois, notamment grâce au lancement par Framasoft de leur nœud diaspora* framasphère dans le cadre de leur campagne « Dégooglisons Internet« . Lancé en Octobre dernier, celui-ci approche maintenant les 16.000 utilisateurs. Si vous souhaitez (re)découvrir diaspora*, framasphère est un serveur idéal où s’inscrire. N’oubliez pas de suivre des tags pour voir votre flux se remplir de contenu vous intéressant.

diaspora* v0.5.0.0 : Une meilleure protection de la vie privée

vendredi 10 avril 2015 à 12:59

Voici le deuxième article d’une série de 5 sur la sortie de diaspora* v0.5.0.0. Il est consacré aux améliorations permettant une meilleure protection de la vie privée de l’utilisateur de diaspora*, le réseau social Libre et décentralisé. Retrouvez les autres articles depuis celui-ci.

Plus de données en clair dans les e-mails

Lorsque je parle des e-mails à des personnes non techniques, j’explique que l’e-mail n’est pas une lettre mais une carte postale : n’importe qui sur le chemin de la carte peut la lire, et n’importe qui peut la poster en signant du nom qu’il le souhaite. Les communications entre les serveurs diaspora* sont chiffrées et les utilisateurs accèdent au site par HTTPS. Cependant, cette sécurité ne sert à rien si le contenu des messages est envoyé en clair dans les e-mails de notification. Ce n’est maintenant plus le cas dans diaspora*, seul un message générique informant d’une réponse et un lien vers le message sur diaspora* est envoyé (#5494).

Plus de données EXIF sur les photos

Un autre problème courant de vie privée sur Internet vient des méta-données des fichiers, notamment des images. Les métas-données sont des informations liées à un fichier qui décrivent son contexte : le type de fichier, la date de création, la date de dernière modification… Pour les images, les données EXIF vont plus loin en indiquant l’orientation de la photo, les caractéristiques de l’appareil, est-ce que le flash était actif ou non et même, dans le cas où l’appareil est munis d’un GPS (comme c’est le cas d’un téléphone portable par exemple), l’emplacement géographique d’où la photo a été prise. Pour montrer l’ampleur du problème, un bidouilleur s’est amusé à récupérer sur internet un échantillon d’un million de photos publiques de chats et à les afficher sur une carte. Le résultat est assez bluffant. La version 0.5.0.0 de diaspora* permet grâce à un réglage de retirer automatiquement les données EXIF des photos envoyés sur diaspora*. Et fidèle à la philosophie « laisser le choix, mais d’abord protéger », ce réglage est bien sûr activé par défaut (#5510).

Moins de requêtes vers des sites externes

Troisième amélioration et non des moindres : limiter les requêtes de l’utilisateur vers des serveurs externes. Chaque requête envoyé par un navigateur vers un serveur web contient une multitude d’informations pour permettre au serveur web de renvoyer le meilleur contenu possible. Par exemple, le navigateur indique qui il est (Firefox, Internet Explorer…), sa version, son adresse IP, le système d’exploitation sur lequel il fonctionne, mais aussi sa résolution de l’écran, les polices de caractères et ses plugins (Flash, Java…) disponibles… Toutes ces informations mises bout à bout, il devient possible de créer un profil de l’utilisateur quasiment unique (tellement les combinaisons sont nombreuses). Ainsi, il est possible de suivre l’utilisateur de site en site juste en utilisant les informations qu’il transmet. Le projet Panopticlick de l’Eletronic Frontier Fondation vous montre cela très bien.

Lorsqu’un utilisateur affiche un flux diaspora*, son navigateur échange bien sûr avec le serveur diaspora* où il est inscrit, mais pas que. De nombreuses autres requêtes sont envoyées de son ordinateur pour récupérer des données très variées. Par exemple, diaspora* utilise jQuery, une bibliothèque JavaScript. Il est possible de l’importer depuis un CDN, un site qui la met à disposition pour tous les sites qui le souhaitent, plutôt que depuis le pod directement. Les avantages sont multiples : économie de bande passante pour le pod, version toujours à jour, vitesse accrue pour le visiteur car la bibliothèque a probablement déjà été mise en cache par un autre site qui utilise aussi le CDN… Cependant, si elle n’est pas en cache, la lier depuis un CDN implique pour le navigateur de faire une requête vers ce serveur et donc de lui envoyer les informations dont j’ai parlé ci-dessus. Le CDN proposé par diaspora* était celui de Google. C’est maintenant jQuery.com (#5105). Utiliser un CDN pour charger jQuery dans diaspora* est dans tous les cas un réglage à faire manuellement par le podmin, ce n’est pas le comportement de diaspora* par défaut et votre vie privée était ici déjà protégée.

Mais il y avait d’autres domaines où diaspora* pouvait être amélioré pour éviter des requêtes vers un serveur externe. diaspora* propose par exemple de lier son compte Facebook lorsque l’on inscrit. Cela permet notamment de poster des messages depuis diaspora* vers Facebook, mais aussi d’importer des données de Facebook dans diaspora* comme l’avatar de l’utilisateur. Le but a toujours été de stocker l’avatar en local, mais un bug faisait qu’en réalité il était lié directement depuis Facebook. Donc, à chaque fois qu’un utilisateur diaspora* affichait un avatar d’un autre utilisateur lié depuis Facebook, son navigateur faisait une requête vers leurs serveurs. La version 0.5.0.0 corrige ce problème (#5493).

Le plus grand nombre de requêtes fait vers l’extérieur de diaspora* concerne cependant les images. Il y a trois types d’images qui sont intégrées directement dans diaspora* depuis des sites externes : les images embarquées dans le message par les utilisateurs en utilisant la syntaxe markdown, les images ajoutées par OpenGraph qui crée une prévisualisation du site en bas d’un message contenant un lien, et toutes les images en provenance des autres pods (avatar, images uploadées sur un message…). Il n’est pas question de garder ces images en cache, on parle ici de centaine de Go de données : toutes les images du “réseau” diaspora*. Cela poserait de plus des soucis de confidentialité vis à vis des autres pods puisque les fichiers seraient répliqués sur chacun des noeuds du réseau. La version 0.5 propose donc, grâce à Dennis Schubert, l’inclusion d’un proxy en NodeJS : Camo (#5386). Ce proxy peut être activé séparément pour les trois types d’images (markdown, OpenGraph, autres pods). Le pod se transforme en intermédiaire en faisant les requêtes vers le serveur externe à la place du navigateur, puis lui renvoie le contenu. En pratique, cela augmente énormément la bande passante utilisée par le pod. Cette fonctionnalité est donc un réglage non activé par défaut, et ce sera au podmin de décider du niveau de protection qu’il souhaite apporter. Un réglage raisonnable pourrait par exemple être d’activer le proxy pour les images liées avec markdown et pour l’aperçu créé par OpenGraph, mais de faire confiance aux autres pods du réseau et de continuer de charger les avatars et images directement depuis eux. Cette solution atteint sa limite avec l’impossibilité de contrôler l’hébergement choisi par les autres pods. Joindiaspora.com utilise par exemple Heroku, un service d’Amazon AWS, ce qui implique de nombreuses requêtes vers leurs serveurs pour charger les avatars et images des utilisateurs de JoinDiaspora.com.

Il reste un cas principal où des requêtes sont faites directement vers un serveur externe : l’inclusion de contenu tierce directement dans le flux lorsqu’un utilisateur poste un lien d’un site connu par la bibliothèque oEmbed tel que YouTube, Twitter, DailyMotion, Vimeo, Soundcloud et bien d’autres. Il ne s’agit pas ici d’image mais bien de contenu directement (du flux audio ou vidéo par exemple) ce qui fait qu’il n’est pas facile de mettre Camo comme intermédiaire. La nouvelle version de diaspora* n’améliore pas ce problème pour l’instant, les utilisateurs qui souhaitent ne pas faire de requêtes vers ces serveurs peuvent utiliser un module complémentaire comme RequestPolicy pour contrôler les requêtes envoyées par leur navigateur.

La possession de ses données par l’utilisateur

À chaque instant, un utilisateur de diaspora* peut aller dans les paramètres de son compte et demander le téléchargement de ses données. Deux archives sont disponibles, la première contient un JSON avec toutes les informations de l’utilisateur (son profil, ses contacts, ses messages, ses commentaires…) et la seconde contient toutes les photos envoyées sur diaspora* par l’utilisateur. Si cette fonctionnalité existe depuis longtemps dans diaspora*, elle était plus ou moins cassée depuis un moment. Les données étaient sous forme d’un XML qui était parfois incomplet et invalide car il était traité immédiatement par l’application. Avec cette nouvelle version, diaspora* génère un JSON plus facilement réutilisable, mais surtout cette génération a lieu en tâche de fond en étant déléguée à Sidekiq, ce qui évite des problèmes lorsque les messages sont nombreux et que le serveur est surchargé (#5354) (#5499). L’export des photos était lui aussi cassé et a été réécrit pour être aussi délégué à Sidekiq (#5685). Ces améliorations sont une étape de plus vers la fonctionnalité très demandée « migration entre deux pods », qui permettra de transférer son compte d’un serveur diaspora* à un autre. Il reste cependant beaucoup de travail à faire pour y parvenir.

Voilà, c’est tout pour les principales fonctionnalités de protection de la vie privée des utilisateurs dans diaspora* v0.5.0.0. Comme vous l’avez vu, il y a eu de belles améliorations qui montrent que la vie privée reste une des valeurs phares du projet. Gardez à l’esprit cependant que même avec les meilleurs réglages par défaut du monde, un utilisateur qui s’en fiche fera n’importe quoi. Un bon logiciel ne remplace pas une bonne éducation :)

diaspora* v0.5.0.0 est en approche

mercredi 8 avril 2015 à 21:27

Il nous aura fallu environ 6 mois pour sortir une release candidate de la nouvelle version majeure de diaspora*, la version 0.5.0.0. En cause principalement, le nouveau chat intégré basé sur XMPP que nous avons beaucoup de mal à stabiliser. Il est fonctionnel mais a du mal à passer correctement à l’échelle. Une nouvelle version de diaspora* sort en général tous les trois mois, nous avions donc déjà manqué une sortie, il n’était plus possible de repousser encore et toujours la sortie de la 0.5.0.0. Une branche contenant le code candidat à une release a donc été créée il y a un peu plus d’une semaine. Le chat XMPP y est inclus mais marqué comme expérimental et il est fortement déconseillé de l’activer sur un serveur de production avec de nombreux utilisateurs pour le moment. Pour autant, les améliorations sont nombreuses dans cette nouvelle version et il aurait été dommage de vous faire encore patienter.

En fait, les modifications sont tellement nombreuses que j’ai dû découper cet article en une série d’articles. Rien que le plan m’a montré à quel point il devenait gros. Pourtant, j’avais fait un effort, j’avais pris un joli pad dans lequel j’avais retenu uniquement les fonctionnalités essentielles, et tout et tout… Mais rien n’y a fait, il a fallu hacher tout ça et vous le délivrer petit à petit, histoire de faire monter le suspense. Quant-à ceux qui sont sur diaspora-fr.org et utilisent déjà le code de la version 0.5.0.0, vous êtes priés de ne pas tout dévoiler à vos petits camarades ! Laissez-les s’impatienter voyons !

Voici toutefois le sommaire de cette série d’articles sur diaspora* v0.5.0.0 qui vous dévoile les plus grosses améliorations. Après tout, le changelog, bien qu’incompréhensible, est public. Il n’y avait donc pas tellement de raison d’attendre plus. J’ajouterai au fur et à mesure les liens vers les articles lorsqu’ils sortiront (y’a encore du boulot). Le sommaire donc :

Voilà, croyez moi, vous allez en avoir pour votre argent. Comment ça, c’est Libre et gratuit ? Bon, mais si vous voulez quand même investir de l’argent, n’oubliez pas que nous sommes présents sur Bounty Source, où vous pouvez poster des bounties sur des issues github, pour financer le développement des fonctionnalités qui vous tiennent le plus à cœur. Plus d’infos sur le blog officiel.

Dîtes, ça se voit que je suis enthousiaste ?