POSSE-fr

From IndieWeb

Cette page a démarré sur POSSE

POSSE

POSSE est l'acronyme/abréviation de Publish (on your) Own Site, Syndicate Elsewhere. C'est un Modèle de Syndication où le flow s'engage à poster d'abord votre contenu sur votre propre domaine, puis à syndiquer des copies aux services tiers avec des permaliens raccourcis vers la version originale.

POSSE permet à vos amis de continuer à utiliser n'importe quel agrégateur silo (Facebook, Twitter, etc.) qu'ils utilisent pour lire vos trucs.

C'est un composant-clé de la raison et de la manière dont le mouvement "IndieWeb" diffère de simplement "chacun blogue sur son propre site", et c'est aussi différent de "tout le monde installe et fait simplement tourner StatusNet/Diaspora" etc.

POSSE est véritablement plus important que la fédération. POSSE parle de rester en contact maintenant avec ses amis actuels, plutôt que le potentiel de rester en contact avec ses amis dans le futur. En plus, si les approches fédérées prennent d'abord une approche POSSE, elles y gagneront probablement en adoption (tout le monde veut rester en contact avec ses amis), et de fait une approche plus rapide que le futur fédéré.

Sites

Les sites des participants à l'IndieWebCamp qui supportent une architecture POSSE. Si vous avez une implémentation, ajoutez-la, faites des copies d'écrans et/ou un screencast et/ou un billet de blog à propos, puis postez ici les détails/liens. L'ordre d'arrivée par date (les premiers tout en haut) :

  • Tantek.com en date du 2010-01-01[1] (2010-01-26 syndication Twitter démarrée[2] et mise à jour[3][4]). Tantek Çelik a implémenté POSSE avec Falcon sur tantek.com
    • tous les billets auto-hébergés (notes, articles, etc.) sont ouvertement syndiqués PuSH+Atom en temps-réel avec un hub PubsubHubbub vers Google Buzz, StatusNet, etc.
    • les notes (et titres des articles) sont des flocons copiés par le serveur du site personnel vers Twitter avec citation des liens/références sous forme de permaliens-raccourcis (voir Whistle pour les détails) ramenant à l'original. Les copies des notes vers Twitter sont aussi automatiquement recopiées à partir de là vers Facebook.
  • User:Sandeep.io Premier post POSSÉ le 05-Nov-2012. Je syndique d'abord vers Twitter en utilisant une solution très lo-fi d'ajouter les silos (Facebook, Twiiter, Google+) fournis pour partager des liens vers chaque post que je peux manuellement cliquer pour pré-remplir le contenu, éditer et poster. J'ai éviter l'intégration API parce que l'expérience intensive que j'ai eu à utiliser l'API de Facebook et de traiter toutes ses modifications hasardeuses. L'intégration a parfois des coûts élevés aussi je maintiens ça aussi simple que possible
  • werd.io en date du 2013-05-31 [9]. Ben Werdmuller a implémenté POSSE dans sa plate-forme idno via des extensions. Le nouveau contenu a un type objects Activity Streams associé ; les extensions POSSE écoutent les événements des posts associés avec ces object types et les syndiquent en conséquence.
    • Notes et articles sont syndiqués vers Twitter et Facebook
    • Les images sont syndiquées vers Facebook (Flickr à suivre)
    • Les endroits sont syndiqués vers Foursquare
    • Plus d'extensions sont très faciles à développer ; l'extension Foursquare m'a pris une heure à construire


  • ... Ajoutez un lien vers votre site POSSE et la date à laquelle vous avez démarré à syndiquer les copies de votre contenu vers des services tiers de partage ou de publication.

Autres approches partielles POSSE sur les sites :

  • User:Hupili.net implémente un POSSE partiel avec les paramètres suivants :
    • SNSAPI est un middleware léger pour unifier la structure de data et les interfaces de différents services de réseaux sociaux. Il offre la flexibilité de script aux utilisateurs développeurs pour manipuler les silos sociaux.
    • SNSRouter est une UI web construirte sur SNSAPI où l'on peut lire une timeline agrégée provenant de différents sites, pousser des messages en masse, et mettre à jour les statuts sur tous les canaux.
    • Une partie de mon usage quotidien est d'aller sur mon SNSRouter en fonctionnement, lire les messages et mettre à jour les statuts dessus. Le nouveau statut est écrit vers les flux RSS, http://hupili.net/feeds/all.xml , et d'autres silos. (Ce flux est bien sûr un mix de POSSE PESOS )
    • Comme cela a été dit dans l'une des descriptions du paragraphe au-dessus, ce modèle n'est pas vraiment POSSE. On ne peut pas (à peine) distinguer le statut original/syndiqué. Je prévois de placer une page avec un permalien sur mon site sur chaque mise à jour de statut et puis d'utiliser SNAPSI pour syndiquer vers d'autres silos.

