In 2016, I registered a 10-year domain and started blogging. My focus was machine learning: backpropagation derivations, RNN/LSTM principles. Each post was meticulously crafted with custom illustrations and LaTeX equations. Using Jekyll with a sleek theme, I obsessed over fonts, equations, and layout. Three years later, I realized I’d forgotten my blog’s URL.
From 2018 to 2022, I stopped writing entirely. The mere thought of dealing with domains, fonts, configurations, and deployment was overwhelming. Then one day, I wanted to write an article explaining Stable Diffusion’s principles on an independent platform. This time, I skipped domain registration—that’s why it’s still mazzzystar.github.io—aiming for the least fussy way to publish.
I chose Hexo. The process was:
- Create a post with
hexo new 'title' - Render with
hexo g, preview on localhost:4000 - Publish with
hexo d, wait a few minutes, then see it on Github Pages
Hexo was decent, but not perfect. I typically wrote in local VS Code, then switched to the browser for preview. Each time, I had to manually add images and insert image URLs. It felt like a lot of effort, possibly just to write an article that could be finished in 10 minutes.
Later, I wanted to create a “short thoughts” page for brief, public musings: a place without likes/comments/shares, where I could record fragmented, less-filtered thoughts from daily life. Without your feedback, I could write freely what I think. But implementing this in Hexo was challenging: blogs are article lists, while short thoughts are text cards. After much struggle, I spent two days implementing this feature.
I realized several friends had similar needs: writing something on their phone and publishing it to their own blog. I wondered: could there be a truly simple, foolproof platform for quickly publishing blogs and thoughts?
The biggest challenge wasn’t technical, but trust. Users would worry about data loss if the platform shut down. I considered many solutions: self-hosted databases, daily auto-exports. But they were all too cumbersome, and the hassle would only discourage writing.
Last week, it hit me: Github itself seemed capable of this job. For developers, it’s a platform unlikely to disappear, and it allows users to store large amounts of content for free. What if we kept each user’s blog and thoughts in their Github account? Wouldn’t that ensure the data would never be lost?
Thus, Tinymind was born. After logging in with Github and authorizing, it creates a “tinymind-blog” repository in your account. Each blog post or thought you write becomes a commit to this repo. It’s serverless and open-source.
I launched this site last week, coding until 3 AM every night to implement 100% of the most desired features, including public homepages, drag-and-drop image uploads, and blog editing. In less than a week, over 400 people have created their own public blogs. You can see this by searching for “tinymind-blog” repositories on Github. Many of these users don’t know how to code at all.
Will I migrate my current blog? No, but I’ll use it to write drafts and preview, then finalize publishing on mazzzystar.github.io. I’ll also record certain rough, raw ideas on Tinymind, then compile them on my Thoughts page. When things become simple, people do them more often.
Why must the content be public? Because I don’t want Tinymind to request access to your private repositories, which means it can only create publicly visible repositories. At the same time, your blog data is stored in your own Github account, not hosted on Tinymind.
I spent many late nights perfecting Tinymind to meet my standards. Now it’s complete, and I’m moving on to the next project, but its life is just beginning. I hope it allows many non-programmers to have their own blogs, and enables those who, like me, once struggled with blogging but ultimately couldn’t persist, to keep writing longer due to its simplicity.