Plurality and the IndieWeb

It's been a long while since my last proper "blog post." I have been meaning to write one for a while but recently I have struggled to come up with a topic. I realise there is no such thing as a "perfect topic" so I thought I'd choose the most recent one that came to mind. (And use this preamble to help me overcome the blank page and get something on the digital text editor.)

I attended a Bonus Homebrew Website Club on Sunday. The first in what I hope to be a series of such events, this club was hosted on a Sunday at a time amenable to those in both Europe and the US. Thus, the event was an excellent opportunity to chat with people that I may otherwise not see on the regular HWC Europe meetings that I attend.

One topic that came up was how we could build a service -- or a framework -- that lets you create photography "challenges" to which someone could respond on your site. This could be made more generic to support any challenge. The challenge would have a root page that aggregated all of the submissions to that challenge. Submissions would be posted on someone's website then syndicated to the root challenge page. This means that anyone could see all submissions from one page. Because site owners would publish first on their website, they would have full control over how they categorized and displayed their submissions -- a custom tag? a custom category? a custom page? -- and then their content would be standardized for the aggregated version.

There were at least two paths of implementation proposed and one of them didn't even require any authentication to facilitate the above social interactions. I shall not go into details because this post is not about the idea. The most notable part of the discussion -- excluding an aside where I learned "spam" in email inboxes was named after the Spam Monty Python sketch -- was that there wasn't a one prescribed way to make this idea a reality. Using IndieWeb technologies, the idea could be implemented in different ways. Each implementation would have its own benefits and tradeoffs (i.e. one idea put a bit more burden on publishers than the controller of the aggregated page).

This was so interesting because not only was the idea open to plenty of different ways of thinking, the way one brings the idea to reality was too. Services in an open social web can use protocols to create interoperable tools but how they use those protocols is up to the discretion of the implementor. In the case of the IndieWeb, there was once a Webmention POSSE system that let you publish from your site using Webmention (implemented now in Brid.gy). The idea was later developed into "Micropub", its own W3C standard, but not before there was plenty of real world experimentation with its antecedent (which today still has myriad use cases and is still being explored.)

I am intrigued by the IndieWeb's approach to plurality and building technologies that don't serve the creation of monocultures or single ways of thinking about things. IndieWeb technologies help build plug-and-play social bridges. The technologies are your pipes. You get to decide how they connect and what you make with those pipes. This idea excites me to a great degree.

Also posted on IndieNews.

Tagged in IndieWeb.