Il y a quelques jours, j’ai eu la bonne surprise de voir ma demande a la beta de Let’s Encrypt être acceptée. A moi l’argent, la gloire et la crypto !

letsencrypt
Pour rappel, letsencrypt est une autorité de certification (CA) qui ne demande aucune validation humaine de leur part. Pas d’envoie de papiers d’identité ou autre preuves. Pour prouver que vous etes bien possesseur du domaine, il suffit que, lors de la génération du certificat, vous placiez un fichier json accessible a une url « mondomaine.com/.well-known/… ».

La procédure de génération est donnée (et risque d’évoluer d’ici la fin de la beta) mais en résumé:

Make sure your web server displays the following content at                                                                                           
http://mart-e.be/.well-known/acme-challenge/abcdef... before continuing:

{"header": ...}

Content-Type header MUST be set to application/jose+json.

If you don't have HTTP server configured, you can run the following
command on the target server (as root):

mkdir -p /tmp/letsencrypt/public_html/.well-known/acme-challenge
cd /tmp/letsencrypt/public_html
echo -n '{"header": ...}' > .well-known/acme-challenge/abcdef...
# run only once per server:
$(command -v python2 || command -v python2.7 || command -v python2.6) -c \
"import BaseHTTPServer, SimpleHTTPServer; \
SimpleHTTPServer.SimpleHTTPRequestHandler.extensions_map = {'': 'application/jose+json'}; \
s = BaseHTTPServer.HTTPServer(('', 80), SimpleHTTPServer.SimpleHTTPRequestHandler); \
s.serve_forever()"
Press ENTER to continue

Super, seulement wordpress ne me laisse pas créer des dossiers arbitraires dans mon dossier contenant le code (et c’est une bonne nouvelle en soit). Pour résoudre cela, un petit bricolage nginx s’imposait.

HTTPS sur un blog, c'est comme un éléphant-mitrailleuse. Ça ne sert pas a grand chose mais c'est cool!

HTTPS sur un blog, c’est comme un éléphant-mitrailleuse. Ça ne sert pas a grand chose mais c’est cool!


Dans la config nginx du blog, ajoutez un bloc location:

Mise à jour: Michel propose une solution plus simple sans s’ennuyer avec un serveur local en python!

server {
       listen 80;
       server_name mart-e.be;
       location ~ /.well-known {
            proxy_pass  http://127.0.0.1:7890;
       }
       
       # reste de la config pour wordpress
}

Où 7890 est un numero de port totalement arbitraire.
Ensuite, suivant +/- les conseils du wizard de letsencrypt

$ mkdir -p /tmp/letsencrypt/public_html/.well-known/acme-challenge
$ cd /tmp/letsencrypt/public_html
$ echo -n '{"header":...}  > .well-known/acme-challenge/abcdef...
$ python -c "import BaseHTTPServer, SimpleHTTPServer; SimpleHTTPServer.SimpleHTTPRequestHandler.extensions_map = {'': 'application/jose+json'}; s = BaseHTTPServer.HTTPServer(('', 7890), SimpleHTTPServer.SimpleHTTPRequestHandler); s.serve_forever()"

Notez que j’ai changé le numéro de port de 80 a 7890 dans les paramètres de HTTPServer.

On relance NGINX (nginx -s reload), continue l’exécution du wizard (press ENTER) et victoire !

Press ENTER to continue

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/mart-e.be/fullchain.pem. Your cert will
   expire on 2016-01-26. To obtain a new version of the certificate in
   the future, simply run Let's Encrypt again.

Vous pouvez tuer la commande python une fois validé et retirer la config nginx (ou commentez, le certificat beta ne vaut que 90 jours).

En bonus, la config nginx qui va bien:

ssl_certificate /etc/letsencrypt/live/mart-e.be/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mart-e.be/privkey.pem;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
ssl_protocols TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/dhparams.pem;

Avec le fichier dhparams.pem servant à la génération d’une clef diffie-helman, via la commande openssl dhparam -out dhparam.pem 2048

Mozilla a un super générateur de config. J’ai prit la config moderne, désolé utilisateurs de vieux soft, je décroche ainsi un beau A sur le CryptCheck un peu nazi de Aeris !

CrptCheck

Vous pouvez maintenant accéder a mart-e.be en https !

HOT pour Humanitarian OpenStreetMap Team, soit l’équipe humanitaire d’OpenStreetMap. Désolé à ceux qui espéraient un article digne de Sam & Max, on parlera de cartographie aujourd’hui !