Autres Approches

Une approche similaire mais inverse est PESOS où le contenu est d'abord posté sur des services tiers et puis copié/syndiqué à l'intérieur d'un site personnel.

Si des copies exactes du contenu sont postées à la fois sur un site personnel et des services tiers, il n'y a pas moyen de dire (raccourci pour comparer les dates de publication probablement non existantes) si un site utilise POSSE ou PESOS. Les sites peuvent supporter POSSE en incluant des permaliens-raccourcis dans les copies syndiquées qui lient/référencent en retour vers les originaux publiés.

Avantages

POSSE est considéré comme un modèle de syndication robuste et préférable pour les raisons suivantes :

  • Propriété. En postant d'abord sur votre propre site, vous créez un chaîne de propriété directe qui peut être tracée vers vous sans intervention des C.G.U. des services tiers (silos) (ce qui est une vulnérabilité de PESOS)).
  • Réduire la dépendance aux tiers. En postant directement sur votre propre site, vous n'êtes pas dépendants de services tiers pour faire ainsi — si vous pouvez accédez à votre site, vous pouvez publier votre contenu
  • Possédez les URLs canoniques vers votre contenu. Les URLs canoniques vers votre contenu sont sur votre domaine.
  • Les copies peuvent citer l'original. En postant du contenu d'abord sur votre propre site (et de ce fait un créant un permalien pour lui), les copies que vous postez sur les services tiers peuvent lier ou citer l'original sur votre site (voir formats de syndication et POSSEr des Notes vers Twitter)
  • Découverte de votre contenu original. La découverte de votre contenu original à partir des copies provenant des services tiers est permise par les permaliens-raccourcis postés sur lesdits services.
  • Meilleure recherche. Chercher du contenu public sur votre propre domaine (avec n'importe quel moteur web de recherche) fonctionne mieux que de dépendre exclusivement de Twitter pour recherche vos tweets.[10]. Et quand les copies relient vers vos posts originaux, les moteurs de recherche les voient en suivant ces liens retour et les classent mieux.
  • Le backfeed peut être utilisé pour ramener les réponses (rétro-syndication) provenant d'autres services
  • permet aussi de tirer profit des autres couches et fonctionnalités sociales et d'agrégation d'autres services tout en stockant la copie canonique de votre contenu sur votre propre site
  • ...

Destinations POSSE

Twitter

  • Accès API - poster de nouveaux tweets fonctionne biendu fait des tokens API permanents, et la valeur renvoyée contient une URL vers le post
  • Supporte les web actions endpoints très complets, aussi le post semi-manuel est facile à mettre en œuvre.

Voir POSSEr vers Twitter pour les détails sur la façon de POSSEr à la fois des notes et articles (posts de blog) vers Twitter.

Facebook

Article principal : POSSE to Facebook-fr
  • Accès API - Les nouveaux posts peuvent être créés à travers l'API en utilisant Publishing API.
  • Une action web endpoint (https://www.facebook.com/dialog/feed) est fournie par l'extension Feed social pour du post semi-manuel. Requiert une id app facebook, mais pas d'authentification. Elle accepte une URL callback, vers laquelle elle redirige avec un set ?post_id GET param, à partir duquel une URL peut être constuite. À faire : trouver les docs (ils ne semblent pas être sur le site FB)

Google Plus


Articles

TODO : Lier/écrire des posts articles de dev qui guideront les personnes pour syndiquer leurs contenus sur ces réseaux.

Bibliothèques logicielles

  • PHP
    • L'espace-nom POSSE dans php-helpers (pourrait migrer sur un package séparé) contient diverses fonctions de tronquage, préparation et syndication y compris HTML => convertisseur de syntaxe plein-texte µblog
  • …

Flux de Publication

Il existe au moins deux moyens d'implémenter un flow de contenus de posts POSSE :

Client vers Domaine Privé vers Services Tiers

  • L'utilisateur écrit un morceau de contenu en utilisant un client de publication
    • Optionnel : le client fournit l'IU pour sélectionner quels services tiers pousser s'il les connaît, avec des personnalisations optionnelles par service
  • Ayant fini le contenu, l'utilisateur publie le contenu sur son serveur (optionnellement avec des métadonnées des parties tiers et toute personnalisation imaginable)
    • Optionnel : le client peut générer un permalien connaissant l'état du serveur, et publier sur ce permalien.
  • Le serveur publie le contenu, génère un permalien et un sommaire (et/ou un contenu personnalisé s'adaptant aux services tiers) si nécessaire
  • Le serveur poste les copies avec des permaliens ves les services tiers

Avantages :

  • L'utilisateur ne doit interagir qu'avec un site sur l'internet, le sien
  • La syndication peut être produite complètement automatiquement par le serveur

Inconvénients :

  • ?

Client vers Domaine Privé et Services Tiers

  • L'utilisateur écrit un morceau de contenu en utilisant un client de publication
  • Une fois le contenu terminé, l'utilisateur le publie sur son serveur
  • Le client requête le serveur pour l'URL du contenu qu'il vient de pousser
  • Le client de publication présente à l'utilisateur une interface pour sélectionner :
    • sur quels services tiers publier
    • le contenu exact du contenu publié sur les services, pré-rempli avec un résumé basé sur le contenu produit
  • L'utilisateur sélectionne les services et soumet le formulaire
  • Le client de publication poste les résumés de contenus vers les services tiers

Avantages :

  • Plus de contrôle par l'utilisateur sur l'horaire et l'édition des copies de contenus vers les services tiers.

Inconvénients :

  • La syndication requiert une étape manuelle à chaque fois
  • Dépendant de la connectivité du client directement vers les services tiers (problématique dans des situations mobiles délicates, ou quand le client publie en utilisant un accès internet sur un domaine censuré).

CRUD

Tout ce qui est au-dessus, et à ce jour (2013-222), POSSE a uniquement été décrit comme syndiquant la Création de contenu sur votre site (publication) vers d'autres sites. Ce modèle a tout à fait réussi et peut peut-être suffire.

Néanmoins, cela vaut le coup d'explorer l'utilité potentielle d'un protocole CRUD pour POSSE.

Create

Créer est le POSSE par défaut. Vous créez du contenu sur votre site, vous POSSEz vos créations sur d'autres sites. Tout ce qui est décrit ci-dessus, et dans détails spécifiques aux silos sur les pages de silo.

Read

Read (lire) pris comme un verbe est intéressant quand appliqué à POSSE.

Au minimum, il est utile de stocker des liens vers les copies syndiquées de votre contenu pour fournir la possibilité future de lire à partir de copies de flux descendants de POSSE.

Voir :

Les usages véritables de Reading (Lire) en provenance de copies descendantes de flux POSSE :

En outre, conserver un lien rel-syndication vers la copie POSSÉe permet de l'effacer pour exécuter une action Update ou un Delete, comme décrit dans les sections suivantes.

Update

Si un service de flux descendant permet les mises à jour/éditions, alors quand vous éditez votre post, vous pourriez propager cette mise à jour vers la copie POSSE de ce flux descendant. (Quelles sont les destinations POSSE qui permettent ça ?)

Ce serait possible de POSSEr des mises à jour vers Twitter (ou tout autre silo qui ne permet pas de modifications sur les posts) en effaçant le tweet POSSE et en repostant.

Imaginez ne POSSEr que des mises à jour vers Twitter :

  • si personne n'y a répondu à cette heure (autrement vous briseriez une conversation/fil de discussion sur Twitter)
  • si vous modifications seraient affichées dans la copie tronquée sur Twitter (par ex si vous changements sont proches de l'horizon des 140 caractères (plus proche de 120), aucun intérêt à perdre la copie Twitter).
  • dans un laps de temps très court, peut-être 2 à 5 minutes, parce qu'autrement la mise à jour sera vue comme un doublon pour les personnes qui vous lisent sur Twitter.

Tous ces problèmes en considérant l'expérience que vous fournissez à vos amis lisant vos tweets sur Twitter, qui bien sûr devrait être la raison globale (design) pour laquelle vous devriez vous soucier de POSSEr vers Twitter en premier lieu.

Delete

Les effacements (Deletes) semblent tout à fait liés à POSSE, tout spécialement vers les services qui propagent eux-mêmes les effacements aux clients.

Par ex. on peut effacer une note sur Twitter à tout moment.

Similaire aux mises à jour, imaginez :

  • s'il existe déjà des réponses à une copie POSSE (ou activité comme like favoriss/retweets), imaginez conserver cela pour maintenir le fil de conversation (et autres favoris/retweets).

Néanmoins, si vous vous sentez vraiment à l'aise pour effacer le contenu à partir de votre site et les copies POSSEes (par ex sur Twitter), allez-y et faites ainsi.

Peut-être que c'est une opportunité pour l'IU pour l'effacement d'un post de vérifier s'il y a eu quelque activité (réponses, favoris, retweets) sur la copie POSSEe avant d'exécuter l'effacement. Une implémentation possible pourrait comprendre une IU informant l'utilisateur de cette activité (ou manque d'activité) et demander la reconfirmation de la requête d'effacement par service.

Historique

Voir aussi

En rapport

Retrieved from "https://indieweb.org/wiki/index.php?title=POSSE-fr&oldid=86228"