larlet-fr-david-cache/cache/5fc43f9c6c7f90b66e4ae248630f8f86/index.md

title: POSSE - IndieWebCamp
url: https://indiewebcamp.com/POSSE
hash_url: 5fc43f9c6c7f90b66e4ae248630f8f86

<p><span class="p-summary"><b><dfn>POSSE</dfn></b> is an abbreviation for <b>Publish (on your) Own Site, Syndicate Elsewhere</b>, a content publishing model that starts with posting content on your own domain first, then syndicating out copies to 3rd party services with <a href="/permashortlinks" title="permashortlinks" class="mw-redirect">permashortlinks</a> back to the original on your site.</span>
</p>

<h2> <span class="mw-headline" id="Why"> Why </span></h2>
<p>POSSE lets your friends keep using whatever they use to read your stuff (e.g. <a href="/silo" title="silo">silo</a> aggregators like <a href="/Facebook" title="Facebook">Facebook</a>, <a href="/Tumblr" title="Tumblr">Tumblr</a>, <a href="/Twitter" title="Twitter">Twitter</a>, etc.).
</p><p>It's a key part of why and how the IndieWeb movement is <a href="/different" title="different">different</a> from just "everyone blog on their own site", and also different from "everyone just install and run StatusNet/Diaspora" etc. <a href="/monoculture" title="monoculture">monoculture</a> solutions.
</p><p>POSSE is about staying in touch with current friends now, rather than the potential of staying in touch with friends in the future.
</p><p>As such, POSSE is more important than <a href="/federation" title="federation">federation</a>. In addition, if federated approaches take a POSSE approach first, they will likely get better adoption (everyone wants to stay in touch with their friends), and thereby more rapidly approach that federated future.
</p>
<h3> <span class="mw-headline" id="Advantages"> Advantages </span></h3>
<p>POSSE is considered a robust and preferable syndication model for the following reasons:
</p>
<ul><li> <b>Ownership.</b> By posting <i>first</i> on your own site, you create a direct ownership chain that can be traced back to you without any intervening 3rd party services (silos) TOS's getting in the way (which is a vulnerability of <a href="/PESOS" title="PESOS">PESOS</a>).
</li><li> <b>Reduce 3rd party dependence.</b> By posting directly to your own site, you're not dependent on 3rd Party services to do so -- if you can access your site, you can publish your content
</li><li> <b>Own canonical URLs to your content.</b> Canonical URLs to your content are on your domain.
</li><li> <b>Copies can cite the original.</b> By posting content first to your own site (and thus creating a permalink for it), copies that you post on 3rd Party services can link or cite the original on your site (see <a href="/syndication_formats" title="syndication formats">syndication_formats</a> and <a href="/Twitter#POSSE_Notes_to_Twitter" title="Twitter">POSSE Notes to Twitter</a>)
</li><li> <b>Discovery of your original content.</b> <a href="/discovery" title="discovery">discovery</a> of your original content from the copies on 3rd party services is enabled by the permashortlinks to your originals posted on said services
</li><li> <b>Better search.</b> Searching public content on your own domain (with any web search engine of your choice) works better than depending on Twitter exclusively to search your tweets.<a href="http://tantek.com/2011/009/t3/value-searching-finding-past-tweets-self-hosting" class="external autonumber">[1]</a>. And when the copies link to your original posts, search engines figure that out by following those links back to the original and ranking it higher.
</li><li> <a href="/backfeed" title="backfeed">backfeed</a> can be used to pull in (reverse syndicate) responses from other services
</li><li> allows taking advantage of other services' social layers and aggregation features while storing the canonical copy of your content on your own site
</li><li> ...
</li></ul>
<h2> <span class="mw-headline" id="How_To_Implement"> How To Implement </span></h2>
<h3> <span class="mw-headline" id="In_General"> In General </span></h3>
<p>In general, when your content posting software posts something, it should also post a copy to the <a href="/silo" title="silo">silo</a> destinations of your choice, with a <a href="/permashortlink" title="permashortlink">permashortlink</a> (or <a href="/permashortcitation" title="permashortcitation">permashortcitation</a>) back to your original.
</p><p>The details of how to do so vary per destination. See the silo-specific sections below.
</p><p>Once you have posted the copy to the silo, you should:
</p>
<ul><li> link to the copy from the original in a <b><a href="/posts-elsewhere" title="posts-elsewhere">posts-elsewhere</a></b> section on your post.
</li></ul>
<h3> <span class="mw-headline" id="Twitter"> Twitter </span></h3>

