From IndieWeb
PESOS icon
PESOS icon

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.


IndieWeb Examples

HU, Pili

Pulls content from multiple silos and present them in his own sites (currently only in form of an RSS feed) using SNSAPI

  • Facebook
  • Twitter
  • Renren, the large OSN in China. It's a Facebook like model:
  • SinaWeibo, ("weibo" in Chinese means "micro-blog"). It's a twitter like model:
  • 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).
  • The aggregated status update from those silos: . 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 hereโ€ฆ (see this for more details)

  • Add yourself and a list of the silos you PESOS from



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.


  • 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:


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]

      Discovered via [2].
  • 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).
      • this is completely silo-dependent; if your post was intended for a certain silo, there is no quality difference - 2017-06-08 Peter Molnar
    • link-wrapping (e.g. Twitter hides all links behind their link-wrapper)
      • links can be followed and extracted, but that requires extra work - 2017-06-08 Peter Molnar


See Also