POSSE is an acronym/abbreviation for Publish (on your) Own Site, Syndicate Elsewhere. It's a Syndication Model where the flow involves posting your content on your own domain first, then syndicating out copies to 3rd party services with perma(short)links back to the original version.
It's a key part of why and how the "IndieWeb" movement is different from just "everyone blog on their own site", and also different from "everyone just install and run StatusNet/Diaspora" etc.
POSSE is actually more important than federation. POSSE is about staying in touch with current friends now, rather than the potential of staying in touch with friends in the future. 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.
The following IndieWebCamp participants' sites 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) :
User:Sandeep.io 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.
werd.io as of 2013-05-31 . Ben Werdmuller implemented POSSE in his idno 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.
iamshane.com - need to copy example from rel-syndication page
glennjones.net as of 2014-01-14 Glenn Jones The blog implemented POSSE using a new version of transmat.io 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.
... add more here ...
... 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.
Partial POSSE sites
Sites which only POSSE some of their content, and still post directly to the same silo they POSSE to.
Other partial POSSE sites:
A similar but opposite approach is PESOS where content is posted first to 3rd party services and then copied/syndicated into a personal site.
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.
POSSE is considered a robust and preferable syndication model for the following reasons:
How To Implement
There is no one POSSE implementation technique, you have to implement it per silo destination.
In general, when your content posting software posts something, it should also post a copy to the silo destinations of your choice, with a permashortlink (or permashortcitation) back to your original.
The details of how to do so vary per destination. See the sections below.
Main article: Twitter#POSSE_to_Twitter
Twitter is perhaps the most popular POSSE destination and a good place to start.
If you can start posting notes (tweets) to your own site and POSSEing to Twitter, instead of posting directly to Twitter, you have taken a big step towards owning your data.
See POSSE to Twitter for details on how to POSSE both notes and articles (blog posts) to Twitter.
Main article: POSSE to Facebook
Main article: Google+#POSSE
Main article: Medium
Main article: WordPress
TODO: Link to/write dev articles/blog posts which guide people in syndicating their content out to these networks
There's at least two ways to implement a POSSE content posting flow:
Client to Own Domain to 3rd Party Services
Client to Own Domain and 3rd Party Services
All of the above, and to date (2013-222), POSSE has solely described syndicating the Creation of content on your site (publishing) to other sites. This model has been quite successful and perhaps may be sufficient.
However, it is worth exploring the potential utility of a full CRUD protocol for POSSE.
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 silo pages.
Read as a verb is interesting when applied to POSSE.
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.
Actual direct uses of Reading from downstream POSSE copies:
In addition, keeping a rel-syndication link to the POSSE copy enables deleting it to perform an Update or a Delete action, as described in the following sections.
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?)
It would be possible to POSSE updates to Twitter (or any other silo that disallows edits to posts) by deleting the POSSE tweet and reposting.
Consider only POSSEing updates to Twitter:
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.
Deletes seem fairly straightforward to POSSE, especially to services which themselves propagate deletes to clients.
E.g. one can delete a note on Twitter at any point.
Similar to updates, consider:
However, if you really feel like deleting the content from your site and POSSE copies (e.g. on Twitter), go ahead and do so.
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.
Worry about search engines and duplicates
Q: Do we need to worry about search engines penalizing apparently duplicate posts?
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 rel-canonical 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.
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.
Q: Brid.gy can use posse-post-discovery 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?
A: POSSEing without a backlink is considered a last resort, and has some costs associated with it. See posse-post-discovery#Tradeoffs for more details.
Articles and blog posts about POSSE, especially implementing it: