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! :)