dentonjacobs.com

Before I can really start building anything, I have to understand what it is that I’m building. Step 0, design. As such, here are my thoughts for what I want to accomplish. I definitely want to start small, building the most impactful features, and build momentum while I continue to make progress.

I post very infrequently. I guess, in truth, I want that to change. I think sharing more will help me become a better person. I’ve talked about this before, but I want to remove friction from posting. Sure, Twitter doesn’t have much friction, but Twitter has its issues. Among the biggest for me is that I want to own my data. So, here I am posting the old way about how to do it the new way.

Micropub is an open standard for posting content. There are existing web clients and, at the time of this post, at least one iOS app in development for posting content to a blog and syndicating that content to any number of services. It’s becoming a de facto standard in the Indie Web world. It was even created and is maintained by an Indie Web Camp Co-founder. It’s also used by Micro.blog. I love the idea.

However, the way Koala is built, it currently expects everything for a post to be stored in a markdown file with some YAML headers. This has worked for me so far, but I’m not sure that’s the way Micropub works. With Micropub, data is transmitted as form-data or JSON.

So I come to a decision point. Does the endpoint on my site convert submitted data to a markdown file and maintain the current state? Or should the app be enhanced to also read a JSON file and convert to HTML at the time of render? The former is probably easier and quicker to implement, while the latter is probably more feature-rich and extensible for the future. Likes, comments, web mentions, etc., seem better suited with JSON, at least right now. But I haven’t truly investigated that yet.

Markdown makes sense for writing, as it’s fast, simple, portable and easily converted to HTML for display on the web. It was an easy choice for getting started. Now that I’m looking to add more functionality, I wonder if JSON is a better storage mechanism. It has many of the same attributes: fast, portable, easily converted. It may not be as simple as pure Markdown, but it could contain Markdown as part of the content. I have to decide if that’s too work to bite off right now, or if it’s better to convert before the next steps.

I’m set on maintaining a database-less site and application. Databases are great, but I’m not trying to mess with that right now. I want simple, portable data that doesn’t require a database.

Reading about p3k and file format used, I’m leaning toward sticking with the current Markdown structure, and having the app update the YAML section as needed. I’m not sure how I’ll handle comments or web mentions, but I suppose that can be addressed when I’m ready for them.

So I’ve decided to maintain the current structure of using a Markdown file to indicate a post, and using YAML headers for metadata about the post. Next, I have to build the Micropub endpoint. To authenticate against this endpoint, I will use IndieAuth for generating tokens. So, the first part to build is a way to validate tokens.

Once this has been tackled, I can begin the process of handling posts made to the Micropub endpoint. I plan to start with what will likely be the most common use case: h=entry posts. This will allow me to create notes and articles on my site from another app or service. Seems like the most reasonable place to start.

In the future, I hope to be able to support other types of content, including like, reply, repost, and other types of content, including possibly h=cite, h=card, and h=event.

This post has helped me nail down a plan: I will build a Micropub endpoint. The endpoint will start with authentication and authorization, and will validate tokens. Once validated, the endpoint will process the posted JSON data and convert it to a Markdown file with various bits of metadata stored as a YAML header. This file will be picked up by Koala, converted to HTML and used for display to the caller.

Decicion made, now to build!