• Introduction
• What I Built (Last Summer)
• What Made It Different
• Bringing This Into Continuum
• The New Direction: Continuum Stories
• The Only Input That Matters: Tags
• How It Works
• Same Pipeline, New Surface
• Why This Matters
• No “Export,” No “Push,” No “Sync”
• The Tag Is the Interface
• Why I’m Doing This
• What This Proves
• What Comes Next
• Final Thought

Friday, April 17, 2026

§Introduction

Last summer, I built something that quietly changed how I think about publishing.

Not a new app.
Not a platform.
Not a SaaS dashboard.

A pipeline.

Using Nostr as the content layer, GitHub Actions for automation, and GitHub Pages for hosting, I created a system where:

• I write once
• publish as a Nostr event
• and a live site updates automatically

No login.
No CMS.
No “publish” button on a website.

Just content moving across open infrastructure.

As I wrote at the time:

“This post was published as a Nostr event — stored on dozens of relays, fetched with open-source scripts, rendered as static HTML, and served globally via GitHub Pages.”

Here are the original articles (stored in my archive system):

https://nostr.mycontinuum.xyz/e/?event_id=64022bc7694b63d9ccc2e6b335d285c974126a469bf79cd71f6a3c86848fc2aa

and

https://nostr.mycontinuum.xyz/e/?event_id=65e4991ab079fe3edce13389714d95ae971618b4fe2a4ac668a23f9e210b3808

§What I Built (Last Summer)

The core idea was simple:

Write → Publish to Nostr → Fetch → Render → Host

More concretely:

1. I write an article using a Nostr client (Primal, etc.)
2. It’s published as a kind:30023 event
3. A script fetches my public events from multiple relays
4. Filters by tags (blog, article)
5. Converts Markdown → HTML
6. Outputs static files
7. GitHub Pages hosts the result

And then I added automation:

“Just post on Nostr — the rest happens automatically.”

That was the real breakthrough.

§What Made It Different

There were a few key properties that mattered:

• No database I control (or lose)
• No login system
• No dependency on a platform
• Content is signed and public
• Hosting is static and free

And most importantly:

The publishing pipeline is separate from the writing experience

§Bringing This Into Continuum

Now I’m taking that exact idea and applying it to Continuum.

Not by rebuilding it.

By reusing it.

§The New Direction: Continuum Stories

Instead of:

blog.stantonweb.com

I’m creating:

stories.mycontinuum.xyz

But the model is the same.

§The Only Input That Matters: Tags

Here’s the key shift:

Write in Continuum → Publish → Tag correctly → Done

That’s it.

No:

• export step
• repo commit
• manual push
• CMS dashboard

§How It Works

1. I write an article in Continuum
2. Publish it to my public npub
3. Add a tag like:

continuum-stories

4. The site tooling:

• fetches my public events
• filters by those tags
• renders them into a static site

§Same Pipeline, New Surface

This is the exact same architecture I described last summer:

• Nostr = content layer
• GitHub Actions = automation
• GitHub Pages = hosting

But now:

Continuum is the authoring layer

§Why This Matters

This is not about blogging.

It’s about control.

Most publishing today looks like this:

Write → Save → Publish → Platform owns distribution

This flips it:

Write locally → Publish to open network → Render anywhere

§No “Export,” No “Push,” No “Sync”

This is the part that matters most to me:

The system reacts to the content — not the other way around.

I don’t “deploy” anything.

I don’t “upload” anything.

I don’t “log in” anywhere.

I just:

publish an event with the right tags

And everything else happens automatically.

§The Tag Is the Interface

This is the simplest way to describe it:

Tags control what becomes a site

Not a CMS.
Not a dashboard.
Not a config file.

Just:

[“t”, “continuum-stories”]

§Why I’m Doing This

Over the past few days, I tested whether Continuum could fit into other workflows.

Some worked.
Some didn’t.

That’s fine.

But this one?

This one is real.

Because:

• I already built it once
• I already use it
• I already understand it

§What This Proves

Continuum is not just:

• a writing tool
• a dashboard
• a local app

It can be:

the front-end to a fully automated, decentralized publishing pipeline

§What Comes Next

• build stories.mycontinuum.xyz
• define tag structure cleanly
• connect it to my npub
• start publishing Continuum-based workflows

Each article becomes:

• a story
• a demo
• a real use case

§Final Thought

Last summer, I proved this could work.

Now I’m integrating it directly into how I build and publish with Continuum.

No new system.

No new platform.

Just:

the same idea — applied more intentionally

One article at a time.