• [^] # Re: Commentaires

    Posté par . En réponse au journal Générateur de site web statique. Évalué à 2.

    Perso, je suis fan de l'approche Indieweb qui fait de la fédération sur le web à base de microformats (classes CSS standardisées pour la sémantique) et de Webmention/Websub.

    Webmention est un standard d'endpoint dynamique à définir dans toutes les pages HTML de son blog:

     <link rel="webmention" href="ENDPOINT">
    

    Les endpoints communiquent des ping HTTP qui contiennent seulement deux paramètres, la page source et la page ciblée. Le principe est que quand tu publies un lien vers un autre site sur le tien, ton site doit aller pinger l'autre pour le prévenir qu'on a parlé de lui. Ensuite, le endpoint en face va télécharger et parser ta page pour comprendre la nature de l'interaction : a-t-on juste placé un lien vers une autre page? sommes-nous en train de répondre à un article/commentaire? etc..
    WebSub (précédemment PubSubHubHub) fait un peu la même chose mais en mode pub/sub.

    Les deux protocoles sont très faciles à implémenter et sont en quelque sorte les ancêtres de ActivityPub/ActivityStreams (le W3C Social WG qui a accouché du standard AP est né des efforts autour de Indieweb/Salmon/Linked Data).

    Donc si ton blog et mon blog avait un endpoint Webmention, je pourrais commenter un article sur ton blog en écrivant directement sur le mien:

    <article class="h-entry">
     <aside>En réponse à <a class="u-in-reply-to" href="https://ton.blog/ton-article">Un article très intéressant</a></aside>
     <h1 class="p-name">Mon titre de commentaire</h1>
     <div class="e-content">
     <p>Ceci est mon commentaire.</p>
     </div>
    </article>
    

    Les informations-clé à retenir ici sont les classes suivantes: h-entry (une entrée sur mon site), u-in-reply-to (l'entrée est en réponse au href joint), p-name (le nom de l'entrée est le contenu inline de la balise), e-content (le contenu de l'entrée est le contenu en block de la balise).

    Quand je publie l'article, mon endpoint doit contacter l'endpoint déclaré dans la page https://ton.blog/ton-article pour le prévenir que j'ai publié un contenu te concernant.

    Ensuite, il suffit d'intégrer un appel à l'API de ton endpoint dans ton script de build pour importer les nouveaux commentaires directement dans le dossier de contenu (ou dans le dossier data) de ton site statique.

    Il existe une installation clé-en-main de Webmention: webmention.io. Le code est libre même si ce n'est pas vraiment un projet communautaire pensé pour l'autohébergement.. mais il est très très simple de réimplémenter un tel endpoint. Et c'est un bon outil de transition pour comprendre comment intégrer de telles technologies dans sa pipeline.

    En conclusion, ce qu'on veut éviter c'est que les requêtes HTTP sur notre site servent de porte d'entrée directe sur le serveur web / la base de données. Recourir à un endpoint dynamique externe (dans un chroot/vm/container séparé) juste avant de compiler le site statique permet d'éviter certains problèmes de sécurité/performance au niveau du serveur web, tout en évitant l'approche JAMSTACK qui comme l'a rappelé devnewton fait porter sur le client toute la charge de construire la page.

    PS: Rien n'empêche, par dessus un tel setup, de rajouter de la modération ainsi qu'une boîte mail pour envoyer des commentaires sans passer par le web, mais mon commentaire était déjà bien assez long :)