Turning off Facebook for Bridgy

I announced recently that Bridgy Publish for Facebook would shut down soon. Facebook’s moves to restrict its API to improve privacy and security are laudable, and arguably the right idea, but also mean that users can no longer use third party apps like Bridgy to create posts.

I didn’t realize it at first, but similar API restrictions hit the backfeed (aka listen) feature, which sends comments and likes back to your web site. Bridgy can still see comments and likes by Bridgy users, but that’s a tiny fraction of the Facebook comments and likes that it used to see.

I spent a while looking for a workaround, and even looked into scraping HTML, but you have to be logged into Facebook to see even public posts, on both www and m, so no luck there. [Insert silo snark here.]

So with a heavy heart, I’m shutting down Facebook on Bridgy entirely. Publish will still work until August 1, but listen largely stopped working on May 24, so I turned it off altogether and disabled new user signup a few days ago.

See you on the web!


24 thoughts on “Turning off Facebook for Bridgy

  1. Thanks for all your work on Bridgy for publish, backfeed, and a myriad other great and troublesome features for hoisting content out of the Facebook silo and into our personal sites.

  2. update on other failed attempts, from the Bridgy docs:

    We tried hard to keep Facebook support alive even without the API. We first tried using email notifications for backfeed. Users forwarded emails from Facebook to Bridgy, which extracted comment text, likes, and shares, and sent webmentions as normal. This was surprisingly difficult to set up, though: many users struggled to get Facebook to actually send notification emails, even after they were turned on in settings.

    After that, we tried scraping m.facebook.com, like facebook-atom does. The scraping itself worked fine, but we never managed to evade Facebook’s bot detection consistently. They always ended up rate limiting or blocking us, even after we started rotating IP addresses, spoofing User Agent headers, and even running some JavaScript for browser fingerprinting. They have way more resources for that arms race than we do, so we gave up.

Leave a Reply

Your email address will not be published. Required fields are marked *