hot-logo

Il y a quelques temps, je vous ai fait une présentation d’OpenStreetMap (TL;DR: le Wikipédia de la carte), superbe projet de cartographie communautaire dont je suis particulièrement fan. Cependant, s’il est plutôt amusant de cartographier l’arrêt de bus prêt de chez soit ou la niche du chien, on se lasse vite et doute parfois de l’intérêt de la tâche… Et si maintenant je vous disais que vous pourriez sauver des vies en contribuant a ce projet libre. Et bien sachez qu’il est possible de cartographier dans un but humanitaire.

gerardus-mercator-flemish-cartographer-photo-researchers-inc

Tremblements de terre, inondations, épidémies, famines et j’en passe, les catastrophes ne manquent malheureusement pas et touchent des zones difficiles d’accès (de par la catastrophe, situation géographique, politique, économiques ou autres). Pouvoir ou non faire circuler un camion de vivres ou médicaments jusqu’à un village peut signifier la vie ou la mort dans ces régions. Et pour finir sur un argument moins dramatique, lorsque l’on est trop radin que pour donner 5€ à la Croix-Rouge, c’est toujours plus sexy de dire qu’on a passé son dimanche à mapper une région du Népal touchée par le tremblement de terre plutôt que de glander dans son canap.

Maintenant que vous êtes convaincu de l’intérêt de la chose, comment contribuer ? Commencez par vous tenir informer. Le meilleur moyen est de vous abonner à la mailing list HOT. Le volume varie en fonction des évènements (beaucoup plus ces derniers temps), à lire en diagonale mais au moins ça vous permet d’être au courant des évènements importants nécessitant une action rapide.

Il y a eu une catastrophe nécessitant de mapper une région, vous êtes disponible pour cartographier une région, parfait ! (enfin non mais vous comprenez ce que je veux dire). Rendez-vous sur OSM Tasking Manager et trouvez la tâche créée à ce sujet. Une fois bien avoir lu les instructions (ne mappez que les routes, etc.), sélectionnez un fragment de la carte (si vous n’avez pas beaucoup de temps, vous pouvez même le subdiviser) et verrouillez le pour communiquer aux autres contributeurs que vous travaillez dessus. Vous êtes ensuite libre de choisir votre éditeur favoris. Personnellement j’utilise iD qui a l’avantage de fonctionner dans le navigateur (sans flash) et d’être assez intuitif.

tasker

Par exemple, dans le cas du Népal, la page wiki de la catastrophe, la section Task Manager affiche le progrès et les tâches les plus urgentes à réaliser. N’oubliez pas de toujours bien lire le wiki openstreetmap de chaque pays pour comprendre quelles sont les conventions (par exemple: les routes au Népal) ainsi que des guides au cas par cas, par exemple Nepal remote mapping guide (je sais je parle beaucoup du Népal mais ce n’est pas de gaieté de cœur).

asia-amp

Donc si, à la fin de la journée, vous voulez avoir le sentiment d’aider les gens, c’est un des meilleur projet libre que je connaisse. N’ayez pas peur si vous ne savez mapper qu’une partie du segment, c’est mieux que rien. En cas de doute, vous pouvez toujours demander.

En bref, aucune raison de ne pas participer, et pourtant si utile.

Samedi passé, la vidéo youtube du court métrage Sintel a été bloqué. La raison de ce blocage est une détection de contenu appartenant à Sony dans la vidéo.

Pour ceux qui l’ignorent, Sintel est un film de la Blender Foundation, une association à but non-lucratif développant le logiciel de 3D Blender. Ce film est réalisé principalement à partir de logiciels libres et publié sous licence Creative Commons ainsi que toutes les ressources étant été créées. Ce film est donc loin, très loin d’être la propriété de Sony !

sintel-youtube

Sans surprise, cette censure déclencha un clash sur le web. Comme le dit TorrentFreak, Sony a réussi l’exploit de se mettre à dos les fan de logiciels libres, adeptes de Creative Commons, mouvement anti abus de copyright et groupes de protections contre la censure en un seul coup. Ça mériterait un prix.

Après un weekend de lynchage virtuel et reprise de l’info sur les grands sites d’info, la vidéo est de retour ! Suite à ce coup de pub, Sintel vient même de passer les 4 millions de vues sur Youtube. Houra, faites péter le champomi, on a gagné ?

Non.

Sintel_poster

