Numeric Citizen I/O — A Blog About Blogging

Week 36 Summary (Aug 30 - Sep 5, 2026)

Mon, 07 Sep 2026 07:04:15 -0400

A week built around one big unresolved question — whether Birchfeed could replace Inoreader and become the feed backbone for the RSS Flow web app. That thread ran Sunday through Tuesday, moving from curiosity to a Claude Code exploration to a firm decision on Tuesday night to keep the existing feed management. Publishing stayed steady around it: four blog posts went out (Apple’s inflection point under John Ternus, CleanShot 5, the August digest, and anticipation for the September 9th iPhone event). Tool testing was the other constant — two Craft betas, the CleanShot 5 upgrade and its video recording, Claude Design, and Claude AI scheduled tasks all got a turn. The back half of the week tapered into lighter housekeeping and photo sharing on Moments, the photo-journaling app discovered on day one and used three times before the week was out.

Making Eight Years of Blogging Searchable

Sun, 06 Sep 2026 10:20:14 -0400

I have been publishing on Ghost since October 2018. That is 677 posts, and until this week I had no good way to ask questions about any of it. I could search my own site, which matches titles. I could remember roughly what I wrote and when, which works for the last few months and fails completely for 2019.

What I wanted was to ask “what have I written about X” and get a real answer drawn from the full text of every post. Ghost offers an API but no MCP endpoint, so the obvious path was not available. Here is what it actually took, including the parts I got wrong.

Starting with what already exists

There are several community-built Ghost MCP servers. I tried one that supports the read-only Content API, and it worked immediately. Posts, pages, tags, authors, all queryable in conversation.

For about an hour I thought I was done.

The thing that quietly breaks everything

Ghost 6.0 removed support for ?limit=all and imposed a maximum page size of 100 on every API endpoint. That change is documented and reasonable, since unbounded queries hurt large sites.

The problem is how it fails. Requesting ?limit=all does not error. It returns 100 items and says nothing about the other 577.

I found this by running a curl command to measure my archive size and getting back exactly 100 posts. A suspiciously round number for a blog running since 2018. The same cap applies to any MCP server built on the Content API, which means every answer I had been getting was drawn from my most recent fourteen months of writing while presenting itself as complete.

That is worse than an error. An error tells you to fix something. This just quietly narrows your world.

There is a second limitation underneath it. Ghost’s NQL filter language has no like operator and no partial matching, and content fields are not filterable at all. You can retrieve plaintext in a response, but you cannot query against it. So even with correct pagination, there is no way to search article bodies through the API.

Ghost’s own site search works around this the same way I ended up doing: download the corpus and search it locally.

The local copy

The design that followed is unglamorous and took an afternoon.

A Postgres table holding one row per post, with the full body in a plaintext column and a generated tsvector column indexed with GIN. An n8n workflow pulls the archive weekly with explicit pagination, seven pages at 100 posts each with a one second delay between them, and upserts everything in a single round trip.

The schema is boring on purpose:

create table ghost.posts (
  id            text primary key,
  slug          text not null unique,
  title         text,
  plaintext     text,
  url           text,
  tags          text[],
  published_at  timestamptz,
  updated_at    timestamptz,
  synced_at     timestamptz not null,
  fts tsvector generated always as (
    setweight(to_tsvector('english'::regconfig, coalesce(title, '')),     'A') ||
    setweight(to_tsvector('english'::regconfig, coalesce(plaintext, '')), 'B')
  ) stored
);

The setweight calls mean a title match outranks a body match. Without them, a post that mentions a term once in passing can outrank the post named after it.

Two details in the sync are worth stealing if you build something similar.

Full reconcile, not incremental. My first instinct was a watermark on updated_at, which is what I use for feed-based syncs. It is the wrong tool here. It would save six HTTP calls a week and would never detect a deleted or unpublished post. Pulling everything self-heals.

A guard on the delete step. Every row gets stamped with the run’s timestamp, and anything older gets pruned, which is how deletions propagate. But the prune only runs if this pass fetched at least 80% of the rows already in the table. Without that check, one bad fetch silently wipes eight years of archive. This is the kind of thing you want in place before you need it.

I was wrong about the size

I nearly did not build this because I assumed the archive would blow past my database provider’s free tier. That assumption was off by roughly two orders of magnitude.

677 posts come to 3.2 million characters of body text. The table with its full-text index totals 11 MB against a 512 MB limit. I would need something like 32,000 posts to be in trouble.

A related surprise: my recent posts average about 8,400 characters while the archive average is 4,700. My writing has roughly doubled in length over eight years. I did not know that about myself before running the query.

The more useful lesson is that on serverless Postgres, storage is almost never the binding constraint for text. Compute hours are. Every query wakes the database for a minimum billing interval regardless of how fast it runs, so a scattered handful of ad-hoc searches costs more than the weekly bulk write does. Worth knowing before you optimise the wrong thing, which I did for a while.

The part I did not anticipate

With the table populated, I assumed I was finished. I was not, and the gap here is the least obvious thing in this whole project.

Nothing routes the question.

Each time you ask something, the assistant picks tools based on their names and descriptions. It sees a Ghost MCP whose tools are explicitly labelled as browsing and reading blog posts. It also sees a generic SQL tool pointed at a database it knows nothing about. Ask “what have I written about X” and the match is overwhelmingly toward the Ghost tools, which return the 100 most recent posts and no warning.

Building the better data source does not cause it to be used. You have to say so, explicitly, somewhere persistent.

