iRyanBell

It Starts With A Simple Blog Theme

May 11, 2019

Clean engine

I’ve noticed a design trend where developers tend to apply an ultra-minimalistic clean-and-simple frontend touch to their own portfolios, blogs, and personal projects. Throughout our career, we spend hour upon grueling hour grasping at deeper design abstractions than we can usually reach. So, when left to our own devices without client demands and constraints, there’s this tendency to set sail toward the wide open spaces and freedom of these uncluttered surfaces.

Music is the silence between the notes. (Claude Debussy)

In this spirit, I’m working on a new theme for my blog using React (https://reactjs.org) and GatsbyJS (https://www.gatsbyjs.org/).

I’ve been on a long tour de framework for quite some time, exploring Vue.js, Nuxt.js, Next.js, Vanilla Js, etc., trying to find some magical combination of frameworks that allows me to work faster and avoid code spaghettification underneath the hood. I haven’t found that combo just yet, but this particular set of tools does seem to position my projects closer to that goal.

I started with this theme from Kyle Mathews (https://twitter.com/kylemathews): 👇
https://www.gatsbyjs.org/starters/gatsbyjs/gatsby-starter-blog/

Along the way, I incorporated pagination from Nicky Meuleman’s (https://twitter.com/NMeuleman) version: https://github.com/NickyMeuleman/gatsby-paginated-blog.

With the basic progressive web app frame in place, I’ve been integrating Material UI components (https://material-ui.com) to build out a minimalist newsfeed scaffold.

Design Material

The Material Design team at Google has really created something special. You have to take a minute to thumb through the documentation on their site to get into the beyond-responsive design mindset. https://material.io/design/introduction/

Material makes it possible https://www.youtube.com/watch?v=m1diVY4Uzjc

Material is the metaphor. Material Design is inspired by the physical world and its textures, including how they reflect light and cast shadows. Material surfaces reimagine the mediums of paper and ink.

Over the years, our environment has been becoming increasingly covered with user-interface tech — we’ve seen our most valuable tools, forms of entertainment, and social experiences escape their former physical boundaries. Material.io lays out a manifesto for a humanistic approach to producing clean interface systems rapidly in this developing machine/human graphical language of visual cues and responses.

The Material library is comprised of composable, adaptive components. It’s basically widgets all the way down.

We’re no longer creating experiences for a handful of web browsers or mobile devices. In fact, Google’s Flutter team just showcased a new update at I/O 2019, demonstrating a uniform design pattern that worked well across a countertop device, a television, a foldable screen, and a smartwatch. To reiterate, this is a single application that can deploy for a phone-sized screen, then unfold onto a larger tablet surface, shrink down to the size of a wristwatch, and enlarge to the size of a television screen, while adapting the level of detail and interactivity to match each canvas — before Material, it’s hard to imagine how we would have begun to approach such a problem.

Beyond Mobile: Material Design, Adaptable UIs, and Flutter https://www.youtube.com/watch?v=YSULAJf6R6M

Combining Material With Markdown

GatsbyJS introduced me to the Remark transformer plugin (https://remark.js.org/) for translating markdown files to static web content.

I’m exploring this new content publishing paradigm of markdown documents with human-readable YAML headers (https://jekyllrb.com/docs/front-matter) deployed as static web content, rather than server-heavy database tables with interleaved HTML/CSS markup. This removes a ton of overhead (albeit, at the cost of some search/sort functionality). In this fashion, the content is self-formatting and platform-agnostic. Sure, you lose a bit of design flexibility in the articles, but you gain more back with functional flexibility.

An issue that pops up soon after ditching the CMS, is the lack of a wysiwyg editor. iAWriter has become my favorite new writing app to fill this void: https://ia.net/writer. The distraction-free interface combined with a dark-mode setting feels like a lot like a code-editing IDE. It could be off-putting to a writer used to paper and black-on-white ink, but for a developer, it feels like home.

Admittedly, there’s still quite a bit more cleaning up to do under the hood on this humble blog theme (it never ends!) But, once it’s a little further along and there’s a bit more of a finalized structure, I’ll release the code under an open-source MIT license on GitHub.com.

Signed Posts

So, now that I have a way to get markdown documents wrapped within a layout and projected into the world, I’m intrigued by the idea of incorporating some sort of versioning mechanism with cryptographic signatures to move from centralized location-based addressing to distributed content-based addressing.

You can view a demo for how this might function over at https://github.com/iRyanBell/Markdown-signer-js. I was initially going to sketch it up in python, but it was 2am when I had the urge to code this out, and I came across a few frameworks on npm that looked more straight-forward than venturing out alone in the dark with pip.

Essentially, asymmetric key pairs create a mathematical relationship between two values — a public key, and a private key. When data is encoded with a private key, it can only be decoded by the corresponding public key. Conversely, when you encode data with a published public key, it can only be decoded with the secret private key. So, we get proof-of-authorship and secure private messaging at the same time.

This video from Computerphile has a great introduction to the idea. Public Key Cryptography - Computerphile https://www.youtube.com/watch?v=GSIDS_lvRv4

On the technical side, there are a few kinks to work out.

For instance, does it make more sense to keep the signature in a separate file (as is usually done)? If you’re not careful, you wind up with a fractal of signed documents inside of signed documents. Do you sign the frontmatter headers (and if so, do you recursively sort the keys for determinism?) And when it comes to the signature itself, is the OpenPGP standard RSA algorithm the way to go, leveraging MIT’s public key registry. Or, does it make more sense to go with something like a shorter crypto-friendly secp256k1 elliptic-curve key pair (or Ed25519?) And, when you format those signatures into the document, do you use a base64-encoding or something like an ASCII-armored detached signature?

An Open Publishing Platform

With authentication provided by the file format itself, the style self-described by the document, and the address relative to that content, we create a system where any platform can publish an individual’s content with identities shared across multiple platforms, yet no content is capable of being edited, and those identities and their content can be sent in the clear, even if their will is to remain private. What’s not clear is how you would fairly monetize such a system or safely guard against malicious intent, and those are pretty large issues.

Implementation details aside, combining a decentralized blockchain-based broadcast / distributed content-addressable storage system with these documents, we can envision a collaborative publishing system with interesting cryptoeconomic incentives. Ethereum and IPFS could certainly pull this off. I suppose the end result would be similar to Medium.com or Steemit.com, but with less platform overhead. It could be cool if it’s kept clean and simple.