POSSEing silo interactions is getting harder by the day, and Bridgy Publish is suffering as a result. We could fix this by adding an OwnYourGram-style PESOS option. Should we?
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.)
Thoughts?
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
retweets). Bridgy
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
/statuses/user_timeline and
/favorites/list.
Facebook‘s
Real Time Updates
should work. I’ve already used it in
ownyourcheckin. I’d subscribe to
/user/likes and /user/feed, which I think should include comments.
I could also poll those endpoints.
Google+ has no way to get comments or +1s by user, only by post. API docs; feature request; SO answer.
Instagram can get likes by user, but not comments.
Not an issue for me at all! I deliberately have a slower POSSE process for “likes” and such, where I take the time to post on my site, with some commentary about the original post.
This shields me from the “like everything” that happens on silos and I only collect deliberate, reasonable things I like on my own site.
Edit: Also experience with bridgy suggests that silo APIs are quite unreliable; Twitter sometimes does not return favs for instance. I would hate to lose posts because the silo API barfed.
I wonder if there is a better way to break up the parts of brid.gy. It might make more sense to have brid.gy backfeed separate from brid.gy POSSE separate from brid.gy PESOS. Then it becomes an a-la cart solution. Someone maybe could handle all their own publishing but just notify brid.gy which posts to watch (after their syndication links have been added).
In any case, I like to think that the speed issue will go away in the future. Once indieweb readers really start, that’s when we would hopefully get those one-click like buttons etc.
For a while I was doing my own PESOS for my tweets so that I could still reply to people from the Twitter app and get those back on my site as posts. I quickly ran into a problem where I was sometimes re-importing a tweet that I had originally POSSE’d and would end up with two identical posts on my site. I wouldn’t even know where to begin to try to do that with Facebook. If bridgy solves this well, I would probably use it, because I gave up running that code myself because of all the edge cases I encountered.
I am planning on doing PESOS of my Instagram, Twitter and Flickr likes, since I still often find myself in a situation where I’m reading something on one of those silos and it’s quicker to just tap their button. I would happily use a Bridgy version of that as well.
You shouldn’t be afraid of writing a micropub client for this, since it’s basically a version of OAuth 2.0 which you’ve already dealt with on Instagram and Facebook. Also most people so far have implemented non-expiring access tokens on their sites. If you wanted to make this explicit, you could add a scope to the authorization request that would indicate such.
thanks for the feedback, all!
another thought: IFTTT already has channels for all the silos. if we could get them to add a micropub channel, we’d get a lot of this functionality for free, without building it in bridgy at all!
sadly, it sounds like getting a micropub channel into IFTTT is unlikely at best.
also, gRegor raises a good point:
he’s not alone. very few sites support micropub. known might be the one with the biggest installed base, but even that is pretty small, since you have to take the extra step of installing the plugin yourself, or enabling it if you’re on the hosted service.
we could mitigate that by supporting some servers directly. known and wordpress are the two obvious candidates. that adds even more work, though, and i don’t even have the bandwidth to do the initial proposal here, much less extend it. :P
Whoa, awesome discussion in your webmentions!! Really appreciate the thought-provoking ideas and proposal. For the publish-to-Facebook cases, geez it does kind of feel like the only alternative if we want absolutely everything captured. It’s not a big itch for me — I like/comment on Facebook pretty rarely, and since 95% of my friends post everything friends-only anyway, I’m mostly not comfortable posting those interactions on my site at all.
For the quick tweet replies and likes, where it’s still technically possible to do through the API, I’m not ready to throw in the UX towel yet! (FWIW I’m hacking on a little indieweb reader, I expect it will always be crude and never up to Shrewdness quality but it will most definitely be able to send a micropub like with one click)
I’ve been forcing myself to like/repost tweets and Instagram photos exclusively through POSSE since 1st Jan. Although I get a self-righteous feeling of “correctness” it does take a few extra steps of copy-and-pasting URLs and I probably act on fewer things as a result.
Using PESOS for likes (and optionally reposts?) seems like an acceptable trade-off (I would still POSSE my replies). I already have a Micropub endpoint so in theory it should Just Work on my site, although I appreciate your audience is smaller for this. I’d certainly be happy to help test it.
That would be amazing :) Happy to test out!