I solved this with a Skill: a set of instructions that triggers on phrasings like “what did I write about X” and states the routing rule as a prohibition rather than a preference. Do not use the Ghost browse tools for search, here is why they fail, here is the table and the query shape to use instead.

The skill also pins the retrieval pattern, which matters more than I expected. Search first with ranked snippets, then fetch full bodies for only the three to five posts that are actually relevant. And read whole posts, never fragments. A paragraph mentioning a product without the surrounding argument is exactly how you end up having your own past position mischaracterised back to you.

Full-text is not semantic search

I conflated these two for a while, and the distinction is worth being precise about.

What I built matches words and their grammatical variants. Ask about “Apple Intelligence” and it finds posts containing those words. Ask “how has my thinking about AI subscriptions evolved” and it will find something, because the words appear somewhere, but it has no way to surface a post that discusses the same idea in entirely different vocabulary.

Semantic search needs embeddings, a vector column, and a model called at both index and query time. That is a real layer of work.

I deliberately did not build it. Full-text over 677 posts with English stemming handles the lookup questions well, and lookup is most of what I actually ask. If the thematic questions come back consistently thin, the embeddings layer drops into the same table without rearchitecting anything. Building it up front would have been solving a problem I had not yet confirmed I have.

What it does not do

Four posts have empty bodies. The unauthenticated Content API cannot see members-only content, so gated posts arrive with a title and nothing else. They are findable by name but their text is not indexed. Fixing that means switching to the Admin API with JWT signing, which is not worth it for four posts.

The copy is up to seven days stale. Irrelevant for archive questions, relevant if I ask about something published yesterday.

And the whole thing is lexical. When a thematic question comes back thin, the honest answer is that the tool is not built for it, not that the archive is silent.

Was it worth it

An afternoon, one database table, one scheduled workflow, and one skill file.

The first real test was asking what I had written about GuruShots, a photography game I covered in late 2018. Two posts came back with dates and links. Through the Ghost API alone, that question has no answer at all.

That is the whole point. Eight years of writing is only an archive if you can reach into it.

Week 35 Summary (Aug 23 - Aug 29, 2026)

Sun, 30 Aug 2026 09:07:13 -0400

A week bookended by writing. It opened with On Integrating Quick Reads Into My Digital Ecosystem going out the door on Sunday, and closed with three consecutive mornings on “I’m proud of my failures” article as a creator alongside the next issue of the ephemeral scrapbook newsletter. Underneath it all was a sustained hunt for better reading sources — chasing an RSS feed on understandingwar.org, adopting Bubbles.town, and opening a trial of Standard Reader. AI experiments ran in parallel almost daily: Whisper transcription on the M4 Mac mini, scheduled tasks in the Claude cloud, Claude in gateway mode against Ollama, and an attempt to make Ghost CMS content searchable through Claude — most of them reaching a verdict rather than staying open. Maintenance took a real share of the week too, with n8n instability, a manual MCP config merge, and a refreshed ecosystem diagram, while a consistent editorial stance on engagement-driven platforms surfaced twice in conversation.

Week 34 Summary (Aug 16 - Aug 22, 2026)

Sun, 23 Aug 2026 10:52:27 -0400

A week with one clear centre of gravity: the On Integrating Quick Reads Into My Digital Ecosystem piece, picked up on five consecutive mornings — continued, diagrammed, re-diagrammed, then restarted from scratch on Thursday. Around it, Claude AI shifted from assistant to workbench: documenting MCP endpoint dependencies, connecting Neon Postgres, refreshing n8n workflow docs, and by week’s end turning bank statements into a financial dashboard for retirement planning. Reading was front-loaded into early mornings and skewed toward AI commentary and Apple’s App Store fight, with a detour into Craft Agents. Infrastructure got quiet attention too — an n8n upgrade to 2.35.4, and a failed Micro.blog highlight deletion that turned into a support ticket. Momentum tapered after Wednesday: Friday came down to a single entry, and Saturday was blank.

Week 33 Summary (Aug 09 - Aug 15, 2026)

Sun, 16 Aug 2026 10:48:05 -0400

This is my first week summary. It is built automatically with AI by consuming my manually-written notes Craft Daily notes where I document most of my activities. Then, I do some touch ups before publishing here.

A week centered on the Quick Reads read-later service, which threaded through nearly every day — from drafting a review and appreciation piece to extracting text highlights, weighing data portability, and wiring a Quick Reads section into the personal Dashboard. Automation was the second big theme: the newly discovered Brrr push-notification app went from curiosity on Tuesday to being integrated into four n8n workflows by Saturday, while Claude Code helped tidy the bookmarking app’s documentation and fix its code. Two blog posts shipped — ‘The digital toxicity’ on the return to the web for app development, and ‘It’s fun to go back’ reflecting on past writing. Reading and watching leaned heavily on AI and industry shifts, spanning antirez on lab risks, the OpenAI/Hugging Face incident timeline, the end of Google Search, and self-hosting LLMs to control token costs. The week opened with continued research for an upcoming iPhone review, focused on the camera control button.

Experimenting with a new visitor card design

Sun, 02 Aug 2026 09:34:43 -0400

I’m currently working on an updated visitor card for my digital space. The following is an updated version, the same design as before but with updated information. It’s done in Keynote. The second is an AI-generated concept for a refreshed design. I’m kind of liking the new structure (my wife, too). I might try to reproduce this in Keynote, but I see a few challenges. Keynote is limited for things like this, and I’m not sure I want to switch to another app.

I went looking for a reason to use Ollama

Sun, 26 Jul 2026 15:39:46 -0400

