Implémentation d'ActivityPub

[azmeuk]

Bonjour à tous,
Nous travaillons sur l'implémentation d'ActivityPub dans le but de pouvoir fédérer des pods avec des pods, ou des pods avec des instances peertube. J'ouvre ce ticket pour pouvoir discuter des choix d'implémentation.

Pour rappel l'idée est d'implémenter un sous-ensemble d'ActivityPub dans le but de pouvoir partager les catalogues de vidéos entre les services. On ignorera les fonctionnalités autour des utilisateurs, des chaînes etc. Les fonctionnalités supportées seront:

• Les activités Follow (et les réponses Accept ou Reject), pour permettre la fédération.
• Les activités Create, Update et Delete sur les objets Video pour notifier / être notifié des ajouts/éditions/suppressions de vidéos.
• Le point d'accès standards : Webfinger, qui est utilisé par peertube comme point d'entrée de découverte.
• Un point d'accès Actor décrivant les métadonnées de l'instance, et notamment les points d'accès Inbox (pour notifier/être notifié des activités sur les vidéos, et fédérer les instances) et Outbox (pour récupérer/transmettre la liste exhaustive des vidéos d'une instance).

Pour info, peertube nécessite que les messages POST soient signés en suivant le draft de l'IETF Signing HTTP messages (ce n'est pas le seul logiciel à faire ça, mastodon aussi par exemple). Ce brouillon a été remplacé par la RFC9421 il y a quelques jours, et elle apporte beaucoup de modifications par rapport au brouillon. Peertube fera probablement évoluer son implémentation à l'avenir, donc il faudra surveiller ces évolutions pour garantir la compatibilité entre les services.

Pour que peertube puisse récupérer la liste des vidéos d'une instance pod, il faut un Actor d'instance, qui liste toutes les vidéos publiques dans sa outbox. Inversement, au moment où l'on fédérera une instance, il faudra aller consulter la outbox du compte d'instance peertube pour obtenir la liste de toutes les vidéos publiques.

Concernant les modèles de données, nous allons enregistrer en base les infos sur les instances fédérées (les instances suivies et suiveuses). Nous allons créer un modèle ExternalVideo qui référencera les métadonnées des vidéos externes.

Nous n'avons pas identifié pour le moment de bibliothèque pertinente à utiliser.

/cc @LoanR

[ptitloup]

Bonjour,
Pour ma part, tout me semble ok.
Ok pour faire du peertube-pod en premier mais nous auront besoin de communiquer rapidement sur du pod-pod !
je pense qu'il faut pouvoir afficher les vidéos externes dans le même pod avec l'iframe pour lire la vidéo
Ils ne faut pas oublier de les référencer dans le moteur de recherche
Merci

[azmeuk]

J'ai ouvert un sujet sur le forum de peertube à propos de la RFC9421. Visiblement une nouvelle spécification est à venir, qui couvrirait spécifiquement la signature des messages ActivityPub.

[ptitloup]

Merci !

[azmeuk]

L’implémentation avance lentement mais sûrement. Pour info j'ai ouvert un ticket de retour d'expériences à Peertube.

[azmeuk]

Bonjour à tous,
Une petite mise à jour de l'état du développement. Nous en sommes à un point où une instance Pod et une instance Peertube peuvent se fédérer correctement:

• la fédération fonctionne dans les deux sens
• la dé-fédération aussi
• la découverte des vidéos publiques fonctionne dans les deux sens
• les créations/éditions/suppressions de vidéos sont automatiquement transmises aux instances fédérées.

Ce qu'il nous reste à faire :

• Maintenant que Pod ↔ Peertube fonctionne, il nous faut tester la fédération Pod ↔ Pod
• Renforcer les tests unitaires
• Implémenter le modèle de données pour les vidéos distantes, l'indexation, et la partie front.

Nous avons commencé à écrire un README qui détaille quelques aspects techniques de l'implémentation. Nous ferons un squash de la branche avant de soumettre un PR.

[DeprezLaurent]

Super !

[ptitloup]

Merci pour ces nouvelles.

[LoanR]

Bonjour bonjour,

Petite question de conception concernant les vidéos provenant d'ActivityPub :
Afin de garder une logique métier, on passe par une forme d'héritage entre les Video déjà présentes sur Esup-Pod et les nouvelles vidéos ActivityPub, dites ExternalVideo.