Si le retour de la vidéo va un peu calmer les foules, le problème de fond reste inchangé. Une compagnie a la possibilité, sans aucune difficulté, justification ou contrôle a priori de censurer du contenu sur lequel elle n’a aucun droit. Un système qui devient la norme sur tous les sites de partage de contenu. Erreur ou choix de nuire à un concurrent ? Quelle que soit la cause, il est anormal que cela puisse se passer sans répercussion (même pas un « désolé »). On imagine facilement les très nombreux autres « faux-postifs » n’ayant pas la chance de bénéficier d’un tel coup médiatique.

De tels évènements montrent à quel point le système actuel ne fonctionne pas et doit changer. Peut-on espérer un changement du coté politique ? Supporter des projets comme MediaGobelin ou Gooseberry est plus que jamais important.

Télécharger Sintel (de façon propre et légale)

PS: ce titre ne veut rien dire, et alors ?

Commentaires fermés sur Pump.io, un nouveau réseau social libre et décentralisé

Faut-il encore présenter StatusNet ? Il est généralement considéré comme le clone libre et décentralisé de Twitter de référence. Une réussite toute relative comparé au nombre d’utilisateurs sur la version propriétaire mais un bon succès quand même par rapport aux autres projets libres du genre. Cependant, pour Evan Prodromou, son créateur, il était temps d’avoir quelque chose de nouveau et plus moderne. Il est donc passé de PHP à NodeJS, de MySQL à NoSQL, de Gitorious à Github et a créé Pump.io. Les concepts de fonctionnement sont légèrement différents : StatusNet est clairement calqué sur Twitter avec la limite de 140 caractères alors que Pump utilise un formatage riche en wysiwyg sans limite de taille, le tout à la sauce Bootstrap. Cependant le public StatusNet est visé puisqu’une migration forcée d’identi.ca (instance de StatusNet rassemblant une très grosse partie des utilisateurs) vers Pump est prévue en avril. La messe étant dite, faisons une présentation de ce nouveau venu.

pompe rouillée

Avec un nom pareil, je trouve quand même que ça part mal.

Protocole

J’avais parlé de ce problème dans mon article précédent : Pump n’utilise pas OStatus (le groupe de protocoles utilisé par StatusNet) et ne sera donc pas compatible avec ce dernier. C’est nul, je sais. Cependant les standards utilisés ne diffèrent pas trop non plus. Les activity streams sont au cœur du réseau (déjà présents dans OStatus sous forme XML mais l’on va encore plus loin cette fois). Activity Stream est un standard initié par Facebook, Google, Microsoft (et plein d’autres gens bien) pour unifier la façon de représenter des actions sur les réseaux sociaux et faciliter l’interopérabilité. Un message d’un serveur Activity Stream à un autre est par exemple :

    {
        "id": "http://coding.example/api/activity/bwkposthw",
        "actor": {
            "id": "acct:bwk@coding.example",
            "displayName": "Brian Kernighan",
            "objectType": "person",
            "url": "http://coding.example/bwk"
        },
        "verb": "post",
        "object": {
            "id": "http://coding.example/api/note/helloworld",
            "content": "Hello, World!"
            "objectType": "note"
        },
        "published": "1973-01-01T00:00:00"
    }

Dans pump, une activité est authentifiée via OAuth, ce qui permet de séparer complètement l’authentification du contenu

POST /api/user/bwk/feed HTTP/1.1
Host: coding.example
Authorization: OAuth oauth_consumer_key="[...]",
    oauth_token="[...]", [...]
Content-Type: application/json

{
    "verb": "follow",
    "object": {
        "id": "acct:ken@coding.example",
        "objectType": "person"
    }
}

C’est simple et clair. Un exemple assez sympa de proof of contest est openframgame.com. C’est un site très simple de simulation de ferme. Vous avez de l’argent avec lequel vous achetez des parcelles, des semences et de l’eau. Vous plantez des semences, vous arrosez vos plantes et les revendez une fois atteinte la maturité. Rien de très intéressant dans le fonctionnement interne mais là où ça peut être intéressant est qu’il communique avec un compte Pump via des activty streams. Le fait que votre plante ait soif ou que vous ayez revendu une parcelle de tomates est une activité envoyée au serveur. Vous pourriez ainsi prévoir des réactions automatisées comme l’envoi de l’action d’arroser lorsque une plante a soif ou poster un message de victoire dès votre premier million amassé. On peut facilement imaginer les nombreuses possibilités si certains services utilisaient le couple activity streams – PubSubHubbub. En parlant de PuSH, Evan a annoncé dans un status vouloir l’intégrer dans pump.io.

