• Pour commencer à décentraliser un peu #seenthis j’ai bricolé un système d’import/export des seens .

    Export : j’ai choisi, après avoir pas mal hésité, un format « email », avec l’idée de pouvoir importer les messages dans un client mail ou news, et en espérant que ces derniers sauront refléter les fils de discussion.

    Import : l’import d’un email se fait si ce dernier n’existe pas dans ma base (l’identifiant étant un UUID attribué par seenthis, et reflété dans le champ Message-Id) ; ou si la date de modification du fichier est plus récente que la « date_modif » du message dans la base.

    (Je n’ai pas traité la suppression, j’imagine qu’on ajoutera un entête ad-hoc disant « message supprimé », mais je n’ai pas regardé s’il existait un standard pour cela.)

    A titre d’exemple, un message (ici une réponse) ressemble à ça :

    Message-Id: <52d3ae2a-7440-4c6c-b4b1-f4cbecc31efa>
    Date: Mon, 13 Jan 2014 10:13:14 +0100
    From:  <fil@seenthis.net>
    Subject: Hello World
    In-Reply-To: <52d3a4a7-2db4-4bf6-9211-efe4b236d063>
     
    Hello World http://rezo.net/ cool

    Comme on voit le « subject » est calculé à partir du contenu, comme le « title » des pages seenthis ; mais il est uniquement là à titre décoratif — lorsqu’on réimporte seul le body est pris en compte.

    J’ai commencé à programmer le fait d’exporter aussi la version HTML en parallèle (via multipart/alternative) mais il fallait réfléchir à la question des images, qu’il serait sympa d’avoir en local, mais qui demandent un peu plus de programmation. Je préfère savoir d’abord ce qu’en pensent les gens qui s’y connaissent mieux, je pense notamment à toi @stephane).

    J’ai posé le script ici : https://gist.github.com/Fil/8407898

    Au quotidien je me demande quel usage on pourra faire de ces exports :
    – un backup complet en synchronisant tout
    – une version décentralisée en synchronisant tout en bidirectionnel
    – que chacun puisse avoir une copie de « ses » seens par un rsync bien choisi (?)
    – que chacun puisse s’abonner à son flux par IMAP ?

    Par ailleurs, je pense qu’il faudra traiter la possibilité de répondre par mail et que ça vienne s’afficher sur le site.

    • Mettre en favori depuis l’email comme on met en SPAM en SPIP 3.0 + notifications aussi serait cool.

      Avoir un statut « A lire plus tard car semble vachement cool mais là j’ai pas le temps » aussi que l’on mettrait depuis le mail ou l’interface... mais bon je suis peut être le seul à ne pas trouver de temps...

    • Ah non @kent1, je confirme, car actuellement on est plusieurs à utiliser le favoritisme pour divers besoins totalement différents, càd :
      – soit garder un fil d’une autre personne dans sa boite à soi
      – soit dire qu’on est d’accord avec la personne ou qu’on veut la mettre en avant
      – soit garder en mémoire des choses à lire plus tard !

      Et c’est ce dernier point qui est problématique à mon avis, car je pense que le favoritisme ne devrait pas servir à ça : il ne devrait servir à mettre des choses dans sa liste que quand on veut vraiment les garder. Alors que « lire plus tard » c’est autre chose.

      Enfin bon, c’est plutôt un autre fil de discussion à faire pour ce besoin je crois, car ça n’a pas trop de rapport avec la sauvegarde. Mais je plussoie quand même carrément pour qu’apparaisse cette fonctionnalité.

    • En parlant de fils et d’emails, dans mon client mail, je ne vois pas les mails de seenthis par thread, ce qui serait bien pratique. Si je comprend bien, il suffirait d’ajouter In-Reply-To (comme décrit par @fil) dans les mails envoyés par seenthis à chaque nouveau commentaire, ce qui permettra au client mail de recréer le thread.

      À propos des Message-ID, @fil, tu proposes un UUID. Pour info, GitHub utilise qqch qui ressemble beaucoup plus à une URL, par exemple :

      Message-ID: <openlayers/openlayers/pull/1055/issue_event/57699872@github.com>
      In-Reply-To: <openlayers/openlayers/pull/1055@github.com>

      Pour le coup, ça ne va pas trop dans le sens de la décentralisation, mais c’est plus explicite.

    • Et sinon, je plussoie pour le choix de l’email comme format pivot.

      Et plus généralement, je me dis que l’email (grâce à #IMAP) est certainement le format le plus adapté et utilisé pour la conservation des données personnelles (messages, photos, documents) sur le long terme : ça reste des années, on ne perd rien, on peut déplacer d’un serveur à l’autre, les clients mails indexent tout très bien.

    • je comprends la demande mais ça n’a vraiment rien à voir avec le sujet initial, qui est l’import/export de seens

    • L’idée d’un seenthis décentralisé voire avec plusieurs implémentations possibles m’intéresse énormément. Il faudrait que chaque serveur parle avec chaque serveur pour récupérer les derniers messages. ça le parait possible mais assez complexe, en particulier la découverte de serveurs seenthis. Mais au niveau de la décentralisation ce serait juste super. Est-ce que chacun peut avoir son propre serveur seenthis pour l’instant ?
      Ce qui risque d’être lourd c’est le dialogue entre les serveurs. D’une part tous devront dialoguer constamment pour synchroniser leurs messages, d’autre part ils ne devront récupérer que les derniers posts/les posts modifiés/supprimés.
      Il faudrait également mettre l’adresse du serveur dans le message id.

    • Il faut gérer pas mal de choses en même temps en effet, notamment :
      – comment définit-on les UUID et les id d’auteurs
      – comment envoyer les nouveautés d’un serveur à un autre
      – comment envoyer le « stock »

      Cela dit, plus la réflexion avance, plus j’ai l’impression que le jeu de fonctionnalités dont on a besoin est couvert par #NNTP ; il ne manque, me semble-t-il, que la possibilité de modifier un contenu (je crois que NNTP ne propose que la possibilité d’annuler [cancel] un message).

      Sinon, avec cet export, une base seenthis n’est qu’un tas de fichiers au format email (donc, à la base, au format texte). Ca peut se synchroniser avec #BTSync, #rsync, d’autres trucs basés sur HTTP, etc : là c’est juste une question de choix. Il me paraîtrait quand même contre-productif d’inventer un énième truc over PHP si on peut employer des logiciels déjà existants et qui ont fait leurs preuves.

    • Pour les ids c’est juste une question de choix. Personnellement j’aime bien la notation de Github : people/emersion@seenthis.net ou message/uuid@seenthis.net
      Effectivement NNTP me semble très adapté !


      C’est juste parfait, il ne reste plus qu’à trouver des bibliothèques qui sont capables de la faire. J’avais vu Ratchet en PHP qui pouvait effectuer ce genre de choses. Je peux creuser plus l’idée au besoin.
      Sinon il y a git qui pourrait faire des choses pas mal. Mais rsync aussi effectivement.
      Seenthis n’est pas open-source ?

    • je me demandais s’il était possible de faire un export de tous mes posts sur seenthis, et je suis tombé sur ce @fil ...

      ... sans vraiment avoir de réponse. est-ce toujours un projet en cours, ou ai-je loupé quelque chose ?