cedricAbonnel/folio
1
0
Fork 0
Code Issues 15 Pull Requests Actions Packages Projects Releases Wiki Activity

Exploration : protocoles fédérés pour la syndication et la réciprocité entre blogs #38

New Issue
Open
opened 2026-05-13 22:09:55 +00:00 by cedricAbonnel · 0 comments
cedricAbonnel commented 2026-05-13 22:09:55 +00:00
Owner
Copy Link
Copy Source

Contexte et idée de départ

L'idée : permettre à un autre site (avec son propre flux RSS) de donner son accord explicite pour reprendre des articles de varlog — et inversement, que varlog puisse reprendre ceux d'un partenaire de confiance. La relation devrait être formalisée, pas juste un abonnement RSS silencieux.

Ce ticket explore les protocoles fédérés disponibles et identifie ceux qui s'intègrent naturellement à l'infrastructure existante.

Infrastructure existante (base de départ)

Élément État
/feed RSS 2.0 + Atom ✅ Opérationnel, paginé, filtré par catégories privées
FeedFetcher ✅ Pull + cache fichier par URL
Table rss_feeds ✅ Flux abonnés par utilisateur
Page /flux ✅ Agrège tous les flux des profils inscrits
Profils (user_profiles) ✅ display_name, profile_slug
Webmention / ActivityPub ❌ Absent

La mécanique de base (RSS en lecture) existe. Il manque la réciprocité et le consentement.

Protocoles candidats

