Integrated IndieWeb Services

A quick note: this post does contain quite a bit of IndieWeb jargon and may be confusing if you are only just getting started. Don't let my jargon deter you from the IndieWeb. This is an architectural discussion so I am asssuming readers have a good understanding of the standards incubated in the community.

A few weeks ago (I like to start my blog posts with a sense of time!), I started to think about whether I should merge my IndieWeb applications into one big codebase. Specifically, I wanted to merge Webmentions (social comments and reactions), Micropub (publishing on the web), IndieAuth (authentication), and maybe, although I cannot fully remember this, Microsub (social reading). The goal would be to give me one service to authenticate with instead of four.

All of the services above have complementary functions. IndieAuth is used to authenticate to the other three aforementioned services. Webmentions enhance my Microsub feed reader in terms of providing the mechanism through which reactions are sent, received, and verified. Webmentions are sent when I publish new content on my site using Micropub. There are plenty of these synergies.

I did try to consolidate the above services into one codebase but I ran into a few problems. First, the codebase was going to be big. I'm not saying that monorepositories are a bad decision. I don't know enough about them. But at the time I knew there was going to be a lot of work ahead to merge the services. I took a step back and decided to keep them all separate.

The advantage of integrating the aforementioned services -- Webmentions, IndieAuth, Microsub, and maybe even Micropub clients, although that is a separate discussion -- is to create a cohesive user experience. At the moment, I have to sign in with four services to do many IndieWeb things. Taking a leaf from the ease of use we associate with social media, I ask: is this an experience other people would want? If the IndieWeb is to become more mainstream, would the number of independent services cause issues with comprehension and an assumed commitment associated with setting up at least two different sites.

I like the idea of a "one stop" IndieWeb service. We have a few examples of this already, implementing standards to varying degrees. micro.blog provides an all-in-one microblogging solution. They support many IndieWeb standards. Known, a hosted and open-source blog solution, also implements many IndieWeb features. But to the extent I am aware, both of these don't implement social reading outside their own networks (please prove me wrong if this is the case).

There are many drawbacks to having a bundled IndieWeb service, too. First, the complexity associated with maintaining a codebase that implements various standards. Second, the IndieWeb is built upon a strong foundation of supporting building blocks. Thus, I would expect that a consolidated service provided a "build your own" sort of experience where you could choose which blocks provided by the service you could use. Want to change your webmention provider? You should be able to do that. Want to try a new reader interface? You should be able to do that too without having to completely migrate services.

I realise, as I write, that what I am advocating for sounds like a centralised service but that's not the case. Such a solution could be self-hosted and/or open-source, allowing for multiple interoperable implementations. I haven't thought through the exact ramifications of consolidating services but I'd like to at least have a discussion about it.

As a developer passionate about the web, I feel fine setting up (or even building!) a few services to let me take control over my data. But I want to ask a question that I think is really important: how can we cater to those who don't have the same level of interest and intent? How can we create interoperable, open, all-in-one solutions whose components can easily be interchanged, thus preventing vendor lock-in. I don't have an answer but this is a conversation I think needs to happen and continue as a narrative while we build services for the open web.

Also posted on IndieNews.

Tagged in IndieWeb.