Open azmeuk opened 9 months ago
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
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.
Merci !
L’implémentation avance lentement mais sûrement. Pour info j'ai ouvert un ticket de retour d'expériences à Peertube.
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:
Ce qu'il nous reste à faire :
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.
Super !
Merci pour ces nouvelles.
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 ?
Bonjour, je transfert à l'équipe dev et on vous tient au courant. Je regarderai pour ma part vendredi après midi.
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 ?
Bonjour petit up pour tester svp, merci! :)
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à.
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
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"
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 :
Bonjour à tous, je valide la migration vers l'implémentation d'ActivityPub. Pour information, voici le test effectué:
Je valide donc l'implementation Merci à vous
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
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:
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