<p><a href="/Twitter" title="Twitter">Twitter</a> is perhaps the most popular POSSE destination and a good place to start.
</p><p>If you can start posting notes (tweets) to your own site and POSSEing to Twitter, <em>instead of</em> posting directly to Twitter, you have taken a big step towards owning your data.
</p><p>Details:
</p>
<ul><li> API Access - <a href="https://dev.twitter.com/docs/api/1.1/post/statuses/update" class="external text">posting new tweets</a> works nicely due to permanent API tokens, and the return value contains a URL to the posted
</li><li> Supports very complete web action endpoints, so semi-manual posting is easy to implement
</li></ul>
<p>See <a href="/Twitter#POSSE_to_Twitter" title="Twitter">POSSE to Twitter</a> for details on how to POSSE both notes and articles (blog posts) to Twitter.
</p>
<h3> <span class="mw-headline" id="Facebook"> Facebook </span></h3>

<ul><li> API Access - New posts can be created through the API using the <a href="https://developers.facebook.com/docs/reference/api/publishing/" class="external text">Publishing API</a>
</li><li> A web action endpoint (<code><a href="https://www.facebook.com/dialog/feed" class="external free">https://www.facebook.com/dialog/feed</a></code>) is supplied by the Feed social plugin for semi-manual posting. Requires a facebook app id, but no authentication. It accepts a callback URL, to which it redirects with ?post_id GET param set, from which a URL can be constructed.
</li></ul>
<h3> <span class="mw-headline" id="Google_Plus"> Google Plus </span></h3>

<ul><li> No write API (yet)
</li><li> There are several endpoints which can be used as web action dialogs, but none of them support callbacks, so it’s trick to get the URL of the posted copy.

</li></ul>
<h3> <span class="mw-headline" id="Medium"> Medium </span></h3>

<ul><li> how does iamshane.com do it? (all his articles are POSSEd to Medium)
</li></ul>
<h3> <span class="mw-headline" id="WordPress"> WordPress </span></h3>

<ul><li> how does iamshane.com do it? (all his articles are POSSEd to WordPress)
</li></ul>
<h3> <span class="mw-headline" id="Plain_Text_Notes"> Plain Text Notes </span></h3>
<p>Some destinations (e.g. <a href="/wiki/index.php?title=SMS&amp;action=edit&amp;redlink=1" class="new" title="SMS (page does not exist)">SMS</a> or <a href="/push_notification" title="push notification">push notifications</a>) may require a pure plain text representation.
</p>

<h3> <span class="mw-headline" id="Software"> Software </span></h3>
<p>Software and libraries to implement POSSE:
</p>
<ul><li> PHP
<ul><li> The POSSE namespace in <a href="https://github.com/barnabywalters/php-helpers" class="external text">php-helpers</a> (might be moved to a separate package) contains various truncation, preparation and syndication functions including HTML =&gt; plaintext µblog syntax converter
</li></ul>
</li><li> …
</li></ul>
<h3> <span class="mw-headline" id="Services"> Services </span></h3>

<p><br/>
</p>
<h3> <span class="mw-headline" id="Publishing_Flows"> Publishing Flows </span></h3>
<p>There's at least two ways to implement a POSSE content posting flow:
</p>
<h4> <span class="mw-headline" id="Client_to_site_to_silo"> Client to site to silo </span></h4>
<ul><li> The user writes a piece of content using a publishing client
<ul><li> Optional: client provides UI for selecting which 3rd party services to push to if it knows about them, with optional customizations for per service
</li></ul>
</li><li> Having finished the content, the user publishes content to their server (optionally: with metadata of which 3rd party services and any customizations thereof)
<ul><li> Optional: client can generate a permalink knowing the state of the server, and publish to that permalink
</li></ul>
</li><li> The server publishes the content, generates a permalink and summary (and/or customized content suited to 3rd party services) if necessary
</li><li> The server posts copies with permalinks to 3rd party services
</li></ul>
<p>Advantages:
</p>
<ul><li> User only has to interact with one site over the internet, their own
</li><li> Syndication can be done fully automatically by the server
</li></ul>
<p>Disadvantages:
</p>

<h4> <span class="mw-headline" id="Client_to_site_and_silo"> Client to site and silo </span></h4>
<ul><li> The user writes a piece of content using a publishing client
</li><li> Having finished the content, the user publishes it to their server
</li><li> The client queries the server for the URL of the content it just pushed
</li><li> The publishing client presents the user with an interface for selecting:
<ul><li> Which 3rd party services to publish to
</li><li> The exact content published to the services, pre-filled with a summary based on the produced content
</li></ul>
</li><li> The user selects the services and submits the form
</li><li> The publishing client posts the content summaries out to the 3rd party services
</li></ul>
<p>Advantages:
</p>
<ul><li> More user control over timing and editing of copies of content to 3rd party services
</li></ul>
<p>Disadvantages:
</p>
<ul><li> Syndication requires a manual step each time
</li><li> Dependent on client connectivity directly to 3rd party services (problematic in flakey mobile situations, or when client is publishing using domain-censored internet access).
</li></ul>
<h2> <span class="mw-headline" id="IndieWeb_Examples"> IndieWeb Examples </span></h2>
<p>The following IndieWebCamp participants' <span id="IndieWeb_examples">sites</span> support a POSSE architecture. If you have an implementation, add it, make screenshots or a screencast or blog about it and post the details/link here. In date order (earliest first) :
</p>
<h3> <span class="mw-headline" id="Tantek"> Tantek </span></h3>
<p><b><a href="http://tantek.com" class="external text">Tantek.com</a></b> as of 2010-01-01<a href="http://tantek.com/2010/001/t1/declaring-independence-building-it" class="external autonumber">[2]</a> (2010-01-26 Twitter syndication started<a href="http://twitter.com/t/status/8228455558" class="external autonumber">[3]</a> and caught up<a href="http://tantek.com/2010/026/t2/tweeting-from-tantek-com" class="external autonumber">[4]</a><a href="http://twitter.com/t/status/8228820728" class="external autonumber">[5]</a>). <a href="/User:Tantek.com" title="User:Tantek.com">Tantek Çelik</a> implemented POSSE in <a href="http://tantek.com/w/Falcon" class="external text">Falcon</a> on <a href="http://tantek.com" class="external text">tantek.com</a>.
</p>
<ul><li> all self-hosted posts are openly with <a href="/PuSH" title="PuSH" class="mw-redirect">PuSH</a> v0.4 + <a href="/h-feed" title="h-feed">h-feed</a> and Atom real-time syndicated with a PubsubHubbub hub to <a href="/StatusNet" title="StatusNet" class="mw-redirect">StatusNet</a>, other subscribers etc. (also to <a href="/Google_Buzz" title="Google Buzz">Google Buzz</a> til it shutdown)
</li><li> <a href="/note" title="note">note</a> (and <a href="/article" title="article">article</a> titles), <a href="/reply" title="reply">reply</a>, <a href="/RSVP" title="RSVP" class="mw-redirect">RSVP</a> posts are <a href="/snowflake" title="snowflake">snowflake</a> copied by the personal site server to Twitter with permashortlink citation links/references (see <a href="http://tantek.com/w/Whistle" class="external text">Whistle</a> for details) back to the original. Copies of notes to Twitter are also automatically recopied from there to Facebook.
<ul><li> <a href="/RSVP" title="RSVP" class="mw-redirect">RSVPs</a> to Facebook events are "copied" (more like propagated) to Facebook using <a href="/Bridgy" title="Bridgy">Bridgy</a> publish
</li></ul>
</li><li> <a href="/like" title="like">likes</a> of tweets are "copied" (more like propagated) to Twitter using <a href="/Bridgy" title="Bridgy">Bridgy</a> publish
</li></ul>
<h3> <span class="mw-headline" id="Barnaby_Walters"> Barnaby Walters </span></h3>
<p><b><a href="http://Waterpigs.co.uk" class="external text">Waterpigs.co.uk</a></b> as of 2012-03-12. <a href="/User:Waterpigs.co.uk" title="User:Waterpigs.co.uk">Barnaby Walters</a> implemented POSSE over at <a href="http://waterpigs.co.uk" class="external text">waterpigs.co.uk</a>
</p>
<ul><li> as of 2012-09-25 all collections (notes, articles, activity) are <a href="/PuSH" title="PuSH" class="mw-redirect">PuSH</a>-subscribable <a href="/feeds" title="feeds" class="mw-redirect">feeds</a>.
</li><li> Using the Client to Server to 3rd Parties flow --<a href="/User:Waterpigs.co.uk" title="User:Waterpigs.co.uk">Waterpigs.co.uk</a> 06:08, 25 September 2012 (PDT)
</li><li> Syndicating to Twitter + Facebook
</li><li> As of 2014-06-19 <a href="/Taproot" title="Taproot">Taproot</a> can now optionally post additional POSSE tweets when updating a note or article — example of <a href="http://waterpigs.co.uk/notes/4WfKUc/" class="external text">updated note</a> and <a href="https://twitter.com/BarnabyWalters/status/479721886503288832" class="external text">POSSE tweet for the update</a>. Note that <a href="/Bridgy" title="Bridgy">Bridgy</a> successfully backfeeds silo interactions from the update tweet as well as the original POSSE tweet
</li></ul>
<h3> <span class="mw-headline" id="Brennan_Novak"> Brennan Novak </span></h3>
<p><b><a href="https://brennannovak.com" class="external text">brennannovak.com</a></b> as of 2012-07-01<a href="https://brennannovak.com/notes/10" class="external autonumber">[6]</a><a href="https://twitter.com/brennannovak/status/212243963011280897" class="external autonumber">[7]</a>. <a href="/User:Brennannovak.com" title="User:Brennannovak.com">Brennan Novak</a> implemented POSSE on his site <a href="https://brennannovak.com" class="external text">brennannovak.com</a> with copies posted to Twitter and Facebook
</p>
<h3> <span class="mw-headline" id="Aaron_Parecki"> Aaron Parecki </span></h3>
<p><b><a href="http://aaronparecki.com" class="external text">aaronparecki.com</a></b> as of 2012-08-19<a href="http://aaronparecki.com/2012/232/note/1" class="external autonumber">[8]</a><a href="https://twitter.com/aaronpk/status/237344101928951808" class="external autonumber">[9]</a>. <a href="/User:Aaronparecki.com" title="User:Aaronparecki.com">Aaron Parecki</a> implemented POSSE on his site <a href="http://aaronparecki.com" class="external text">aaronparecki.com</a> with copies posted to Twitter containing permashortlinks back to originals on his own site.
</p>

<h3> <span class="mw-headline" id="Sandeep_Shetty"> Sandeep Shetty </span></h3>
<p><b><a href="/User:Sandeep.io" title="User:Sandeep.io">User:Sandeep.io</a></b> First post POSSE'd on 2012-11-05. I primarily syndicate to Twitter using a very lo-fi solution of adding silo (Facebook, Twiiter, Google+) provided share links to each post that I can manually click to prefill content, edit and post. I've avoided API integration because of the extensive experience I've had using Facebook API and dealing with it's random changes. "Integration" has high costs sometimes so I keep it as simple as possible.
</p>
<h3> <span class="mw-headline" id="Ben_Werdmuller"> Ben Werdmuller </span></h3>
<p><b><a href="http://werd.io" class="external text">werd.io</a></b> as of 2013-05-31 <a href="http://werd.io/view/51a7fb55bed7de2f06761712" class="external autonumber">[10]</a>. <a href="/User:Benwerd.com" title="User:Benwerd.com">Ben Werdmuller</a> implemented POSSE in his <a href="http://idno.co" class="external text">idno</a> platform via plugins. New content has an associated Activity Streams object type; POSSE plugins listen for post events associated with those object types and syndicate appropriately.
</p>
<ul><li> Notes and articles are syndicated to Twitter and Facebook
</li><li> Images are syndicated to Facebook, Flickr and Twitter
</li><li> Places are syndicated to Foursquare
</li><li> More plugins are very easily possible; the Foursquare plugin took about an hour to build
</li></ul>
<h3> <span class="mw-headline" id="Shane_Becker"> Shane Becker </span></h3>
<p>iamshane.com - need to copy example from <a href="/rel-syndication" title="rel-syndication">rel-syndication</a> page
</p>
<h3> <span class="mw-headline" id="Glenn_Jones"> Glenn Jones </span></h3>
<p><b><a href="http://glennjones.net" class="external text">glennjones.net</a></b> as of 2014-01-14 <a href="/User:Glennjones.net" title="User:Glennjones.net">Glenn Jones</a> The blog implemented POSSE using a new version of <a href="http://transmat.io" class="external text">transmat.io</a> system. New content added to transmat is associated with objects types. A POSSE twitter plugins listens for post events syndicating content. At moment only notes are syndicated.
</p>
<h3> <span class="mw-headline" id="Jeremy_Keith"> Jeremy Keith </span></h3>
<p><b><a href="http://adactio.com" class="external text">adactio.com</a></b> as of 2014-05-27 <a href="/User:Adactio.com" title="User:Adactio.com">Jeremy Keith</a> has implemented POSSE using his own custom CMS.
</p>

<h3> <span class="mw-headline" id="Shane_Hudson"> Shane Hudson </span></h3>
<p><b><a href="https://shanehudson.net" class="external text">shanehudson.net</a></b> as of 2014-09-19 <a href="/User:ShaneHudson.net" title="User:ShaneHudson.net">Shane Hudson</a> has implemented POSSE to Twitter for Craft CMS.
</p>
<ul><li> Previously working on Wordpress but he was not keen on the UX.
</li><li> Has reply contexts working but has to manually copy the ID.
</li><li> Not yet POSSEing photos but plans to.
</li><li> Currently he has to manually copy the tweet from the main text box to a 140 character limit tweet text box. He plans to make that automatic.
</li></ul>
<h3> <span class="mw-headline" id="..._add_more_here_..."> ... add more here ... </span></h3>
<p>... Add a link to your POSSE–enabled site and the date you started syndicating copies of your content out to 3rd party social sharing/publishing services.
</p>
<h3> <span class="mw-headline" id="Partial_POSSE_sites"> Partial POSSE sites </span></h3>
<p>Sites which only POSSE some of their content, and still post directly to the same silo they POSSE to.
</p><p>Other partial POSSE sites:
</p>
<ul><li> <b><a href="/User:Hupili.net" title="User:Hupili.net">User:Hupili.net</a></b> implements a partial POSSE with the following setups:
<ul><li> <a href="/SNSAPI" title="SNSAPI">SNSAPI</a> is a lightweight middleware to unify the data structure and interfaces of different social networking services. It gives the scripting flexibility for developer users to manipulate social silos.
</li><li> <a href="/SNSRouter" title="SNSRouter">SNSRouter</a> is a web UI built upon SNSAPI where one can read an aggregated timeline from different sites, mass forward messages, and update statuses on all channels.
</li><li> Part of my daily usage is to go to my running SNSRouter, read messages and update statuses on it. The new status is written to the RSS feeds, <a href="http://hupili.net/feeds/all.xml" class="external free">http://hupili.net/feeds/all.xml</a> , and other silos. ( This feed is indeed a mix of <strong class="selflink">POSSE</strong> <a href="/PESOS" title="PESOS">PESOS</a> )
</li><li> As is said in one of the description paragraph above, this model is not truly POSSE. One can not (hardly) distinguish original/ syndicated status. I'm planning to put a page with permlink on my site upon each status update and then use SNSAPI to syndicate to other silos.
</li></ul>
</li></ul>
<h2> <span class="mw-headline" id="Other_Approaches"> Other Approaches </span></h2>
<h3> <span class="mw-headline" id="PESOS"> PESOS </span></h3>
<p>A similar but opposite approach is <a href="/PESOS" title="PESOS">PESOS</a> where content is posted first to 3rd party services and then copied/syndicated into a personal site.
</p><p>If exact copies of content are posted on both a personal site and 3rd party services, there's no way to tell (short of comparing possibly non-existent sub-second accurate published dates) whether a site is using POSSE or PESOS. Sites can provably support POSSE by including perma(short)links in syndicated copies that link/reference back to published originals.
</p>
<h3> <span class="mw-headline" id="PESETAS"> PESETAS </span></h3>
<p><a href="/PESETAS" title="PESETAS">PESETAS</a> is like PESOS but copying/syndicating everything to a particular silo (without any involvement of a personal site).
</p><p>For example, most silos support cross-posting to <a href="/Twitter" title="Twitter">Twitter</a>, thus you could connect everything to your Twitter account and always (auto-)cross-post there to keep a copy.
</p><p>E.g. <a href="/Tumblr" title="Tumblr">Tumblr</a> has a UI for cross-posting to <a href="/Twitter" title="Twitter">Twitter</a>. See <a href="http://webapps.stackexchange.com/questions/15315/customize-the-message-tumblr-sends-to-twitter" class="external text">Webapps StackExchange post</a> for documentation and screenshots of UI.
</p><p>Tumblr is a better PESETAS destination however, since it is well established, allows for a wider variety of content, and allows more text, and links to URLs directly instead of linkwrapping them like Twitter does.
</p><p><br/>
</p>
<h2> <span class="mw-headline" id="Brainstorming"> Brainstorming </span></h2>
<h3> <span class="mw-headline" id="CRUD"> CRUD </span></h3>
<p>All of the above, and to date (2013-222), POSSE has solely described syndicating the <b>C</b>reation of content on your site (publishing) to other sites. This model has been quite successful and perhaps may be sufficient.
</p><p>However, it is worth exploring the potential utility of a full CRUD protocol for POSSE.
</p>
<h3> <span class="mw-headline" id="Create"> Create </span></h3>
<p>Create is the POSSE default. You create content on your site, you POSSE your creates to other sites. All of this is described above, and in silo-specific details on <a href="/silo" title="silo">silo</a> pages.
</p>
<h3> <span class="mw-headline" id="Read"> Read </span></h3>
<p>Read as a verb is interesting when applied to POSSE.
</p><p>At a minimum, it's useful to implement storing links to syndicated copies of your content to provide for the future possibility of reading from downstream POSSE copies.
</p><p>See:
</p>

<p>Actual direct uses of Reading from downstream POSSE copies:
</p>
<ul><li> reverse-syndication / <a href="/backfeed" title="backfeed">backfeed</a> of activity around the POSSE copy onto your original:

</li></ul>
<p>In addition, keeping a <a href="/rel-syndication" title="rel-syndication">rel-syndication</a> link to the POSSE copy enables deleting it to perform an Update or a Delete action, as described in the following sections.
</p>
<h3> <span class="mw-headline" id="Update"> Update </span></h3>
<p>If a downstream service allows updates/edits, then when you edit your post, you could propagate that update to the downstream POSSE copy as well. (Any existing POSSE destinations that allow this?)
</p><p>It would be possible to POSSE updates to <a href="/Twitter" title="Twitter">Twitter</a> (or any other silo that disallows edits to posts) by deleting the POSSE tweet and reposting.
</p><p>Consider only POSSEing updates to Twitter:
</p>
<ul><li> if no one has replied to it yet (otherwise you'd break a threaded conversation on Twitter)
</li><li> if your changes would be shown in the truncated copy on Twitter (i.e. if your changes are past the 140 (more like 120) character horizon, no point in churning the Twitter copy).
</li><li> within a very short time window, maybe like 2-5 minutes, because otherwise the update will be seen as a duplicate to people who are reading you on Twitter.
</li></ul>
<p>All of these concerns are regarding the experience that you provide to your friends reading your tweets on Twitter, which of course should be the whole (design) reason you're bothering to POSSE to Twitter in the first place.
</p>
<h3> <span class="mw-headline" id="Delete"> Delete </span></h3>
<p>Deletes seem fairly straightforward to POSSE, especially to services which themselves propagate deletes to clients.
</p><p>E.g. one can delete a note on Twitter at any point.
</p><p>Similar to updates, consider:
</p>
<ul><li> if there are already replies to a POSSE copy (or activity like favorites/retweets), consider keeping it to keep conversation threading (and others' favorites/retweets).
</li></ul>
<p>However, if you really feel like deleting the content from your site and POSSE copies (e.g. on Twitter), go ahead and do so.
</p><p>Perhaps this is an opportunity for the UI for the deletion of a post to check to see if there's been any activity (replies, favorites, retweets) on the POSSE copy before performing the delete. One possible implementation could involve the UI informing the user of this activity (or lack of it) and reconfirming the delete request on a per-service basis.
</p>
<h2> <span class="mw-headline" id="FAQ"> FAQ </span></h2>
<h3> <span class="mw-headline" id="Worry_about_search_engines_and_duplicates"> Worry about search engines and duplicates </span></h3>
<p>Q: Do we need to worry about search engines penalizing apparently duplicate posts?
</p><p>A: That's why the POSSE copies SHOULD always link back to the originals. So that search engines can infer that the copies are just copies. Ideally POSSE copies on silos should use <a href="/rel-canonical" title="rel-canonical">rel-canonical</a> to link back to the originals, but even without explicit rel-canonical, the explicit link back to the original is a strong hint that it is an original.
</p><p>This is also an advantage of POSSE over PESOS. With PESOS - there's no way to tell what's the original and what's the copy - so they do look like duplicates.
</p>
<h3> <span class="mw-headline" id="POSSE-post-discovery_and_backlinks"> POSSE-post-discovery and backlinks </span></h3>
<p>Q: Brid.gy can use <a href="/posse-post-discovery" title="posse-post-discovery">posse-post-discovery</a> to find the relationship between a syndicated post and the original when there is not explicit link. Does this mean I should stop adding backlinks to syndicated copies?
</p><p>A: POSSEing without a backlink is considered a last resort, and has some costs associated with it. See <a href="/posse-post-discovery#Tradeoffs" title="posse-post-discovery">posse-post-discovery#Tradeoffs</a> for more details.
</p>
<h3> <span class="mw-headline" id="POSSE_or_Send_Webmentions_First"> POSSE or Send Webmentions First </span></h3>
<p>In short, <b><strong class="selflink">POSSE</strong> first, then send <a href="/webmentions" title="webmentions" class="mw-redirect">webmentions</a></b>.
</p><p>See: <a href="/Webmention#POSSE_or_Send_Webmentions_First" title="Webmention">Webmention FAQ: POSSE or Send Webmentions First</a> for details and reasoning.
</p>