I tried to find a place for Ollama in my automation stack. I wanted two things: a lower Anthropic bill, and Ollama running somewhere in my workflows. The first reason didn’t survive contact with the data.

The number

I have a workflow that pulls my Anthropic cost report every morning and posts it to Discord and my Craft daily note. So I checked it.

Thirty days, 56 workflows, every LLM call I make: $7.48. Twenty-five cents a day, already down 60% over that window.

Moving everything off Claude would save about $90 a year. Keeping Claude for work where quality matters brings that closer to thirty.

I standardized most of my stack on Haiku months ago. That’s where the savings already went. I went looking to cut a bill that was already at its floor, because reducing API costs sounds like good engineering whether or not the number supports it.

Ollama Cloud costs more than I spend

Two things I had confused: open-weight models and locally-hosted models are separate choices. I don’t want models running on my Mac. That’s not an argument against open models — Ollama Cloud runs them on their hardware behind a normal API. I’d even set up the credentials back in December and forgotten.

But Ollama Cloud doesn’t bill per token. It’s a flat subscription metered by GPU time, with session limits every five hours and weekly limits every seven days. Pro is $20 a month — nearly three times my current bill, for smaller models.

The free tier might cover my volume. I can’t confirm that, because Ollama has no account usage endpoint. Checking your quota means logging into the web dashboard. Several open feature requests ask for an API; none have shipped. You find out you’re near the ceiling when they email you at 90%.

I went looking to reduce a cost I track with a daily automated report, and the alternative can’t be tracked with one.

The reason that holds up

Cost is out. Privacy doesn’t apply — I’m summarizing my own RSS feeds and my own billing data.

What’s left: I don’t know which of my workflows actually need a frontier model.

I have a dozen-plus workflows making LLM calls. Some summarize articles or pull signal out of a week of notes. Others do arithmetic and pattern-matching dressed up as reasoning. I’ve never tested the difference. Everything points at the same model because at twenty-five cents a day there was no reason to check.

An open model is a cheap way to test that. Not to replace Claude — to find out where the line is. Any task where a small open model matches Haiku is a task I’ve been over-provisioning.

The experiment

I picked the most mechanical node I have: the one that asks four questions about thirty numbers. Trend, spikes, projection. 570 tokens in, no nuance required.

Both models now run in parallel from the same prompt, joined by a merge node so the message builder doesn’t fire twice and double-post. Both answers print back to back, labelled with their model. The Ollama arm fails soft — a rate limit on the test shouldn’t break the report.

One thing I nearly got wrong: I reached for the largest open model first, because it was the name I recognized from the docs. Wrong instrument. A big model will obviously handle a trend summary, and confirming that tells me nothing. If you’re looking for the floor, start at the floor.

If you’re considering the same thing

Spending real money on inference? Do the migration. The math works.

Bill is a rounding error? Then cost isn’t your reason and privacy probably isn’t either. The useful question is which of your automations need a frontier model and which ones you’re over-provisioning out of habit.

I’ll report back either way.

AI made me replace another subscription: Ulysses

Sat, 18 Jul 2026 17:07:43 -0400

I finally cancelled my subscription to Ulysses. Why? I was using Ulysses because it supported Craft’s export document so that I could then publish either to Ghost or Micro.blog. Since the beginning of this year, I’ve created two n8n automation workflows to publish directly from Craft to Ghost or Micro.blog.

Publishing from Craft to Micro.blog with a Single n8n Workflow

This is a technical write-up of an n8n automation that takes a document written in Craft, converts it to clean HTML, rehosts its images, and publishes it to Micro.blog as a draft — all from a single webhook call. It’s a companion to an earlier Craft → Ghost publisher and reuses the same document-fetching approach, but targets Micro.blog’s Micropub API instead of a proprietary CMS.

The goal is to write in one place (Craft) and let automation handle the tedious, error-prone part: block conversion and image migration.

What it does

An AI assistant (via n8n’s MCP integration) or any HTTP client sends a webhook request naming a Craft document by title. The workflow then:

Searches the Craft space for that title.
Scores the search results to pick the actual matching document.
Fetches the document’s full block tree.
Converts Craft blocks into Micropub-ready HTML.
Extracts every Craft-hosted image, downloads it, and re-uploads it to Micro.blog’s media endpoint.
Swaps the original image URLs for their new Micro.blog-hosted equivalents.
Publishes the result as a draft for manual review before it goes live.

The whole run typically completes in about 4–6 seconds, with image uploads accounting for most of the overhead.

Trigger and input

The workflow is triggered by an HTTP POST webhook that waits for the full run to complete before responding (a “response node” pattern), so the caller gets the final published URL back synchronously. It’s also exposed through n8n’s MCP server, which is what lets an assistant invoke it conversationally.

The input payload is minimal:

{ "targetTitle": "My Article Title" }

Flow overview

Webhook
  → Search Document in Craft
  → Find Best Matching Document
  → Fetch Document Content
  → Convert Craft Blocks to HTML
  → Set Micro.blog Token
  → Extract Craft Image URLs
  → Has Images?
       ├─ true  → Split by Image URL → Download from Craft → Fix Filename
       │          → Upload to Micro.blog Media → Merge Upload Result
       │          → Reassemble HTML → Merge Before Publish
       └─ false → Format No-Image Post → Merge Before Publish
  → Publish to Micro.blog
  → Respond to Webhook

The interesting problems

Most of the engineering effort went into three areas that aren’t obvious until you hit them.

1. Title matching against a full-text search

