Salut, d’abord, désolé pour le nom du topic à rallonge, mais je n’ai pas trouvé mieux.
Je me présente, je suis Sébastien, réalisateur de films d’animations.
Après avoir téléversé un film sur l’instance ouahpitube, je pensais qu’il serait aisé de le retrouver dans toutes les autres instances.
Hors, pour l’instant, quand je cherche mon film “la queste de digduguesclin”, il ne se trouve pas dans toutes les instances, dans certaines oui, mais pas toutes.
Est-ce normal ?
Car si le contenu varie d’une instance à l’autre alors ça n’est pas du tout pratique, et ça ne correspond pas non plus au principe à la fois centralisateur et décentralisé de peertube, non ?
oui c’est normal.
Le terme décentralisé n’est pas tout à fait exact.
Puisque la vidéo reste pour l’instant disponible sur un seul point unique, l’instance sur laquelle elle a été publié.
Et que la fédération se fait par les administrateur qui décident de suivre une instance.
Ça n’est pas propagé par inondation (comme le mode de propagation de Usenet).
La vidéo ne sera donc visible que sur les instance qui suivent ouahpitube (quelle est son url complète ?).
Ne pensez vous pas que par simplicité, il faudrait que la propagation des vidéos soient faites par propagation et ce de manière intrinsèque et non modifiable par les administrateurs des instances ? Ou laors une obligation de suivre les autres instances.
Sinon ça paraît très compliqué de dire à quelqu’un va sur peertube, ma vidéo y est et tape le nom de la vidéo tu la trouveras. Comme on fait généralement sur Youtube, ce qui en fait que c’est très pratique pour l’utilisateur. Bonne journée !
Les vidéos de tout un chacun se retrouveraient affichées publiquement en première page de ton instance, dont tu es responsable. Je doute que les administrateurs apprécient qu’on leur impose d’afficher une vidéo faisant la promotions de patates s’ils sont fans de carottes, par exemple.
Non je ne pense pas, en tout cas ça n’est pas le principe adopté par la fédération.
Une instance peertube peut être dédiée à un sujet précis et décider de ne diffuser que ce qui est publié sur l’instance. En revanche n’importe quelle autre instance peut décider de suivre une autre instance. Pour l’instant c’est ainsi que ça fonctionne.
Je pense qu’il est prévu de pouvoir suivre des chaînes ou des utilisateurs à l’avenir.
Donc toto sur l’instance titi, pourra suivre titi sur l’instance toto, et inversement.
Donc je suis allé ici : https://tube.ouahpiti.info/about/instance
En fait c’est la page que je vais voir, avant d’aller regarder le contenu local, pour savoir si je décide ou non de diffuser le contenu de l’instance sur la mienne. Comme le souligne @rigelk je n’ai pas forcément envie de tout diffuser. Même si pour tester le bidule je suis pas mal d’instances !
En occurrence, c’est vide. Hors c’est je pense un des points primordiaux.
Hum, ok, merci ; je ne suis pas sûr d’avoir tout compris.
Si je comprends bien, si une instance Y ne suis pas une autre instance Z, alors il est impossible de rechercher via le moteur de recherche de l’instance Y des vidéos hébergées sur l’instance Z ?
Du coup j’en ai discuté avec @Chocobozzz et à terme il y aura sûrement un moyen, depuis une instance A, d’effectuer une recherche de vidéos même non-affichées par l’instance A.
Un index central, ou une construction par chaque instance d’un index supplémentaire et nourri par “inondation” (comme le fait Mastodon), ce sont deux solution envisagées (et pas forcément mutuellement exclusives). L’écueil étant que chaque méthode a son désavantage (le premier est un SPOF, le second est difficile pour des instances tournant sur du matériel peu puissant).
Plutot que les instances se suivent entre elles, ne devrait on pas plutôt faire suivre des chaines entre elle ?
Je suis la Chaine A et C donc je peux voir toutes les vidéos de ces chaines. Est ce que ça marchera comme ça ?
Il ne pourrait pas y avoir un pool d’instances se déclarant comme index central ? Et se déclarant par inondation ? Comme ça, les instances tentent d’interroger un des serveurs du pool, pis si ça foire, passent à un autre. Ou alors en interrogent 2 à la fois (histoire de s’assurer de la cohérence des réponses + failover).
Ça c’est pour les abonnements d’utilisateurs typiquement. Pour les abonnements d’un serveur à un autre, c’est un peu fastidieux pour l’administrateur de sélectionner chaîne par chaîne celles à afficher…
Pour la cohérence c’est impossible, puisque même si deux instances suivent beaucoup d’instances, rien ne les empêche d’avoir une vue de la fédération en décalage. On ne peut pas garantir un état, même à un instant τ, alors on ne prouve pas de cohérence. À la limite on peut évaluer une proximité, mais quel intérêt ?¹
Le fait d’avoir un pool d’instances qui se proposent comme failover n’est pas une mauvaise idée en soi. Ce qui m’embête c’est le fait d’automatiser leur ajout. Rien n’empêche des petites instances sans les épaules assez larges de se proposer comme index central elles aussi. Et là… drame! C’est le DDoS. Elles peuvent très bien ne pas répondre et diluer l’utilité du pool d’index centraux, ou juste le ralentir par erreur.
Plutôt que de les déclarer automatiquement par inondation, les admins d’instances plus petites pourraient renseigner manuellement ces instances, comme on le fait déjà pour suivre des serveurs. C’est moins automatique, mais on le fait pour une ou deux (ou trois, soyons fous) instances et ça suffit.
¹: il y a un intérêt d’évaluer la proximité de deux bases de données, mais le critère est assez flou. Dire que tu as 95% des vidéos d’une instance référence n’est pas aussi intéressant que d’avoir des faits à ce sujet: comme quoi les 5% manquants sont dus à tel et tel blocage par exemple. Ça fait partie de la transparence mais il y a pas vraiment de métrique uniforme pour ça…
Alors si on parle de diffusion ou propagation par inondation, il faut s’inspirer de ce qui se fait pour Usenet (que ce soit en NNTP, mais aussi dans les autres modes de feed asynchrone).
En gros serveur A suit serveur B, serveur B suit serveur C. serveur C suit serveur A.
Quoi que sur Usenet, le maillage est sauf exception, réciproque. Si serveur A envoie à serveur B, en général serveur B envoie aussi à serveur A. Et au niveau local ce sont les groupes/hiérarchies suivies/distribuées.
L’unicité des contenu se fait par le message-id. Nous avons un équivalent avec l’id de la vidéo.
Pour les « groupes », ça pourrait être les mots clefs (hashtag).
Une vidéo est est publié (ou arrive) sur serveur C, serveur C indique à serveur A qu’il a tel contenu et demande à serveur A si il le veut, si serveur A répond oui alors c’est diffusé.
Serveur A contacte alors serveur B, et ainsi de suite.
Les instances avec un bon espace de stockage pourraient stocker la référence à la vidéo et la vidéo elle même.
Pour les modifications ou annulations (supressions) ce sont des messages spéciaux. Mais ça c’est déjà géré avec AP il me semble.
Tout ça est déjà supporté par AP, hormis la réplication de vidéo qui va d’ailleurs être implémentée (mais pas de manière si automatique, pour des raisons évidentes)
Ok, pas de check de la cohérence alors. Proposition :
je déclare mon serveur comme index global
cette déclaration est propagé par inondation
chaque fois que j’ai une nouvelle vidéo, je propage le nombre de vidéos que j’ai indexées
sur chaque instance, j’ai la liste des index globaux avec leur nombre de vidéo indexées
je coche un ou plusieurs index qui serviront pour ma recherche globale
je propage par inondation le temps de réponse de ces index. Ce temps de réponse sera affiché sur la liste des index, ce qui permet de ne pas choisir ceux qui ont du mal… où de privilégier automatiquement ceux qui ont les meilleurs temps/nb de vidéos
Pardonnez moi si ma question peut paraître naïve, je ne suis pas développeur.
La recherche ne pourrait-elle pas se faire par crawling ?
Par exemple le serveur A suit les instance B, C et D (voire même “référence” les serveurs B, C et D, ce qui pourrait être quelque chose d’indépendant de “suivre”). D, référence, E et F
Lorsque je recherche « ma super video » sur A, le moteur de recherche va chercher sur A. S’il trouve, c’est cool. S’il trouve pas il va envoyer une requête « ma super video » a B, C et D. Mettons qu’aucun des trois ne trouve, ils ne répondent rien. D envoie une requête sur E et F. Ils possèdent tous les deux la vidéo. Ils répondent en envoyant le lien à D. D envoie le lien arrivé le premier à A. L’utilisateur voit la video s’afficher dans les résultats de recherche. Lorsqu’il clique, il est redirigé vers l’instance E ou F. Ainsi A ne joue pas de vidéo sur lesquelles il n’as pas de contrôle.
Une petite amélioration qui, je crois, se rapproche de ce que vous appelez un « index nourris par inondation ». Les instances pourraient conserver un cache des requêtes les plus fréquentes. Par exemple, A mémoriserait que « ma super video » est sur E. Les petites instances pourrait ainsi simplement réduire la taille du cache. Vu qu’elle seraient plus longues à répondre elle serait aussi moins sollicitées.
Autre amélioration, mon serveur A pourrait choisir de référencer automatiquement les serveurs référencés par B, C et D (E et F dans l’exemple). L’hébergeur pourrait choisir sur combien de niveau il veut renouveler l’opération en fonction de la puissance de son serveur.
Non ce n’est pas du tout une bêtise, d’ailleurs de nombreux systèmes distribués fonctionnent comme ça. Par contre ce n’est pas adapté dans un cas où on veut une infinité de résultats, paginés et ordonnés (si je cherche le terme “chat”, je peux très bien vouloir aller à la page 56 des résultats). Ce serait donc quasi impossible, très compliqué et très peu efficace d’avoir un système de crawling.
On utilise les instances déclarées comme index global présent dans nos following (en qui on a normalement confiance), ce qui évite de cocher manuellement
Pour les temps de réponse pourquoi pas sous forme de score (si + de 500ms en temps de réponse on essaye avec une autre et on baisse le score de la première instance). Pas besoin de propager, il faut que ça reste une métrique locale car les temps de réponses sont dépendants de plein de choses (géographie, hébergeur/peering etc).