Pourquoi pas du RSS (l’enfant pauvre et délaissé du web actuel) me diriez-vous ? Je ne suis pas dans la tête d’Evan mais il a un jour fait une réflexion disant que si Google abandonnait Google Reader (et donc le RSS), c’était sans doute car le RSS est très primitif. Pas de principe de conversation, on reste dans un schéma de producteur-consommateur qui ne correspond pas web social actuel. Personnellement, je ne pense pas que le RSS soit dépassé (car le schéma producteur-consommateur convient très bien à certains types de contenu) mais le rejoins sur le fait qu’il n’est pas adapté aux réseaux sociaux. Un flux public en RSS pour suivre les messages d’une personne peut être utile (je l’avais suggéré) mais ne doit pas être le protocole central pour l’interaction (ce qui était le cas dans StatusNet).

Ce qui est génial avec cette utilisation des activity streams est qu’il n’y a plus de formats différents pour l’API publique, la communication entre serveurs ou le flux d’un utilisateur : tout est activité (ou liste d’activités) au format JSON. J’envoie une activité (après authentification avec OAuth) avec le verbe « follow » à mon serveur pour donner l’ordre de suivre quelqu’un et je reçois en réponse, en cas de succès, l’activité qui apparaîtra dans mon flux. Même l’interface web est en fait un client web utilisant des activités avec le serveur. La plupart des actions (par exemple l’enregistrement d’un nouvel utilisateur) se fait via des activités.

Je vous laisse lire la page API.md pour plus de détails mais cela explique bien le fonctionnement général. C’est simple et propre, j’aime.

Tester

À quoi ressemble ce service ? C’est très facile, allez sur la page Try it qui vous redirigera aléatoirement vers une des 10 instances déployées par Evan. Contrairement à StatusNet qui avait identi.ca comme point central du réseau (au point où les gens confondaient parfois les deux et certains clients ne supportaient qu’identi.ca), Evan a voulu que Pump fonctionne réellement comme une fédération d’instances décentralisées.

pump-e homepage

Inscrivez-vous sur une instance, suivez d’autres gens (en passant par Login -> Account on another server? dans le cas d’utilisateurs sur d’autres serveurs), envoyez des messages et des images. On n’a pas encore toutes les fonctionnalités de StatusNet mais ce n’est pas loin.

Installation

Bon fini de rire, comment on déploie son instance sur son serveur ? Bonne nouvelle : il est assez simple de faire tourner un site en NodeJS. Mauvaise nouvelle : pour ceux qui font tourner plusieurs services sur une même machine via Apache ou Nginx, déployer Pump risque de vous poser des problèmes. Votre serveur web habituel écoutant sur le port 80 ou 443, il y a conflit avec NodeJS voulant écouter sur le même port.

Plusieurs possibilités s’offrent à vous :

  • utiliser pump seul sur le port 80 ou 443 (pas pratique)
  • utiliser pump sur une IP interne ou différente de celle utilisée par Apache/Nginx (pas facile, peut être fait en utilisant une machine virtuelle par exemple, configuration ici pour apache et ici pour nginx)
  • utiliser un port différent pour NodeJS avec un proxy redirigeant vos connexions vers le port 80 (perte de performance)

Il faut savoir que NodeJS a une bonne gestion de la concurrence ce qui lui permet, entre autres, de si bons benchmark. En utilisant un proxy, vous empêchez cette concurrence et réduisez les performances de Node à celles d’Apache. C’est dommage mais pas insurmontable non plus.

Après recherche, j’ai finalement trouvé deux systèmes fonctionnant pas trop mal avec Varnish (système de cache) et Apache : soit tout fonctionnant sur le port 80 avec Varnish servant de proxy, soit avec Pump écoutant sur le port 443 et Apache sur le port 80. Voulant utiliser du SSL pour pump, j’ai choisi la deuxième solution avec un certificat CaCert. Ci-dessous les explications des deux méthodes :

Tout sur le port 80

Première méthode : on n’utilise pas de SSL et fait tout tourner sur le port 80. Pour cela, j’utilise Varnish pour faire la différence, en m’aidant de ce tutoriel.

Configurez Varnish pour écouter sur le port 80 en modifiant le fichier /etc/default/varnish

DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc,256m"

Créez le fichier /etc/varnish/default.vcl pour indiquer la redirection