Craft’s search API does full-text search, not title-only. That means a document that merely mentions the target title somewhere in its body can rank above the document actually named that. Publishing the wrong document is a nasty failure mode.

The fix is a small scoring node that runs after the search and ranks each candidate:

Exact title match: 100
Title starts with the query: 80
Title contains the query: under 50, penalized by how much longer the title is than the query

Before comparing, it strips Markdown noise — bold markers, italics, and heading prefixes — so formatting in a title doesn’t throw off the match. If nothing scores above zero, the node throws a descriptive error that lists every candidate it saw, which makes debugging a missed title trivial. The node emits the single best match in the same shape as the search results, so the downstream “fetch content” step doesn’t need to know any scoring happened.

2. Converting Craft blocks to HTML

Craft stores documents as a nested tree of typed blocks, not as HTML. A dedicated conversion node walks that tree and emits Micropub-ready markup. It covers:

Paragraphs and headings (h1–h4)
Blockquotes and horizontal rules
Unordered and ordered lists — consecutive list-item blocks are grouped into a single <ul> or <ol> rather than emitting one list per item
Task checkboxes (rendered as ✅ / ☐)
Images, wrapped in <figure>
Rich-link bookmarks, rendered as a styled bookmark block
Code blocks (<pre><code>)
Inline formatting: bold, italic, strikethrough, inline code, links, and proper HTML-entity escaping

It also handles two different document shapes — a notebook with sub-pages and a flat single document — with a fallback lookup, so it doesn’t matter how the source is organized.

3. Rehosting images across services

Craft images live on Craft’s own CDN. If you publish those URLs directly, your post depends on Craft continuing to serve them — not acceptable for a permanent blog post. So every Craft image has to be pulled down and re-uploaded to Micro.blog.

The image branch:

Regex-scans the generated HTML for Craft image URLs.
Splits into one item per image.
Downloads each image’s binary from Craft.
Fixes the filename extension based on the response’s MIME type (Craft URLs don’t always carry a usable extension).
Uploads each image to Micro.blog’s media endpoint as multipart/form-data.

A subtle detail: Micro.blog’s media endpoint returns 202 Accepted and puts the new image URL in the HTTP Location response header, not in the body. To capture a header you have to ask the HTTP node for the full response rather than just the parsed body. A later node maps each uploaded image’s Location back to its original Craft URL by index, and the HTML is reassembled with every Craft URL replaced by its Micro.blog equivalent.

Image failures are handled gracefully: the upload node continues on error, so if one image fails (AVIF, for instance, tends to be rejected), the post still publishes — that image just keeps its original URL instead of breaking the whole run.

Why Micropub

The most reusable idea here is that Micro.blog speaks Micropub, a W3C standard, rather than a proprietary publishing API. The final payload is a standard h-entry:

{
  "type": ["h-entry"],
  "properties": {
    "name": ["My Article Title"],
    "content": ["<h2>...</h2><p>...</p>"],
    "post-status": ["draft"]
  }
}

Any Micropub-compatible endpoint would accept the same shape, so the publishing half of this workflow isn’t locked to one host. The post-status: draft field is deliberate — every post lands as a draft so it can be reviewed in the editor before going public. The endpoint responds with the new post’s URL, a preview link, and an edit link, which the workflow passes straight back to the webhook caller.

Error handling

A shared error-handler workflow catches failures across the automation.
The webhook always responds, even on failure, so a caller never hangs.
Image-upload failures are non-fatal (see above).
A missing title produces an explicit, descriptive error listing what was searched.
Full-text false positives are neutralized by the scoring node rather than by hoping the search ranks correctly.

Credentials and configuration (redacted)

For obvious reasons, the specifics below are not published:

Craft Connect REST link — a private access link used to search Craft and fetch block content.
Micro.blog app token — a Bearer token generated in Micro.blog account settings, stored in a dedicated “Set Token” node so it can be rotated in one place.
n8n instance URL, webhook path, and internal workflow IDs — infrastructure details specific to a self-hosted deployment.

If you rebuild something like this, you’d supply your own Craft access link and your own Micro.blog token, and point the workflow at your own n8n instance.

Takeaways

Treat a full-text search as untrusted input and score its results before acting on them.
When migrating content between hosts, migrate the assets too — don’t hotlink another service’s CDN.
Watch where an API returns the data you need; a Location header is easy to miss if you only read response bodies.
Prefer open standards (Micropub) over proprietary APIs where you can — it keeps the integration portable.
Publish to draft first. Automation should hand you a reviewable result, not a live surprise.

The Second Half of 2026

Tue, 16 Jun 2026 21:53:16 -0400

After spending the first half of 2026 vibe-coding web applications, now that they are mature and operational, I’m thinking about how I’m going to spend the second half: setting up and finding the right use cases for running agentic AI locally on my dormant M4 Mac mini. Just another digital world open for exploration.

Tue, 16 Jun 2026 19:27:58 -0400

Manton Reece on WordPress blogs in Micro.blog:

Several months ago I blogged that we wanted to have more integration with WordPress and Ghost in Micro.blog. I’ve now rolled out the first part of that, with an option to add a WordPress blog to Micro.blog’s web interface. New posts and edits sync back and forth between Micro.blog and WordPress.

I no longer use WordPress; I use Ghost since I moved out a few years ago. I’m really looking forward to seeing how this new integration enables new workflows or simply tweaks existing ones. Some posts are rather complex, and I’m curious to see how Micro.blog would handle these.

Reach is the right word

Mon, 15 Jun 2026 21:46:59 -0400

