Implémentation de l'option A du RFC (voir RFC-commentaires-activitypub-2026-07-04.md) : relais via bokante.o-k-i.net plutôt qu'un acteur ActivityPub natif.
Nouveaux champs : commentaire (origine, auteurNom/Handle/AvatarUrl/ProfilUrl, remoteId, remoteUrl) et parole (bokanteStatusId)
Client HTTP minimal vers l'API Mastodon (createStatus, getStatusContext)
Publication automatique d'un statut miroir à la publication d'une parole — dans afterCreate, pas beforeUpdate : avec draftAndPublish sur Strapi 5, publier crée une nouvelle ligne au lieu de mettre à jour l'existante, beforeUpdate ne se déclenche donc jamais sur une vraie action Publier
Cron d'import des réponses en commentaires (toutes les 20 min)
Cron de backfill du catalogue existant : une parole par exécution (la plus ancienne sans miroir en premier), une par heure par défaut, configurable via BOKANTE_BACKFILL_CRON
Tout est inactif tant que BOKANTE_ACCESS_TOKEN n'est pas configuré (no-op silencieux, même principe que Telegram/Revolt)
Validé en conditions réelles : publication réelle sur bokante.o-k-i.net confirmée, hook de publication confirmé déclenché au bon endroit après correction.
Implémentation de l'option A du RFC (voir RFC-commentaires-activitypub-2026-07-04.md) : relais via bokante.o-k-i.net plutôt qu'un acteur ActivityPub natif.
- Nouveaux champs : `commentaire` (origine, auteurNom/Handle/AvatarUrl/ProfilUrl, remoteId, remoteUrl) et `parole` (bokanteStatusId)
- Client HTTP minimal vers l'API Mastodon (createStatus, getStatusContext)
- Publication automatique d'un statut miroir à la publication d'une parole — dans `afterCreate`, pas `beforeUpdate` : avec draftAndPublish sur Strapi 5, publier crée une nouvelle ligne au lieu de mettre à jour l'existante, `beforeUpdate` ne se déclenche donc jamais sur une vraie action Publier
- Cron d'import des réponses en commentaires (toutes les 20 min)
- Cron de backfill du catalogue existant : une parole par exécution (la plus ancienne sans miroir en premier), une par heure par défaut, configurable via `BOKANTE_BACKFILL_CRON`
- Tout est inactif tant que `BOKANTE_ACCESS_TOKEN` n'est pas configuré (no-op silencieux, même principe que Telegram/Revolt)
Validé en conditions réelles : publication réelle sur bokante.o-k-i.net confirmée, hook de publication confirmé déclenché au bon endroit après correction.
Avec draftAndPublish sur Strapi 5, publier une entrée crée une
nouvelle ligne (document-service publishEntry -> createEntry) au lieu
de mettre à jour la ligne existante : beforeUpdate ne se déclenche
donc jamais sur une vraie action Publier, seulement sur l'édition
d'une entrée déjà publiée. Le miroir bokante est maintenant posté
dans afterCreate, sur la condition result.publishedAt, avec
synchronisation brouillon/publié pour rester idempotent à travers les
cycles dépublier/republier.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Implémentation de l'option A du RFC (voir RFC-commentaires-activitypub-2026-07-04.md) : relais via bokante.o-k-i.net plutôt qu'un acteur ActivityPub natif.
commentaire(origine, auteurNom/Handle/AvatarUrl/ProfilUrl, remoteId, remoteUrl) etparole(bokanteStatusId)afterCreate, pasbeforeUpdate: avec draftAndPublish sur Strapi 5, publier crée une nouvelle ligne au lieu de mettre à jour l'existante,beforeUpdatene se déclenche donc jamais sur une vraie action PublierBOKANTE_BACKFILL_CRONBOKANTE_ACCESS_TOKENn'est pas configuré (no-op silencieux, même principe que Telegram/Revolt)Validé en conditions réelles : publication réelle sur bokante.o-k-i.net confirmée, hook de publication confirmé déclenché au bon endroit après correction.