PESOS is an acronym for Publish Elsewhere, Syndicate (to your) Own Site. It's a syndication model where publishing starts by posting to a 3rd party service, then using infrastructure (e.g. feeds, Micropub, webhooks) to create an archive copy on your site.
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.
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
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.
When creating posts via Micropub, set the syndication property to the post's original URL. This defines the new post as canonical (original) version of the post.
If you see the new post as the copy of the silo URL, then syndication is the wrong property - better would be to repost.
Advantages
more API options: difference in restrictions in APIs for content creation and content retrieval: sometimes it's possible to pull data which can't be pushed, eg. Facebook comments
native interactions: the native interfaces are sometimes quite well done for silos
prevents you from oversharing the same content to every network (no, that is not good, usually different networks attract different audience and not every content should be shared with everyone)
implementations will be async:
breakage in your site/POSSE layer will not prevent you from posting to a silo (those breakages are not as uncommon as one would like them to be)
static generators can use it as well without losing real-time ability in silos
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.[1]
Peter Molnar