I was exploring the GitHub website, my profile page to be exact. Here’s my GitHub activity panel for 2026 so far. Apart from the commits from the Micro.blog auto-archiving process, this is what it shows, with everything beginning on January 1st: the contributions coming from my vibe activities. This represents nearly 8 commits per day, every day, resulting in seven custom-built web applications.

Looking back on the past six months, I cannot believe how far I’ve come with all this. If I could choose one word to summarize what generative AI and vibe coding have done for me, it would be “reach”. I have achieved goals that would otherwise have required years of coding experience. The only thing I had was years of end-user experience and a clear idea of what would be fulfilling.

Excited to see what the next six months of 2026 have in store.

Here and There

Sun, 14 Jun 2026 15:28:48 -0400

If it’s a very short thought, it goes here. If it’s a great link, I share it there, too. Any in-the-moment thing is here, too. When I explain why I do this and how I do that, it’s right here. Long-form articles or a new edition of my newsletter, well, that’s over there. Other written tidbits, not too short, not too long, well, it goes here, of course. I wish I could make this post stick to the main page.

From Craft to Ghost (images included)

Sun, 07 Jun 2026 08:46:20 -0400

I finally have a Claude skill that works end-to-end for publishing a document (with images) in draft mode from Craft to Ghost. Two important things happen with this workflow: Claude invokes an n8n workflow that first creates the article in Ghost and performs a full image rehosting from the Craft backend to Ghost. Without this rehosting, images in the Ghost article would still refer to resources hosted on the Craft backend, which I don’t want. 😎

Of course, none of this would be required if there were a way to publish directly to Ghost from within Craft. 🤷🏻‍♂️

The Numeric Citizen Analytics Dashboard Experiment

Sat, 06 Jun 2026 08:49:07 -0400

This morning, I delved into integrating Craft with Claude Cowork. Using the Craft MCP connector, I built a dashboard that sources data directly from Craft tables. This setup generates a Live Artifact in Claude Cowork, which dynamically updates as more data is added. Although Lovable could have been used to achieve this, the absence of custom domain support in its free tier led me to choose Claude Cowork, which offers more flexibility for my needs.

The Numeric Citizen Digital Ecosystem — Edition 2026-04

Mon, 27 Apr 2026 17:38:17 -0400

Today, I’m excited to share my latest digital ecosystem update, previously known as “The Numeric Citizen Content Creator Workflow”. The diagram sports a new title: “The Numeric Citizen Digital Ecosystem” to better reflect its scope: to enumerate services and apps at the center of my digital presence. It was entirely rebuilt in Apple Freeform, leaving Apple Keynote behind. Freeform is a joy to use; it’s much more flexible and powerful than Keynote, too. The content was also expanded to include a new set of tools I have built over the last few months since publishing the previous update. Let's dive in for all the details.

The entire ecosystem diagram was rebuilt from the ground up. Full resolution version available here.

At a high level, both Micro.blog and Ghost remain the two hosting and publishing pillars for most of my *.numericcitizen.me websites, while a few other websites, like my Ko-fi page and my new about website, Who Is Numeric Citizen, are hosted elsewhere. On the diagram, my websites are positioned on the left and in the top-left portion.

As you might notice, a lot has happened since my last update. Thanks to Claude AI and Claude Code, I made a major shift toward web app to meet two fundamental needs: a brand new bookmark manager (replacing AnyBox), and a lightweight RSS reader that integrates with my bookmark manager. Together, they support my reading workflow and help me produce the Ephemeral Scrapbook newsletter. See both web apps in this YouTube video.

My custom-built RSS reader web application

What’s in, what changed since last fall

AI is now playing a more prominent role in my digital ecosystem since the beginning of 2026. It’s mainly used for vibe coding, maintaining my web applications, and content summarization. You’ll see little light bulbs (💡) in the diagram; they indicate where AI summarization is involved. Anthropic’s Claude AI replaced OpenAI’s ChatGPT in all my workflows. Plus, Claude AI and Claude Code enabled many new possibilities for helping me build small digital services and web apps for my personal needs. It’s something I couldn’t have imagined a year ago.

Claude Code’s main window with some of my projects on the left sidebar and the DIFF view shown on the right

Another milestone was to replace IFTTT with n8n automation. It’s a major upgrade in functionality and usability. My n8n instance is running on the Digital Ocean hosting service, inside a pre-packaged “droplet” with 1 GB of RAM and 10 GB of disk space for $6 a month. Digital Ocean provides a one-click install of n8n which really made a difference in selecting Digital Ocean as a hosting service. I created more than a dozen automations, far more complex and useful than what I could build with IFTTT. Claude AI was also involved in optimizing many n8n workflows. It was possible because n8n supports the MCP endpoint that is exposed to Claude AI. In the following table, I present a summary of my n8n automation workflows. As you will see, Discord is a new entry, as it provides a custom server to receive n8n workflow outputs and some status reports from Tinylytics. Also good to know: all my n8n workflows are automatically documented in a Craft document, thanks to Claude Code, which connects to both the n8n and Craft backends. To get a well-structured documentation, I created a Claude Skill.

A portion of an automation workflow shown in the n8n canvas

My automated n8n workflows

Here’s a list of utilities running as n8n workflows on my self-hosted DigitalOcean instance.

