POSSE
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.
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.
Sites
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) :
- Tantek.com as of 2010-01-01[1] (2010-01-26 Twitter syndication started[2] and caught up[3][4]). Tantek Çelik implemented POSSE in Falcon on tantek.com.
- all self-hosted posts (notes, articles, etc.) are openly PuSH+Atom real-time syndicated with a PubsubHubbub hub to Google Buzz, StatusNet, etc.
- notes (and article titles) are snowflake copied by the personal site server to Twitter with permashortlink citation links/references (see Whistle for details) back to the original. Copies of notes to Twitter are also automatically recopied from there to Facebook.
- ... 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.
Advantages
POSSE is considered a robust and preferable syndication model for the following reasons:
- ownership. by posting first 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 PESOS).
- Not dependent on 3rd Party services -- if you can access your site, you can publish your content
- Canonical URLs to your content are on your domain
- Copies posted on 3rd Party services can link or cite the original on your site (see syndication_formats)
- discovery of your original content from the copies on 3rd party services is enabled by the permashortlinks to your originals posted on said services
- backfeed can be used to pull in (reverse syndicate) responses from other services
- allows taking advantage of other services' social layers and aggregation features while storing the canonical copy of your content on your own site
- ...
POSSE Destinations
TODO: Link to/write dev articles/blog posts which guide people in syndicating their content out to these networks
- API Access - posting new tweets works nicely due to permanent API tokens, and the return value contains a URL to the posted
- Supports very complete web action endpoints, so semi-manual posting is easy to implement
Facebook
- API Access - New posts can be created through the API
- A web action endpoint (
https://www.facebook.com/dialog/feed) 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. TODO: find docs (they don’t seem to be on the FB website)
Google Plus
- No write API (yet)
- 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.
Software Libraries
- PHP
- The POSSE namespace in php-helpers (might be moved to a separate package) contains various truncation, preparation and syndication functions including HTML => plaintext µblog syntax converter
- …
Publishing Flows
There's at least two ways to implement a POSSE content posting flow:
Client to Own Domain to 3rd Party Services
- The user writes a piece of content using a publishing client
- Optional: client provides UI for selecting which 3rd party services to push to if it knows about them, with optional customizations for per service
- Having finished the content, the user publishes content to their server (optionally: with metadata of which 3rd party services and any customizations thereof)
- Optional: client can generate a permalink knowing the state of the server, and publish to that permalink
- The server publishes the content, generates a permalink and summary (and/or customized content suited to 3rd party services) if necessary
- The server posts copies with permalinks to 3rd party services
Advantages:
- User only has to interact with one site over the internet, their own
- Syndication can be done fully automatically by the server
Disadvantages:
Client to Own Domain and 3rd Party Services
- The user writes a piece of content using a publishing client
- Having finished the content, the user publishes it to their server
- The client queries the server for the URL of the content it just pushed
- The publishing client presents the user with an interface for selecting:
- Which 3rd party services to publish to
- The exact content published to the services, pre-filled with a summary based on the produced content
- The user selects the services and submits the form
- The publishing client posts the content summaries out to the 3rd party services
Advantages:
- More user control over timing and editing of copies of content to 3rd party services
Disadvantages:
- Syndication requires a manual step each time
- Dependent on client connectivity directly to 3rd party services (problematic in flakey mobile situations, or when client is publishing using domain-censored internet access).
Background
See Also
Related