backend apache {
    .host = "127.0.0.1";
    .port = "6001";
}
backend node {
    .host = "127.0.0.1";
    .port = "6002";
}
sub vcl_recv {
    if(req.http.host == "pump.mart-e.be") {
        set req.backend = node;
    } else {
        set req.backend = apache;
    }

    if (req.http.Upgrade ~ "(?i)websocket") {
      return (pipe);
    }
}
sub vcl_pipe {
  if (req.http.upgrade) {
    set bereq.http.upgrade = req.http.upgrade;
  }
}

En cas de domaine contenant « pump.mart-e.be », on redirige vers le port 6002, autrement vers le port 6001. Les commandes avec « pipe » étant pour permettre le fonctionnement des websockets à travers Varnish. Il vous faudra ensuite faire écouter Apache sur le port 6001 au lieu de 80 en modifiant le fichier /etc/apache2/ports.conf.

NameVirtualHost *:6001
Listen 6001

et en changent tous vos <VirtualHost *:80> par <VirtualHost *:6001> dans la configuration des sites.

En ce qui concerne pump en lui même ce n’est pas trop compliqué. Le fait qu’on utilise le port 6002 pour pump vous permet de lancer node avec un utilisateur non-root. Pump ne fonctionne pas (encore) bien avec la version 0.10 de NodeJs (il manque même certaines dépendances je pense), préférez donc la 0.8. Comme pump.io est encore en développement actif, on préférera la version git à mettre à jour régulièrement. Les explications ci-dessous utilisent mongodb mais vous pouvez utiliser un autre service tel que Redis ou même laisser le « disk » par défaut pour ne pas avoir de base de donnée (attention aux performances).

# mkdir /var/www/pump && cd /var/www/pump
# git clone https://github.com/e14n/pump.io
# cd pump.io
# npm install
# cd node_modules/databank
# npm install databank-mongodb

Utilisez le fichier pump.io.json.sample pour créer le fichier /etc/pump.io.json. Voici le mien :

{
    "driver": "mongodb",
    "params": {"host": "localhost", "port": 27017},
    "secret": "azerty12345",
    "noweb": false,
    "site": "pump-e",
    "owner": "mart-e",
    "ownerURL": "http://mart-e.be",
    "port": 80,
    "serverUser": "www-data",
    "hostname": "pump.mart-e.be",
    "address": "127.0.0.1",
    "nologger": false,
    "uploaddir": "/var/www/pump/uploads",
    "debugClient": false,
    "firehose": "ofirehose.com"
}

Installez bien le paquet mongodb et démarrez le démon (ici sur le port 27017). N’oubliez pas non plus de créer le dossier uploaddir mentionné. Lancez pump via

$ node bin/pump &> pumpd.log

ou utilisez la commande forever (npm install -g forever) pour quelque chose de plus stable. Si vous sauvegardez les logs dans un fichier, vous pouvez les consulter via bunyan (npm install -g bunyan et puis tail -f pumpd.log | bunyan), ça en facilitera grandement la lecture.

Et ceci était un des premiers services à interagir avec pump, c'est beau !

Et ceci était un des premiers services à interagir avec pump, c’est beau !

Pump en SSL

La config précédente est bien, mais c’est encore mieux si on utilise du HTTPS ! Trouvez-vous donc un certificat SSL (openssl req -nodes -new -keyout server.key -out server.crt) et envoyez-le sur votre serveur. Comme on ne veut pas produire de page d’erreur quand les gens essayent d’accéder à pump en HTTP, on va utiliser Varnish pour faire une redirection, status HTTP 302. Le fichier /etc/varnish/default.vcl devient donc :

backend apache {
    .host = "127.0.0.1";
    .port = "6001";
}
sub vcl_recv {
    if(req.http.host == "pump.mart-e.be" && req.http.X-Forwarded-Proto !~ "(?i)https") {
        set req.http.x-Redir-Url = "https://pump.mart-e.be" req.url;
        error 750 req.http.x-Redir-Url;
    } else {
        set req.backend = apache;
    }

    if (req.http.Upgrade ~ "(?i)websocket") {
      return (pipe);
    }
}
sub vcl_error {
  if (obj.status == 750) {
    set obj.http.Location = obj.response;
    set obj.status = 302;
    return(deliver);
  }
}
sub vcl_pipe {
  if (req.http.upgrade) {
    set bereq.http.upgrade = req.http.upgrade;
  }
}

Attention, si vous avez la version 3 ou plus de Varnish (dans Debian stable c’est encore la 2), la concaténation se fait avec un +, la ligne de calcul d’URL devient donc : set req.http.x-Redir-Url = "https://pump.mart-e.be" + req.url;

Varnish ne gère pas le trafic SSL donc on est obligé de rester sur le port 80 pour ce dernier.

Rien de change du coté d’apache (par contre faites bien attention dans le fichier ports.conf de ne pas écouter sur le port 443) mais le fichier de config de pump devient :

{
    "driver": "mongodb",
    "params": {"host": "localhost", "port": 27017},
    "secret": "monkey1",
    "noweb": false,
    "site": "pump-e",
    "owner": "mart-e",
    "ownerURL": "http://mart-e.be",
    "port": 443,
    "serverUser": "www-data",
    "hostname": "pump.mart-e.be",
    "address": "pump.mart-e.be",
    "nologger": false,
    "uploaddir": "/var/www/pump/uploads",
    "debugClient": false,
    "firehose": "ofirehose.com",
    "key": "/etc/ssl/server.key",
    "cert": "/etc/ssl/server.crt"
}

Notez que le champ « address » est passé de 127.0.0.1 à pump.mart-e.be. Sans cela, je n’ai pas réussi à accéder à mon serveur depuis l’extérieur. Ajoutez également l’URL de votre serveur pump (pump.mart-e.be ici) dans le fichier /etc/hosts pointant vers 127.0.0.1. Ainsi, la boucle est bouclée pour l’accès en local.

Via mes tests, j’ai noté que les serveurs semblaient retenir les précédentes informations de connexion. C’est-à-dire que les serveurs avec lesquels j’avais interagi à l’époque de mauvaises configs ou lorsque je tournais sur le port 80 semblent avoir retenu ces infos et je n’arrive plus à les contacter. J’ai ouvert un bug report à ce sujet. En attendant que cela soit réglé, faites bien attention de choisir votre mode de connexion et de vous y tenir.

Les clients

C’est bien beau d’avoir une bonne API mais qu’en est-il des clients externes ? Hélas, on n’en est qu’aux débuts. Il existe actuellement une librairie en python PyPump, utilisée par Muon, un client ncurse l’utilisant. C’est tout à ma connaissance…

Le fonctionnement de l’API semblant assez simple, ça ne devrait qu’être une question de temps avant l’apparition de plus de clients mais actuellement c’est un frein certain à l’adoption de pump. Si vous voulez recevoir la reconnaissance de toute une communauté (1170 personnes aux dernières nouvelles), c’est l’occasion rêvée pour faire un peu de développement !

Les services externes

Si vous voulez passer à Pump, une fonctionnalité intéressante est les bridges avec les autres réseaux. C’est dans ce but que pump2status a été créé. Pour l’instant, ce site vous permet de lier votre compte pump à votre compte StatusNet et vous permet de découvrir les gens ayant fait la transition (comme moi !). Dans le futur, ce site vous permettera de publier sur StatusNet vos activités Pump. Sont également prévus, par ordre de priorité et hackerliness Google+, Twitter, Facebook sans doute même des Foursquare, LinkedIn et Instagram plus tard. En raison du bug des anciennes configs mémorisées, pas certain que vous me trouverez (si vous voyez mart@pump.jpope.org, c’est mon compte de test, je ne devrais plus l’utiliser).

Là où Status.Net englobait un maximum de fonctionnalités, le but de Pump.io est d’être beaucoup plus minimaliste dans son mode de fonctionnement et de se baser sur des services externes. Les fonctionnalités de gestion du spam sont par exemple déléguées à activityspam (dont spamicity.info est une instance, wiki) ou le service OFireHose est utilisé pour faciliter la fédération du contenu public (dont ofirehose.com est une instance).

Les passerelles fonctionneraient avec ce même principe. On pourrait ainsi avoir une application externe s’occupant de récupérer du contenu venant de Twitter et de le convertir en activités poussées vers un compte pump. C’est une des possibilités parmi d’autres mais le principe reste d’utiliser des services externes.

L’idée (pas mauvaise) est de garder le coeur de Pump.io minimale pour avoir quelque chose de robuste et hack-friendly. Mon seul regret est l’absence d’extensions, je ne suis pas certain que le modèle de services externes fonctionne dans tous les cas de figure (pour une modification des templates par exemple).

Le futur

Dans une présentation datant de février dernier, Evan annoncait vouloir migrer les serveurs identi.ca de Status.Net vers pump.io en avril 2013. Les inscriptions sur identi.ca sont bloquées depuis quelques jours. On verra si ça pourra se faire mais je pense que le logiciel n’est clairement pas encore assez mature pour faire la transition aujourd’hui.