Ces ExternalVideo n'héritent pas directement du modèle existant Video car une certaine part de son métier ne peut pas s'appliquer au nouveau modèle.

On a donc choisi d'avoir un parent commun, une classe de base abstraite dont les deux modèles héritent :

class Video(BaseVideo):
    ...
    class Meta:
        abstract = True

On y retrouvera les attributs en commun ainsi que la logique partagée entre les vidéos de l'instance Esup-Pod et les vidéos provenant d'ActivityPub.

Cela a évidemment des impacts sur les migrations. Les fichiers de migrations sont dans le gitignore, donc on ne sait pas exactement dans quel état sont les bases des différentes instances. Mais cela semble bien se comporter pour le moment.

En suivant la procédure : utiliser normalement Esup-Pod depuis la branche master => passer sur la branche implémentant ActivityPub => générer les nouvelles migrations => appliquer les migrations => faire un nouveau build depuis la branche implémentant ActivityPub
On n'identifie pas de problèmes et Django retrouve bien les différents modèles.

Est-ce que ça vous va ?

[ptitloup]

Bonjour, je transfert à l'équipe dev et on vous tient au courant. Je regarderai pour ma part vendredi après midi.

[ptitloup]

Pour moi, cela me semble ok sur le principe. Nous avons déjà utilisé cette solution pour les quiz. Pourriez-vous proposer une PR que je puisse tester la migration en basculant sur la branche ?

[ptitloup]

Bonjour petit up pour tester svp, merci! :)

[LoanR]

La PR est ici : #1170

Elle est rouge pour le moment, on passe par les signaux pour capter les créations / mises à jour de vidéos (le pre_save n'est peut-être pas idéal pour les nouvelles vidéos, mais jusqu'à maintenant, ça nous aidait à comparer avec l'état précédent). Il faut qu'on corrige ça, mais l'idée est là.

[ptitloup]

Merci bcp pour votre retour.
Est-ce que vous voulez qu'on teste une migration des maintenant en partant de develop et en allant sur votre branche ?
Ou on attends encore des correctifs ?
Merci

[LoanR]

Le correctif est en place !

Le warning de gitguardian concerne de la conf utilisée par peertube, il n'est donc pas vraiment pertinent.
Pour pouvoir tester les échanges entre Peertube et Pod, quelques points à noter :

• lors de la fédération Peertube "suit" Esup-Pod, les vidéo publiables de Esup-Pod vont être partagées vers Peertube. Elles sont visibles sous "Découvrir" ou "Tendances"

  • les nouvelles vidéos créées sur Esup-Pod seront aussi publiées, mais étrangement, elles ne se retrouvent ni sous "Découvrir" ou "Tendances" mais elles sont bien partagées : on les retrouve dans le channel correspondant à l'instance Esup-Pod. (les versions précédentes se comportaient mieux, le mainteneur doit être en train de faire pas mal de modifications)

• lors de la fédération Esup-Pod "suit" Peertube (Send the federation request), il faut aussi lancer Reindex the instance videos, c'est pour le moment la seule action qui permet de récupérer les vidéos d'instances fédérées.

• Il nous faut brancher la déserialization sur les autres événements

• Le mécanisme du player doit être adapté

Une fois ça fait, il nous faudra :

• valider la communication Pod-Pod
• adapter le style visuel
• adapter Elasticsearch

[ptitloup]

Bonjour à tous,
je valide la migration vers l'implémentation d'ActivityPub.
Pour information, voici le test effectué:

• copie bdd prod -> preprod : version 3.6.0
• bascule sur la branche de developpement activitypub : git checkout --track yaal-coop/activitypub
• installation des lib : pip3 install -r requirements.txt
• creation des fichiers de migrations : python manage.py makemigrations
• lancement de la migration : python manage.py migrate
• verification du bon fonctionnement et de la présence des videos : OK !

Je valide donc l'implementation
Merci à vous

[LoanR]

Petite question, je me demandais si des modifications de l'index elasticsearch étaient acceptées et faciles à déployer sur les différentes instance ? L'id des vidéos passe de long number à keyword et il y a aussi un nouvel attribut is_external qui est un boolean.
C'est dans la PR #1170