Seems like a lot of new faces, and some of the homepage demos highlighted the political (and emotional) stakes of carving out one’s own space on the Internet. I’ll be tuning in all day and chatting at https://chat.indieweb.org/
Here’s a quick reminder that IndieWebCamp Austin is this weekend. If you’re in the #DoOO, #edtech, or #IndieWeb spaces and can’t attend in person, there should be some interesting conversations and work that can be done to participate remotely (via chat, video, etc.) to help you improve and b...
Actually we didn’t talk journalism very much. Most of the people there were from other parts of the same parent faculty as the journalism school (Communication and Design). I briefly talked about Storify’s shutdown since a lot of news outlets used Storify in its heyday.
Most of the discussion was a bit more general — future directions for alternative social media, regulatory responses, considerations for maintaining one’s values when using social media, etc.
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.