API Credit Health Check — Pre-flight check on Anthropic credits; alerts Discord if depleted
Today's Forecast — Pulls weather data into the Craft daily note
Tinylytics Insights — Injects site analytics summary into the Craft daily note
Apple Daily News — Fetches MacSurfer headlines into the Craft daily note
Setup Craft Daily Note — Creates the day's 8-section journaling scaffold in Craft
Anthropic Daily Cost Report — Posts 7-day and 30-day AI spend breakdown to Discord

Example of automatically propulated Craft Daily note, thanks to n8n automation.

RSS & News Aggregation

A few workflows are used for content processing in the context of news consumption and Micro.blog timeline processing.

RSS Daily Summary — Aggregates RSS feeds and delivers an AI-summarized digest
Micro.blog Timeline Highlights — Summarizes Micro.blog activity via Claude
Apple News Flash Alerts — Real-time Apple news alerts from RSS
Apps & Services Release Highlights — Monitors release notes feeds for notable updates

Content & Publishing

Other workflows for supporting my content creation include:

Craft → Ghost — Two workflows (specific and generic) push Craft documents to Ghost as drafts
Ghost Publish Proxy — Triggers final publication on Ghost via webhook
Craft Fetch Proxy — Fetches Craft document content on demand for downstream processing
Poke to Craft / Peek at Ghost — Manual/chat-triggered utilities for quick content inspection

Newsletter & Email

A special workflow automation is processing email summarization on demand: simply forwarding an email to a dedicated Gmail account and after a few seconds I’ll receive a summary on my Discord server.

Email Summarizer — Polls Gmail every minute; summarizes newsletters and posts to Discord

Maintenance

Finally, backing up my workflows is a must, just in case something really bad happens on my n8n instance.

GitHub Backup — Backs up all n8n workflow definitions to a GitHub repo every Sunday

The Craft Agents main window

The updated diagram illustrates this: Craft consists of two parts—Craft content stored in the Craft cloud backend and various Craft clients, including the native general-purpose client and Craft Agents. Additionally, Craft now supports MCP and offers a comprehensive set of APIs, emphasizing the division between data storage and client applications. These latest additions to Craft are game changers and enable new use cases.

A few thoughts and observations about Craft Agents, a sort of spin-off of Craft, are worth sharing here. Think about Craft Agents as an orchestrator of AI agents. In many ways, Craft Agents can be compared to the Claude Desktop app. There is a high level of affinity between Craft Agents and Craft, connected via APIs or MCP. Consuming Craft content through Craft Agents is an obvious use case. Yet, I’m still not sure why the team behind Craft is spending so much effort on this, but it’s interesting to follow nonetheless. I’m still looking for clear use cases for it, hence the yellow dot (🟡) on its icon in the diagram. There are a few aspects of the app’s design and structure that I don’t like. I don’t like using the task manager to organize conversations. I don’t think task management belongs in this app. Plus, Craft Agents is a very hungry consumer of AI credits. It’s a major concern unless you subscribe to the highest tier of any AI provider (OpenAI, Anthropic, etc.). It’s worth noting that Craft also offers an assistant working inside Craft itself.

Also added to my digital ecosystem is CleanShot Cloud for hosting publicly shared screenshots or short screen recordings. I use that to share bugs or feedback. CleanShot X is sort of the client to CleanShot Cloud and is the best Mac utility you can get if you tae a lot of screenshots.

One last automation that prevented me from closing my IFTTT account was the process of automatically archiving my publications in DayOne. This process was briefly described in this blog post. Each time I share a blog post or an article, it is saved in DayOne. Micro.blog added a send-to-DayOne feature, which was the last needed nail in the coffin of IFTTT. It was such a relief.

Speaking of Micro.blog, I created a new website for sharing automated blog post digests on a monthly basis. Most of the process is supported by the use of AI summarization. It’s not fully automated but very effective. Each month I send my Micro.blog postss digest to Craft fo later processing using Craft Agents. The process takes less than 15 minutes to complete. I know there is a potential for a fully automated process. It’s on my todo list.

What’s out since the last update

Chillidog Web Hosting is out (the service hosting the Who Is Numeric Citizen website). It was replaced with Realmac Software Elements’ hosting solution. You can read the doc here. The transition was seamless. I prefer integrated solutions, which Realmac is now offering. Plus. Chillidog was purchased last year by Exact Hosting, and the purchase has been reported to degrade customer service.

Last fall, I added the ChatGPT Atlas browser to my ecosystem, but I removed it after switching to Claude AI. OpenAI Atlas was mainly used for summarizing articles, but now I do this within the Claude Desktop app. I still prefer using the ARC Browser, even though it might eventually be discontinued. The new browser, Dia, could take its place, but I’m interested to see how things unfold. Dia appears to require a Pro subscription to enable AI features in the browser. At $20 a month, I’ll pass.

Gone is Google News for cross-posting from Micro.blog. It never took off. Also gone is AnyBox, the very well-done bookmark manager available on all Apple platforms, but not available on the web, like Raindrop.io. I never liked Raindrop.io, so I built my own bookmark manager as a web-only app. It’s one of my new custom-built web apps.

Finally, the numericcitizen.io domain will be retired when it expires later this year, and the content hosted on a dedicated Craft subscription has already been moved to my main Craft subscription, helping me reduce costs. The meta.numericcitizen.me is taking over (my previous content was migrated there during 2025). Some of my content was also simply removed from public access.

My newly redesigned metablog as seen in dark mode

Still pondering about these

You’ll find yellow dots on the diagram which points to services or apps that I’m reconsidering. Let’s review a few of them.

