Thank you to @RyersonResearch and especially @joyceemsmith  for inviting me to talk about my research today.  I had a great time talking IndieWeb, and specifically, Bridgy.

I presented a study I’ve been working on about Bridgy, in which I investigated the challenges arising from its use of Facebook’s API from 2014-2018. IndieWeb’s practice of syndicating to and from silos while also acting as an alternative to the ‘corporate web’ demonstrates simultaneous antagonism and dependence upon corporate platforms. My question then, is how this relationship might complicate IndieWeb’s efforts to build a Web that reflects its principles

I studied Bridgy by sifting through issues on its GitHub repo, identifying recurring challenges and how they were addressed. Additionally, Bridgy’s creator Ryan Barrett was kind enough to talk with with me about his work,  which added context and helped me verify that I was on the right track.

I highlighted three recurring challenges in Bridgy’s development:

1. Mapping between the open Web, where resources are identified using URLs, and platform APIs, where they are are identified using arbitrary IDs. This problem kept recurring, which highlights the ongoing labour necessary to maintain a software like Bridgy.

2. Instances where Bridgy had difficulty determining the privacy status of posts or photos.  These are thankfully uncommon, but present a significant problem when they do occur. Bridgy errs on the side of preserving privacy, but this has sometimes meant compromising its expected functionality.

3. Precarity of relying on APIs. For the most part, Bridgy is able to endure API updates due to ongoing maintenance work by its developers. However, Bridgy lost support for Facebook in 2018, when the API was updated with dramatic privacy restrictions.  These restrictions are a response to Cambridge Analytica’s mass collection of Facebook data, but also impact legitimate apps like Bridgy (and Internet researchers). Fortunately, Bridgy still works with other platforms— e.g. The post you’re reading now was syndicated to Twitter with Bridgy.

The Cambridge Analytica news broke when I was in the middle of studying how Bridgy used Facebook’s API during the same timeline. Being immersed in Facebook’s API helped me understand some of the nitty gritty of what had happened and how this affected third-party developers, and I tried to convey some of that in my talk.

Finally, I think Bridgy’s development history demonstrates the kinds of challenges that arise when trying to build alternatives alongside corporate platforms, instead of simply opting out. While principled technologists attempt to build a Web for the future, they must work through the present. This means contending with messiness, heterogeneity, and resistance from established infrastructures.