PESOS is an acronym/abbreviation for Publish Elsewhere, Syndicate (to your) Own Site. It's a Syndication Model where publishing flow starts with posting to 3rd party services, then using some infrastructure (e.g. feeds, pingbacks, webhooks) to create an archive copy under your domain.
The opposite (and preferable) approach is POSSE, whereby a user publishes original content to their own site, and then syndicates copies to 3rd party services, preferably with perma(short)links back to the originals on their own site.
Indieweb creators implementing PESOS on their personal sites:
- Laurent Eschenauer pulls content in from various silos:
- User:Hupili.net pulls content from multiple silos and present them in his own sites (currently only in form of an RSS feed) using SNSAPI https://github.com/hupili/snsapi
- Renren, the large OSN in China. It's a Facebook like model: http://www.renren.com/
- SinaWeibo, ("weibo" in Chinese means "micro-blog"). It's a twitter like model: http://weibo.com/
- TecentWeibo. It's another micro-blogging service in China. Due to the broad production line of Tecent, TecentWeibo has some unique access point (e.g. WeChat from a mobile device). http://t.qq.com/
- The aggregated status update from those silos: http://hupili.net/feeds/all.xml . It's currently a mix of all materials. I'll separate the English and Chinese messages later.
- Used Twitter export to back-patch Twitter IDs into posts originally syndicated out to Twitter but for which the Twitter ID wasn't originally recovered from the API.
- Uses the Google calendar export to backup calendar data in his own repository
- Add yourself and a list of the silos you PESOS from
PESOS is considered less robust and inferior to POSSE for the following reasons:
- Possible loss or restriction of ownership. By posting first on a silo, you are subject to that silo's TOS, both with entering the data and later getting it out. You calling their API or feeds to extract your own data may still shackle your data with some rights to them (e.g. "database copyright" for content contributed to silo collections like Foursquare venues). You have a dependent ownership chain for your content (from creation, to syndication/re-use, to consumption), where the silo is an intermediate dependent party that you can never be rid of.
- Twitter Developer Rules of the Road appears to prohibit export to your site:
Exporting Twitter Content to a datastore as a service or other cloud based service, however, is not permitted. Discovered via .
- Less reliable. Your site relies on 3rd Party Services to post any content
- Non-canonical. Copes archived to your domain are not a canonical copy
- Lower quality. Pulling in from 3rd Party Services can reduce the quality of content, e.g.
- character limits (e.g. 140 character Twitter posts, 200 character Foursquare shouts/tips).
- link-wrapping (e.g. Twitter hides all links behind their t.co link-wrapper)