Option A — Modèle RSS + partenariat explicite (plus proche de l'idée initiale)

Principe : étendre le système rss_feeds existant avec une couche de consentement bilatérale.

Flux :

  1. Le site partenaire envoie une demande de partenariat (URL de son flux RSS + URL de son site).
  2. L'admin varlog valide la demande → le partenaire est inscrit comme source approuvée.
  3. Le partenaire peut alors republier les articles de varlog avec attribution (son lecteur RSS sait qu'il a les droits).
  4. Varlog affiche ses articles dans /flux avec la mention du partenaire.

Implémentation côté varlog :

  • Table syndication_partners : id, site_url, feed_url, label, status (pending/approved/rejected), approved_at
  • Route POST /syndication/request : formulaire public pour demander un partenariat
  • Interface admin (onglet existant) pour approuver/rejeter
  • Dans le flux /feed, ajouter un namespace de droits explicite : 
    <atom:rights>CC BY 4.0 — republication avec attribution autorisée</atom:rights>
  • Endpoint GET /partners (JSON ou HTML) listant les partenaires approuvés (leur flux RSS devient "de confiance" dans FeedFetcher)

Complexité : faible — tout repose sur RSS + une table + un workflow admin. Pas de dépendance externe.

Limite : protocole maison, non standardisé. La vérification que le partenaire respecte les conditions reste manuelle.

Option B — Webmention (standard W3C, recommandé comme première brique fédérée)

Principe : quand un autre site publie un article qui cite ou reprend un article de varlog, il notifie varlog via une requête HTTP. Varlog peut alors afficher la citation, créer une rétro-notification, etc.

Spec : https://www.w3.org/TR/webmention/ (W3C Recommendation 2017)

Flux :

  1. Site B publie un article avec un lien vers varlog.a5l.fr/post/mon-article.
  2. Site B envoie POST /webmention avec source=https://siteB/article&target=https://varlog.a5l.fr/post/mon-article.
  3. Varlog valide que la source contient bien un lien vers la cible, stocke la mention.
  4. Varlog peut afficher les mentions reçues sous l'article (comme des commentaires entrants).

Implémentation côté varlog :

  • Balise dans <head> du layout : <link rel="webmention" href="/webmention">
  • Route POST /webmention : valide source/target, enregistre en BDD
  • Table webmentions : id, source_url, target_url, verified_at, status, author_name, author_url, summary
  • Vérification asynchrone (cron ou queue) : fetch la source, confirme que le lien existe
  • Affichage optionnel sous post_view.php (section "Mentionné par")

Complexité : moyenne — ~300 lignes PHP + une table + une vérification HTTP asynchrone.

Avantage : protocole standard, déjà supporté par des centaines de blogs IndieWeb. Si le site partenaire supporte Webmention, la réciprocité est automatique.

Option C — ActivityPub (intégration Fediverse, plus ambitieux)

Principe : publier les articles de varlog comme des objets ActivityPub, permettant à des comptes Mastodon/Misskey/etc. de suivre le blog directement depuis leur instance.

Spec : https://www.w3.org/TR/activitypub/ (W3C Recommendation 2018)

Ce que ça apporterait :

  • Un compte Mastodon peut suivre @varlog@varlog.a5l.fr
  • Chaque nouvel article apparaît dans son fil
  • Les boosts et réponses Mastodon peuvent remonter comme mentions

Implémentation côté varlog :

  • Endpoint GET /.well-known/webfinger (discovery)
  • Endpoint GET /actor (profil ActivityPub JSON-LD)
  • Endpoint GET /actor/outbox (articles comme Create > Note)
  • Endpoint POST /actor/inbox (réception des follows, likes, boosts)
  • Signatures HTTP (Digest + Signature headers) sur toutes les requêtes sortantes

Complexité : élevée — ActivityPub nécessite HTTP Signatures, JSON-LD, gestion des followers, clés RSA, etc. Représente plusieurs semaines de travail pour une implémentation robuste.

Alternative légère : ne publier que le profil webfinger + outbox en lecture seule, ce qui permet à Mastodon de "découvrir" le blog sans implémenter l'inbox.

Recommandation

Court terme  →  Option A (partenariat RSS explicite)
                Simple, maîtrisé, répond exactement à l'idée initiale.

Moyen terme  →  Option B (Webmention)
                Standard W3C, s'intègre au système de commentaires existant,
                ouvre la porte à l'écosystème IndieWeb.

Long terme   →  Option C (ActivityPub)
                À envisager si l'audience Fediverse devient un objectif.

Prochaines étapes suggérées

  • Valider quelle option prioriser
  • Option A : spécifier le schéma de syndication_partners et le workflow admin
  • Option B : ajouter <link rel="webmention"> dans layout.php + créer le endpoint (étape 0 indolore)
  • Option C : à décomposer en sous-tickets si retenu

Fichiers clés

  • src/FeedFetcher.php — fetcher RSS existant (réutilisable pour vérification Webmention)
  • public/feed.php — flux RSS sortant (à enrichir avec métadonnées de droits)
  • templates/layout.php — <head> à enrichir avec <link rel="webmention">
  • database/migration_005_rss_feeds.sql — modèle pour les nouvelles tables
  • public/index.php — routing central (nouvelles routes à ajouter)

Migré depuis varlog#53

## Contexte et idée de départ L'idée : permettre à un autre site (avec son propre flux RSS) de **donner son accord explicite pour reprendre des articles** de varlog — et inversement, que varlog puisse reprendre ceux d'un partenaire de confiance. La relation devrait être formalisée, pas juste un abonnement RSS silencieux. Ce ticket explore les protocoles fédérés disponibles et identifie ceux qui s'intègrent naturellement à l'infrastructure existante. --- ## Infrastructure existante (base de départ) | Élément | État | |---|---| | `/feed` RSS 2.0 + Atom | ✅ Opérationnel, paginé, filtré par catégories privées | | `FeedFetcher` | ✅ Pull + cache fichier par URL | | Table `rss_feeds` | ✅ Flux abonnés par utilisateur | | Page `/flux` | ✅ Agrège tous les flux des profils inscrits | | Profils (`user_profiles`) | ✅ display_name, profile_slug | | Webmention / ActivityPub | ❌ Absent | La mécanique de base (RSS en lecture) existe. Il manque la **réciprocité** et le **consentement**. --- ## Protocoles candidats ### Option A — Modèle RSS + partenariat explicite *(plus proche de l'idée initiale)* **Principe** : étendre le système `rss_feeds` existant avec une couche de consentement bilatérale. **Flux :** 1. Le site partenaire envoie une demande de partenariat (URL de son flux RSS + URL de son site). 2. L'admin varlog valide la demande → le partenaire est inscrit comme source approuvée. 3. Le partenaire peut alors republier les articles de varlog avec attribution (son lecteur RSS sait qu'il a les droits). 4. Varlog affiche ses articles dans `/flux` avec la mention du partenaire. **Implémentation côté varlog :** - Table `syndication_partners` : `id, site_url, feed_url, label, status (pending/approved/rejected), approved_at` - Route `POST /syndication/request` : formulaire public pour demander un partenariat - Interface admin (onglet existant) pour approuver/rejeter - Dans le flux `/feed`, ajouter un namespace de droits explicite : ```xml <atom:rights>CC BY 4.0 — republication avec attribution autorisée</atom:rights> ``` - Endpoint `GET /partners` (JSON ou HTML) listant les partenaires approuvés (leur flux RSS devient "de confiance" dans FeedFetcher) **Complexité** : faible — tout repose sur RSS + une table + un workflow admin. Pas de dépendance externe. **Limite** : protocole maison, non standardisé. La vérification que le partenaire respecte les conditions reste manuelle. --- ### Option B — Webmention *(standard W3C, recommandé comme première brique fédérée)* **Principe** : quand un autre site publie un article qui **cite ou reprend** un article de varlog, il notifie varlog via une requête HTTP. Varlog peut alors afficher la citation, créer une rétro-notification, etc. **Spec** : https://www.w3.org/TR/webmention/ (W3C Recommendation 2017) **Flux :** 1. Site B publie un article avec un lien vers `varlog.a5l.fr/post/mon-article`. 2. Site B envoie `POST /webmention` avec `source=https://siteB/article&target=https://varlog.a5l.fr/post/mon-article`. 3. Varlog valide que la source contient bien un lien vers la cible, stocke la mention. 4. Varlog peut afficher les mentions reçues sous l'article (comme des commentaires entrants). **Implémentation côté varlog :** - Balise dans `<head>` du layout : `<link rel="webmention" href="/webmention">` - Route `POST /webmention` : valide source/target, enregistre en BDD - Table `webmentions` : `id, source_url, target_url, verified_at, status, author_name, author_url, summary` - Vérification asynchrone (cron ou queue) : fetch la source, confirme que le lien existe - Affichage optionnel sous `post_view.php` (section "Mentionné par") **Complexité** : moyenne — ~300 lignes PHP + une table + une vérification HTTP asynchrone. **Avantage** : protocole standard, déjà supporté par des centaines de blogs IndieWeb. Si le site partenaire supporte Webmention, la réciprocité est automatique. --- ### Option C — ActivityPub *(intégration Fediverse, plus ambitieux)* **Principe** : publier les articles de varlog comme des objets ActivityPub, permettant à des comptes Mastodon/Misskey/etc. de **suivre le blog directement** depuis leur instance. **Spec** : https://www.w3.org/TR/activitypub/ (W3C Recommendation 2018) **Ce que ça apporterait :** - Un compte Mastodon peut suivre `@varlog@varlog.a5l.fr` - Chaque nouvel article apparaît dans son fil - Les boosts et réponses Mastodon peuvent remonter comme mentions **Implémentation côté varlog :** - Endpoint `GET /.well-known/webfinger` (discovery) - Endpoint `GET /actor` (profil ActivityPub JSON-LD) - Endpoint `GET /actor/outbox` (articles comme `Create > Note`) - Endpoint `POST /actor/inbox` (réception des follows, likes, boosts) - Signatures HTTP (Digest + Signature headers) sur toutes les requêtes sortantes **Complexité** : élevée — ActivityPub nécessite HTTP Signatures, JSON-LD, gestion des followers, clés RSA, etc. Représente plusieurs semaines de travail pour une implémentation robuste. **Alternative légère** : ne publier que le **profil webfinger + outbox en lecture seule**, ce qui permet à Mastodon de "découvrir" le blog sans implémenter l'inbox. --- ## Recommandation ``` Court terme → Option A (partenariat RSS explicite) Simple, maîtrisé, répond exactement à l'idée initiale. Moyen terme → Option B (Webmention) Standard W3C, s'intègre au système de commentaires existant, ouvre la porte à l'écosystème IndieWeb. Long terme → Option C (ActivityPub) À envisager si l'audience Fediverse devient un objectif. ``` ## Prochaines étapes suggérées - [ ] Valider quelle option prioriser - [ ] Option A : spécifier le schéma de `syndication_partners` et le workflow admin - [ ] Option B : ajouter `<link rel="webmention">` dans `layout.php` + créer le endpoint (étape 0 indolore) - [ ] Option C : à décomposer en sous-tickets si retenu ## Fichiers clés - `src/FeedFetcher.php` — fetcher RSS existant (réutilisable pour vérification Webmention) - `public/feed.php` — flux RSS sortant (à enrichir avec métadonnées de droits) - `templates/layout.php` — `<head>` à enrichir avec `<link rel="webmention">` - `database/migration_005_rss_feeds.sql` — modèle pour les nouvelles tables - `public/index.php` — routing central (nouvelles routes à ajouter) --- *Migré depuis [varlog#53](https://git.abonnel.fr/cedricAbonnel/varlog/issues/53)*
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
cedricAbonnel (Cédric Abonnel)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: cedricAbonnel/folio#38
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?