Plausible vs Tinylytics: I use two web analytics. Plausible has been around in my ecosystem since I left Google Analytics. Then came long Tinylytics and I wanted to support its developer plus it provides a great design compared to Plausible. Yet, I have a lot of historic data in the latter. Plus, I started using Tinylytics APIs to feed one of my workflows who inject data inside Craft daily notes and dashboard web application. I could replace this with Plausible’s APIs but I don’t feel it’s worth the effort.

Things 3, a popular and highly regarded task manager, is currently being reconsidered. I like managing my to-dos, but I don’t have many. If I want to eliminate Things 3, I could switch to Craft’s basic task management, but it’s quite limited. For now, my most likely option is to create my own app, much like I did with my RSS reader or bookmark manager. However, I’m not in a hurry to switch away since it doesn’t require a subscription, giving me plenty of time to decide and develop a replacement.

Ulysses is another case where I’m pondering its long-term usefulness. If I can post to Micro.blog or Ghost directly from Craft (using my custom-made n8n workflows), why should I continue paying for this app? The next renewal is a year from now.

Finally, my Flipboard account hosts a magazine that pulls content from my main website via its RSS feed. I have 8 followers, apparently. I never get any reactions or comments from this place. The bigger question: is Flipboard still a thing these days?

Risk management

In this edition of the diagram, I included red dots (🔴) to indicate potential disruption risks. For example, Anthropic recently adjusted Claude's credit consumption, leading to a fivefold increase in the number of credits needed to perform the same task; something I've noticed too. Additionally, Anthropic conducted an experiment in which new subscribers could access Claude Code only if they chose the Max subscription tier at $200 per month. Although they quickly reversed this change, it raises the concern that they might eliminate the $20 plan altogether. If that happened, I could face serious difficulties and might stop maintaining my web applications built with Claude Code. Vercel is another risk potential: I’m using the free tier, which is rather generous. If they decided to remove this free tier, I would have to reconsider my position: either drop my web application or accept paying the monthly price they charge.

Concluding thoughts

This evolution reflects a fundamental shift in how I approach my digital life. By embracing AI assistants like Claude and building custom tools tailored to my specific needs, I've moved away from cobbling together disparate services toward a more cohesive, intentional ecosystem. The transition from automation platforms like IFTTT to n8n, coupled with the ability to code solutions with Claude Code, has given me both flexibility and control—rare commodities in the world of Software-as-a-Service.

The introduction of AI summarization across my workflows has transformed how I consume information, while the consolidation of my web presence under fewer, better-managed domains simplifies my digital footprint. Yet this ecosystem remains dynamic and somewhat fragile, dependent on the sustained availability of key services and the pricing decisions of AI providers. The risk management considerations I've outlined aren't just technical footnotes—they're essential guideposts for maintaining digital independence in an increasingly interconnected world.

As I continue to iterate and refine this ecosystem, the principles remain constant: intentionality, control, and the ability to evolve. The next edition will likely bring even more changes, but I'm optimistic that the foundations I've built will prove resilient enough to adapt to whatever comes next.

Previous update to my digital ecosystem can be found here.

Solving Broken Images When Exporting Craft Documents

Sat, 25 Apr 2026 13:27:03 -0400

The Problem

When exporting articles from Craft to Ulysses and Micro.blog, images referenced by temporary URLs quickly become broken links. Craft hosts images with public URLs that expire within days, leaving your published posts with missing images. This automation workflow solves that problem by re-hosting all images on Micro.blog before publishing.

How It Works

The workflow is triggered when you request to publish a Craft document to Micro.blog. Here's what happens behind the scenes:

A request is send in Claude with the article title to publish
The n8n automation searches my Craft space and uses a scoring algorithm to find the exact document (preventing false matches from body text mentions)
The document's content is converted from Craft's block format into clean HTML, preserving headings, lists, formatting, quotes, code blocks, and more
The workflow scans for all image URLs pointing to Craft's backend hosting
Each image is downloaded from Craft and immediately re-uploaded to Micro.blog's permanent media storage
All image references in the post are updated to point to the new, stable Micro.blog URLs
The article is published as a draft to Micro.blog for review before going live, which is a manual process

Key Technical Features

Smart Document Matching

The search algorithm scores results by how closely the document title matches the request. Exact matches score 100, partial matches score lower, and body-text mentions are heavily penalized. This ensures I get the right document even if multiple articles discuss similar topics. The search is done via Craft API endpoint.

Rich Content Support

The conversion preserves all the formatting: paragraph styles, heading levels (h1–h4), bullet and numbered lists, blockquotes, task checkboxes, strikethrough text, code blocks, horizontal rules, and rich link bookmarks. Consecutive list items are automatically grouped into single lists.

Graceful Image Handling

If an image fails to upload (for example, unsupported formats like AVIF), the system keeps the original Craft URL in your post rather than failing entirely. This ensures the article publishes even if one image has issues.

Manual Review

All posts are created as drafts in Micro.blog. I can review the final result, check that images loaded correctly, and make edits before publishing it live.

Workflow Specifications

Trigger: Webhook at craft-to-microblog (available in my n8n instance wirh MCP endpoint enabled)
Input: Simple JSON with the article title to publish
APIs used: Craft's document search and block retrieval, Micro.blog's Micropub standard API
Typical execution: 4–6 seconds (image uploads add ~1.5 seconds)
Output: Draft post URL, preview link, and edit URL from Micro.blog

Why This Matters

This automation fills a gap in the content publishing process. I can craft and organize my articles in Craft, a versatile and attractive writing environment, and then publish them to Micro.blog without losing images or manually fixing broken links. I use a similar method to publish new editions of the Ephemeral Scrapbook newsletter, which relies on a separate n8n workflow to handle Ghost CMS-specific requirements.