Vous l'avez rêvé, e14n n'a fait : le bouton « Je n'aime pas » !

Vous en avez rêvé, e14n n’a fait : le bouton « Je n’aime pas » !

Un des soucis potentiel est que la transition casserait tous les clients Status.Net (n’utilisant plus l’API à la Twitter). Une possibilité serait de maintenir une compatibilité avec un bridge entre les deux. J’avais vu cette suggestion faite par Evan (mais n’arrive plus à retrouver le lien). Cela faciliterait grandement les choses le temps de la transition.

Si la sauce prend bien, Evan espère voir les gens adopter massivement pump.io et développer pour celui-ci. Les possibilités d’utilisation du réseau sont assez larges et intéressantes. Openfarmgame était une démo simple. Ih8.it en est une autre. On pourrait même imaginer des analyses globales des comportements via les publications poussées sur ofirehose (de la pub ?). Les principes de fédérations semblent bien réfléchis, et l’on devrait éviter les travers rencontrés avec StatusNet et identi.ca.

Si vous ne voulez pas passer à Pump.io (parce que ça ne correspond pas à ce que vous cherchez), faites une sauvegarde de votre compte identi.ca et utilisez Status.Net sur une autre instance (c’est le moment de passer à l’auto-hébergement). N’oubliez pas, ce n’est pas parce qu’identi.ca et Evan passent à Pump.io que la communauté est obligée de suivre. C’est du libre après tout.

Pump est encore un peu jeune mais néanmoins déjà utilisable. Essayez-le, faites-vous un avis et choississez ensuite si vous voulez rester sur StatusNet ou passer à Pump (ou utiliser les deux ou aucun). Je ne compte pas encore remplacer mon compte StatusNet par Pump mais ça sera sans doute le cas un jour (et me permettra d’abandonner définitivement mon compte Friendica inutilisé). En tout cas, espérons que ce réseau ne soit pas encore « un parmi tant d’autres ».

Commentaires fermés sur Les API mortes se ramassent à la pelle


Les souvenirs et les regrets aussi.
Mais mon serveur silencieux et fidèle sourit toujours et remercie la vie.
Je t’aimais tant, tu étais si standardisée, comment veux-tu que je t’oublie ?

– Jacques Prévert.

Les réseaux libres et décentralisés c’est beau, pas de censure ou exploitation de vos données, bel exemple de liberté d’expression. Chacun choisissant son serveur, on évite les problèmes de points de passage uniques et diminue les problèmes en cas de défaillance d’un nœud. Enfin dans la théorie parce qu’en réalité c’est complètement le bordel. Les réseaux sociaux libres fleurissent un peu partout mais il n’y a pas moyen de s’entendre.

La semaine passée, pump.io venait de sortir sa version 0.2, une première release après 4 mois de développement (c’est là qu’on se rend compte que Diaspora avec ses 2 ans de développement s’est bien foutu de nous). Pump est un projet de Evan Prodromou, le créateur de StatusNet, et présenté comme la succession de ce dernier (prévu pour la 0.3, en avril 2013, les inscriptions sur identi.ca sont d’ailleurs désormais gelées). StatusNet continuera a vivre et être maintenu mais il ne faut pas s’attendre a voir de grandes nouveautés apparaître. Pump est écrit en NodeJS et avec une base de donnée NoSQL (MongoDB & co). Je n’ai aucun problème avec le fait d’abandonner le couple vieillissant PHP/MySQL (au contraire). Le point problématique est un aspect que l’on voit apparaître très souvent avec les réseaux sociaux libres : il n’utilise pas OStatus mais une nouvelle API. OStatus est une suite de protocoles (Atom, Activity Streams, PubSubHubbub, Salmon et Webfinger) qui permet de se mettre d’accord sur la façon dont deux serveurs OStatus peuvent communiquer. C’est grâce à OStatus que je ne suis pas obligé d’utiliser StatusNet pour communiquer avec quelqu’un l’utilisant, je peux utiliser Friendica par exemple. Cependant Friendica est un peu l’exception qui confirme la règle, a part lui qui met un point d’honneur a être compatible avec plusieurs réseaux, les autres utilisent systématiquement des manières propre pour communiquer.

