Why?

I've been using the open standard Micropub for publishing to my site for almost a year.

Because it's an open standard, there are loads of great Micropub clients that can be used to publish content, so up until now I've been using them.

However, there are certain requests that are very specific to my site and my workflow that don't make sense to general-purpose Micropub clients, or that aren't as widespread as to need support. This means that if I want to create these posts, then I need to perform a manual curl, which although possible, isn't as helpful when I'm i.e. on mobile.

Since I set up a staging Micropub server last year, I've been using it as a great way to preview posts before it goes to production, which especially helps when I'm trying something new and want to make sure it'll render correctly.

However, when I want to test these out, I need to trawl back and find a previously created access token, or get a new one.

For both these purposes, I've found it less than ideal, and I want a slightly better UX than that.

So I thought, you know what, I should create my own Micropub client. I can shape it around my desire to be able to create content against staging or production, and for the content types that I want, which may not apply to how others use their own sites, or how they'd expect the contract to be implemented.

What

My new client can be found at www-editor.jvt.me, but as it requires you to authenticate against either my production or staging domains, you won't be able to view any of the form, so I've taken a handy screenshot:

As you can see, I've added the ability to:

• publish notes with a pre-uploaded photo, as I often upload from my phone, but then post on my laptop/desktop, where it's more comfortable to type out a longer alt text
• publish replies with a title (i.e. for use with GitHub issues)
• publish self-owned events
• publish h-cards for @-mentioning people

I decided I did not want to make this a general-purpose editor (at least for now), as I want to still use other folks' clients, and only use my own when I need extra stuff that's not supported in other clients.

Implementation Details

I was thinking about implementing this as a Netlify-only project, using Netlify Functions, which reduces any management of infrastructure, but as I've said before, I'm a Java developer and I want to invest in my skills where possible.

It's also been a great opportunity as I've been able to work on a full-stack application with Spring Boot, whereas I've previously done only APIs, so it gave me my first experience with how to write, and test, a Spring MVC application.

The server component of the project purely handles the IndieAuth interactions, and rendering the HTML for the forms based on which domains are currently "logged in". For Authentication/Authorization, the login process stores the access token from my IndieAuth server as an encrypted JWT (JWE) stored in a cookie, which can then be sent by the client on subsequent requests to prevent repeat authentications.

Interested in the code? Check out the initial Merge Request for the code.

The Future

I already have a number of future improvements to make which are labelled on my public issue tracker, and I'm sure now I have this capability I'll start to invest in it further.

The most important of these feature requests that I'm looking at implementing is Autoconfigure Micropub based on supported properties, which would allow my client to automagically render forms for all the content that my Micropub server supports!

Update: I've now added this support.