If you’re going to own your posts on social networks, indieweb people prefer to POSSE: post on your own site, syndicate elsewhere. Bridgy Publish follows this philosophy and provides POSSE as a service.
POSSE has its disadvantages though. The Twitter app, for example, lets you favorite a tweet with a single tap and ~100ms latency. Best of breed mobile indieweb approaches can’t touch that right now. Mine, for example, take many more taps and 10-20s. Browser-based implementations and webactions are a bit better, but not much.
The silos don’t even allow POSSEing interactions consistently, if at all. Facebook’s 2.0 API often prevents commenting, liking, and resharing. Instagram’s API supports liking but not commenting. Google+’s API is read only, full stop. Twitter has a fairly complete write API, but must be taken with a grain of salt.
Proposal: what if we added a Bridgy Publish PESOS option alongside the current POSSE model?
The arguments for POSSE and against PESOS are well founded. They’re also aimed primarily at posts, not interactions. For interactions with single silo posts, especially likes and reposts – which rarely include additional content – PESOS ain’t so bad, and it comes with two big benefits:
- Full support for all interactions in all silos.
- Use the silos’ native UXes (often single-tap and low latency), databases (venues, contacts, etc.), and other features (e.g. character counting) for free. No need to reimplement them or bolt them onto your own site.
Some of the PESOS drawbacks still apply. It enables silo-first authoring and presentation and may discourage indie and cross-silo interactions. Those would be just as doable, though, since we’d keep the current POSSE functionality.
This would be a big project, but it’s doable. Bridgy would watch your silo account for replies, likes, and reshares that it didn’t create. When it sees one, it creates a matching original post on your site, via micropub or whatever. (I despair at implementing even just the token management, much less a full micropub client, but those are literally implementation details.)
Update: To flesh this out a bit, here’s what I could and couldn’t do with each of the four main silos.
Twitter has a streaming API
that sends events for new favorites and tweets (including @-replies and
has used it before.
It broke when Bridgy went over 100ish Twitter users,
but it would work for just one user. Even so,
it’s a bit expensive on App Engine,
so I’d probably just poll
Real Time Updates
should work. I’ve already used it in
ownyourcheckin. I’d subscribe to
/user/feed, which I think should include comments.
I could also poll those endpoints.