Prenons l’exemple de Tent, un nouveau protocole décentralisé assez sympa (dont TentStatus est la partie permettant le microblogging). La façon de voir les choses est intéressante et suis convaincu qu’on puisse voir de chouettes projets apparaître (comme la page Related Projects le montre). Cependant ils ont fait le choix de recommencer from-scratch et cassant toute compatibilité. Les serveurs Tent ne peuvent parler qu’avec des serveurs Tent. Les raisons avancées pour ne pas utiliser OStatus sont discutables : pas de messages prives, impossible de changer de serveur en gardant les relations, pas d’API standard pour l’interaction. Mais comme mentionné dans un commentaire, c’est plus drôle de partir de zéro.

installation-parabole

Avec cette parabole Turbo+ 2.0, nous devrions enfin a comprendre leurs messages codés avec ce mystérieux « XMPP »

Vous vous souvenez de Diaspora ? Belle levée de fond, beaucoup d’espoirs, deux ans de développement pour finalement abandonner le projet a la communauté. Les créateurs décident de se concentrer sur leur sorte de générateur de meme (qui utilise ironiquement Facebook-connect, un bel aveu d’échec). Il semble avoir une bonne relève et il est possible que ce projet aboutisse a quelque chose mais Diaspora part avec une mauvaise base : un protocole interne quasi inexistant (qu’on pourrait presque qualifier de propriétaire). Diaspora avait été conçut sans trop savoir où aller puisque l’API n’était pas documentée et changeait tout le temps. Le projet Friendica a essayé d’être compatible avec celui ci mais a rencontre de nombreuses difficultés. Il semblerait que la communauté a prit conscience de ce problème puisqu’ils essayent d’être compatible avec d’autres réseaux. Personnellement, j’ai abandonné mais espoirs concernant Diaspora mais je peux changer d’avis, wait and see… ou pas.

Ces deux exemples ne sont pas les seuls, dans les plus connus on a aussi Movim (a base de XMPP, pas d’interopérabilité avec d’autres API type OStatus) ou SalutAToi (utilise une API basée sur XMPP documentée mais de leur cru quand même). Notons les bons élèves que sont Friendica et BuddyCloud puisqu’ils supportent plusieurs standards.

Pour revenir a Pump, Evan avait sans doute de bonnes raisons de changer la façon d’interagir entre serveurs, il s’y connaît en réseaux décentralisés et API. En raison de quelques problèmes avec StatusNet, il a préféré repartir sur une nouvelle base. Il annonçait quand même qu’un effort serait fait pour être compatible avec StatusNet. Cependant, l’API de base reste différente, toutes les fonctionnalités devront être adaptées pour faire la transition.

Pour se rendre compte du problème, imaginons maintenant que StatusNet ou Diaspora soient complètement abandonnés par les développeurs et ne soient plus maintenus. Les logiciels ont amassés une bonne base d’utilisateur mais ces utilisateurs vont lentement migrer vers des solutions plus modernes et maintenues. Sans l’émergence d’une solution supérieure, ils vont se diviser, se tournant peut être même vers une solution propriétaire. Cette migration se fera petit a petit, avec une base d’utilisateur ne voulant pas faire de migrer en raison de la communauté déjà présente sur son vieux réseau. Si ces logiciels ne sont plus maintenus, des Pump ou Friendica seront sans doute moins tentés de continuer a maintenir un niveau de compatibilité vers eux. Les nouvelles fonctionnalités ne seraient pas portées en OStatus. La communauté se retrouverait encore plus fragmentée. C’est évidement un scénario peu probable (déjà car OStatus n’est pas utilisé que par StatusNet) mais cela montre le problème des multiplications de standards : division de la communauté encore plus accentuée en cas d’abandon de projets.

Se mettre d’accord sur un protocole standard c’est une condition essentielle pour le succès des réseaux libres décentralisés. Sans cela, je ne pense pas que l’on pourra dominer les réseaux propriétaires centralisés ayant l’avantage de ne pas avoir a se soucier de ce problème. Je ne critique pas un standard en particulier (je ne me permettrais pas d’en désigner un supérieur aux autres), que ce soit OStatus, Pump, Tent, Diaspora ou un autre à base de XMPP, il faut se mettre d’accord sur une API commune et il faut arrêter d’en développer une nouvelle pour chaque logiciel. Toutes les API ne sont sans doute pas compatibles avec tous les cas de figure (sans parler de l’école HTTP vs XMPP) mais il y a sûrement moyen de dégrossir. Créer c’est bien, améliorer l’existant, c’est mieux.

CC-BY-NC XKCD

CC-BY-NC XKCD

css.php