Introducing Indiekit: The IndieWeb for Everyone
Today I’m formally launching Indiekit, the little Node.js server with all the parts needed to publish content to your personal website and share it on social networks.
Think of Indiekit as the missing link between a statically generated website and the social web protocols developed by the IndieWeb community and recommended by the W3C.
Here’s a quick feature overview:
- Publish content to your website using Indiekit’s own content management system or any application that supports the Micropub API
- Save files to a content store such as GitHub, GitLab or an FTP server
- Integrate with static site generators like Jekyll or Hugo
- Automatically share content on social networks like Mastodon and Twitter1
- Customise everything from the interface theme to the format of commit messages
Indiekit is extensible via a plug-in API and localised for use in a growing number of languages.
This project has been in development for over 3 years (it’s 40 months to the day since I released v0.0.1), and there’s still more work to do. But as the saying goes, if you’re not embarrassed by your first release, you’ve waited too long.
That said, what I’m announcing today is a public beta – I’d like to get a few more people using Indiekit to iron out any outstanding issues before I call it done for version 1.0.0 and move on to the next set of features.
Why I built Indiekit (or how I accidentally became a programmer)
I first became interested in the IndieWeb while working with Jeremy at Clearleft. I attended the second IndieWebCamp in the UK in 2013, and returned for the Brighton edition in 2015.
Both times I felt a mixture of excitement and frustration. I enjoyed learning how different IndieWeb protocols enabled you to own and control your content (websites like those of Aaron and Barry still make me envious). Yet, while I met the basic criteria – I had a website at my own domain – the most arresting ideas seemed out of reach without a deeper technical understanding.
The following month I began contracting at the Department for Education.
Working in government also influenced Indiekit’s design. Sometimes I feel like I’ve undergone a re-education programme, my taste having evolved from minimalist to functional. You’ll notice similarities to Indiekit if you’ve ever used a service on GOV.UK, but if not, you’ll appreciate its uncomplicated design.
Born of frustration
The early frustrations I encountered inform the principles behind this project.
The IndieWeb community advocates eating what you cook, which means building your own software to meet your precise needs. Fine in theory, and necessary during the movement’s earliest days when different ideas and protocols needed to be battle tested. Yet if you can’t code, it’s difficult to participate.
Services like Micro.blog are helpful as they make joining the IndieWeb much easier. Yet they achieve this by taking control of certain aspects and inevitably end up centralising things (that applications like MarsEdit and Ulysses support posting to Micro.blog but not sites using Micropub is a little concerning). As ever, there are trade offs.
Indiekit’s approach is to provide an easy to use server that can be hosted anywhere, one that is:
Accessible: the web is for everyone, and so is Indiekit. I have considered accessibility in all its guises; colour contrast, keyboard navigation, adaptive layout, localisation and have used clear, understandable language throughout. The same applies to the codebase: I’m not using TypeScript as this adds complexity for anyone wanting to contribute.
Adaptable: no two people are the same, and neither are personal websites. Indiekit makes no assumptions about the structure of your website, and offers as much customisation as possible.
Reliable: all code is documented and thoroughly tested (over 600 integration and unit tests provide ~95% code coverage) and the web application is built using good ol’ fashioned progressive enhancement.
Extensible: there are only so many integrations I can – and want to – build, but this shouldn’t prevent others from doing so. A plug-in API allows developers to add support for more social networks, content stores and static site generators. Adding new features is possible too, as endpoint plug-ins are Express middleware.
No software is un-opinionated. Indiekit is firmly of the opinion that everyone should be able to enjoy the full benefits of independent web publishing.
So that’s the background and my overriding goal. I hope I’m close to achieving it.
Still, installing Indiekit on a web server can be a bit painful. During the beta period, I’ll be writing tutorials for setting up Indiekit with different hosts, and encouraging feedback on the documentation. However, if you’ve built a static website, you should have enough expertise to set up an Indiekit server.
Beyond the initial 1.0 release, I’d like to support creating and editing additional post types. There’s also a bit of work to be done so that anyone can sign into any Indiekit server and use it as a publishing interface for their own website2 (if that makes sense – it’s a clever yet confusing feature of Micropub).
Then there’s Webmention, the IndieWeb protocol that lets you surface replies, likes and reposts of your content posted on other websites. I’ve been reluctant to work on this until support for Micropub was complete, but its an itch I’ve long been wanting to scratch.
Finally, while I’ve designed Indiekit with static site generators in mind, I’d like to investigate integrating with database-driven content management systems like WordPress and other publishing tools like Kirby (sounds like a good idea for an IndieWebCamp hack project).
There’s a rough roadmap if you’re interested. I’m hoping some features may come sooner if I’m able to build a community around Indiekit and have others contribute to the project. I’d also love to work with a content designer to improve the messaging around the project, review the documentation and refine the microcopy within the application.
To that end, I’ve set up a sponsorship programme to fund Indiekit’s continued development. I have no idea if people will be interested in this, but I know I’d have happily contributed to such a thing 5 years ago – if only in begrudging appreciation that it would mean not needing to become a programmer.