Fri, 24 Apr 2026 09:22:57 -0400

Now that I manage all my issues and enhancements in GitHub Issues, I just realized that I could automate many manual workflows on issues closure… many interesting ideas here, like updating the README.md file once an issue is closed by Claude Code. 🤓

Thu, 23 Apr 2026 22:18:53 -0400

I’m not planning to go any further with my Lovable experimentation. The reason? On the free plan, custom domains are not supported. It’s a complete deal-breaker. Plus, the free tier doesn’t provide enough credits to build something meaningful, and you have to wait 24 hours before getting more. Too bad, it was somewhat promising. Pass. 😔 The good thing is that I’m focusing on Vercel for hosting web apps like mine.

Thu, 23 Apr 2026 07:32:29 -0400

Restarted work for maintaining and updating the “Who Is Numeric Citizen” website, now that my 90% of my vibe coding work is completed. See the latest news post for more details.

Sun, 19 Apr 2026 17:14:13 -0400

Just testing something for my next project… for that one, I might try Lovable instead of Vercel… because I want to try different services.

Thu, 16 Apr 2026 21:59:31 -0400

From now on, I will document and track all bugs in my custom web apps using GitHub, instead of relying on checklists in Craft. Centralizing everything isn’t ideal; organizing issues in their appropriate locations is smarter. Additionally, Claude Code will be able to close issues on my request.

Sun, 12 Apr 2026 09:16:49 -0400

Today I went ahead and fully migrated “Who Is Numeric Citizen” website to Realmac Software Elements Hosting instead of Chillidog Hosting service. Here’s why: A) Chillidog was recently sold, and people are already complaining about a decline in service quality. B) What Realmac Software accomplished with Elements in the last year is nothing less than exemplary. They built mature, native web design software for the Mac and a hosting service. I prefer to reward this company for this hard work.

The migration was really simple and took me less than an hour. The service is a bit more expensive but includes more storage and unlimited network bandwidth. This could enable a future option for hosting more photography-related content. Finally, the web service feels snappier, too!

Coming Soon

Thu, 09 Apr 2026 19:20:16 -0400

One of the first things I’m going to do when I come back home is to deploy my new blog visual theme built entirely with Claude Code. It’s ready. I’m anxiously awaiting for the moment I put that project behind. Next, I’ll spend some time on Who Is Numeric Citizen website design and hosting solution (I’m thinking of leaving Chillidog Hosting hosting service to go with Elements’ built in solution instead).

Mon, 30 Mar 2026 20:42:52 -0400

I realized I forgot to clearly state the design goals before starting to build this custom theme for Micro.blog. They became clearer as I progressed and explored how Hugo and Micro.blog work, especially with assistance from Claude AI, and as I encountered various challenges. Here are the goals: a) I want a theme that stands out and doesn’t resemble typical Micro.blog blogs. b) I aim to minimize the use of external plugins, ensuring that all functionality is integrated within the custom theme. c) I want the same theme to be usable on more than one blog (I have two). Stay tuned for more news.

Takeaways From Building a Custom Micro.blog Theme Using Claude Code and Claude AI

Sun, 29 Mar 2026 19:14:16 -0400

Building a custom visual theme for Micro.blog presents unique challenges at the intersection of web design, static site generation, and AI-assisted development. This blog post captures practical insights and lessons learned from creating a custom theme with Claude Code and Claude AI, including key considerations on Hugo compatibility, plugin conflicts, and theme architecture.

Claude AI isn’t well-trained on Micro.blog architecture and dependency on Hugo static website generator. Claude doesn’t make a clear distinction between Hugo’s capabilities and Micro.blog’s unique features.
Plugins are a challenge because they might inject conflicting formatting instructions into your custom-built theme. It’s hard to debug.
Plugins can conflict with each other.
Don’t use the latest Hugo version (0.158) and stay on 0.117 if you use many plugins. By removing low-value plugins, you increase your chance of using version 0.158.
The workflow for updating a GitHub repo hosting your custom theme to the deployment on The process of Micro.blog is tedious because it’s manual and slow, especially for large websites and Hugo rendering engine. Hugo 0.158 could help, unless it conflicts with one plugin that you need.
More than ever: less is more. Keep it simple, and problems will be kept at bay: removing low-value plugins can make a big difference.
Test the website after each plugin removal, force a rebuild of the entire site to cleanup things. It’s slow but it might help debug later.
If a plugin introduces support for smart code in blog posts, after removing that plugin, Hugo will generate errors. These blog posts need to be either updated or deleted.
If the custom-built theme covers a specific design area, like a /photos page, don’t use a plugin touching the same area, prioritize the custom-built theme and skip the plugin. The idea is to have a self-contained custom theme.
Stay away from abandoned-ware plugins.
Prefer adding stuff in the custom theme instead of relying on an external plugin, so the theme is self-contained.
The lower the number of plugins, the better the chance you can use the latest version of Hugo.
Using the custom.css functionality, which helps externalize and override the custom-theme’s styling, speeds up testing different styling options.

Creating a custom Micro.blog theme using Claude AI revealed both the power and limitations of AI-assisted development in specialized ecosystems. While the tools provided invaluable support, the real breakthroughs came from hands-on debugging and understanding the unique interactions between Hugo, Micro.blog, and plugins. These takeaways form the foundation for a more robust theme architecture—one that will continue to improve with future iterations.

I’m still not done with my design. As I progress, you can visit my test blog.