Forum général.général modèle movim pour owncloud ?

Posté par  . Licence CC By‑SA.
Étiquettes :
1
27
mar.
2015

Bonjour,

En ce moment je m'intéresse doucement à movim, ses pods, tout ça… En espérant un jour que l'OTR y fonctionne et que mes amis auront compris l'intérêt de la chose.

(Si j'ai bien compris, c'est du xmpp + pubsub, donc en gros chat + blog/RSS amélioré.)

Je me demandais si l'idée des pods inter-connectés n'étais pas réplicable à owncloud ?
C'est-à-dire : que chaque instance de owncloud auto-hébergée puisse contacter d'autres serveurs owncloud et ainsi créer une toile mondiale de partage de fichier.

Bien sûr, il y aurait des serveurs qu'on voudrait garder privés (type celui rien que pour toi). Mais je crois que ça c'est l'affaire de cozy cloud, non ?

Cependant pour des serveurs ouverts au public comme openmailbox.org et devosi.org, qui proposent un owncloud, on aurait tout à gagner à ce qu'un fichier sur le owncloud de openmailbox soit partageable en toute transparence sur le owncloud de devosi…

Peut-être que le protocole "webdav" permettrait ça ? Et dans ce cas on pourrait imaginer de mettre en lien des plateformes "cloud" différentes, type seafile & owncloud, seulement parce qu'elle partagerait le même protocole (à la manière de xmpp)

Vous me suivez ? Qu'en pensez-vous ?
Peut-être que c'est quelques chose trop compliqué à coder, mais je n'en ai aucune idée.

Question bonus : connaissez-vous un annuaire complet des pods movim avec la dernière version 0.8 ?

  • # Partage vs indexation, centralisation vs peer to peer

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    Le partage existe déjà avec ownCloud, que ce soit entre utilisateurs de la même instance, par des liens publics par exemple, ou via les serveurs eux-mêmes, à travers leur fédération.

    Quitte à jouer l'indépendance et le partage, autant aussi jouer la décentralisation jusqu'au bout et se passer de serveurs qui mutualisent leur stockages mais restent peu nombreux et/ou identifiables. Et hop, un arrive au peer-to-peer classique :)

    • [^] # Re: Partage vs indexation, centralisation vs peer to peer

      Posté par  . Évalué à 1.

      Ha, merci pour le lien, c'est bon à savoir !

      Sinon c'est vrai ce que tu dis, et je pense justement que les interconnexions dont on parle permettent une prolifération/essaimage des auto-hébergements. (Car elle ne limite pas le partage aux 2 potes qui ont bien voulu se créer un compte sur ton owncloud installé toi-même.)

      • [^] # Re: Partage vs indexation, centralisation vs peer to peer

        Posté par  . Évalué à 3.

        Un exemple d'application: plusieurs labo de recherche en France ont des owncloud. suivant les projets de chacun, il est possible d'utiliser un espace de travail d'un labo sur le owncloud d'un autre labo, de partager tous ça… et gérer les droits qui vont avec.

  • # Annuaire

    Posté par  (site web personnel) . Évalué à 1. Dernière modification le 27 mars 2015 à 13:18.

    Pour l'annuaire j'ai construit une petite API qui permet aux administrateurs d'enregistrer leurs serveur sur une liste.
    L'API est disponible à cette adresse https://api.movim.eu/ et est implémentée dans l'interface d’administration de Movim depuis la version 0.8 :)

    Les différents pods l'utilisent et génèrent une page à partir de ça https://pod.movim.eu/?q=pods.

    Je compte travailler dessus ces prochaines semaines pour rendre l'ensemble plus "user friendly".

    edhelas

    • [^] # Re: Annuaire

      Posté par  . Évalué à 1.

      Ha oui, merci !
      J'avais bien remarqué cette page de pods dans l'interface de connexion de l'ancienne version (par exemple sur http://famille.coutouly.fr/pods), mais je ne la trouvais plus dans la nouvelle version.
      Attention cependant, certain site recensés n'héberge pas ou plus movim !
      Du coup ce serait bien d'avoir un système de suivi des pods (type 'website deprecated'), avec peut-être un système de notation utilisateur pour donner une idée de la confiance à accorder à chacun.

      En tout cas merci pour ton travail, movim est une très bonne idée selon moi.
      Je n'ai toujours pas de compte facebook et dès que movim sera prêt et moi aussi, je compte faire venir un maximum d'amis sur ces pods !

      PS : petite question, y a-t-il un moyen de connaître les extensions xmpp 'XEP' supporté par notre serveur jabber. Concrètement je suis à riseup, et je ne sais pas si je peux blogguer sur movim.

      • [^] # Re: Annuaire

        Posté par  . Évalué à 1.

        quand je parle de l'ancienne version, je veux dire la 0.8 par rapport à la 0.9 qui semble utilisée sur movim.eu

  • # oups

    Posté par  . Évalué à 1.

    Ha bah en fait je me suis trompé à propos des blog de movim
    Ce flux atom sur movim.eu n'est pas le même que sur devosi.org.
    Je pensais qu'un blog movim créé sur n'importe quel pod était lisible sur n'importe quel autre pods…
    J'imagine que ça nécessite d'intégrer un type de lecteur RSS à movim, qui recense automatiquement les flux atoms des autres pods…

    • [^] # Re: oups

      Posté par  (site web personnel) . Évalué à 1.

      Oui mais non.

      Le flux est sensé être le même, sauf que celui-ci se synchronise quand l'utilisateur se connecte avec son propre compte.
      De plus celui-ci doit déclarer quel article venant de XMPP doit être rendu public sur le pod.

      Il n'y aura pas d'intégration de flux RSS à Movim car ce n'est pas le but de celui-ci. Movim n'est qu'un client XMPP "social" et orienté web.

      De plus Movim n'a pas vocation à recenser les flux des autres pods (comme le fait Diaspora par exemple) mais de puiser toutes ces informations du réseau XMPP, le seul point de synchronisation pour les données du réseau sera XMPP ;)

      • [^] # Re: oups

        Posté par  . Évalué à 1.

        Ok, tout ça se précise dans ma tête. Il faut donc que le serveur xmpp permette le pubsub pour que movim en tire parti au maximum.
        Merci pour tes réponse et ton temps !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.