• The Goal
• Extending the Scheduler Model
• Integrating the UI
• Updating the Article API
• Publishing the Scheduled Event
• Maintaining Simplicity
• A Small Step Forward
• Work With Me
  • Early Adopters

Andrew G. Stanton - Monday, March 9, 2026

§The Goal

Today’s work focused on completing scheduled publishing support for both notes and long-form articles in Continuum.

The core idea was simple.

Authors should be able to prepare content ahead of time, sign the event locally, and allow Continuum to publish the event automatically at a chosen moment.

Achieving that behavior required coordination across several parts of the system.

The scheduler itself was only one component.

The surrounding infrastructure also had to understand the concept of scheduled events.

§Extending the Scheduler Model

Continuum already had a working scheduler for short-form notes.

Articles, however, required additional integration.

Both notes and articles are represented as Nostr events, but they differ in kind:

Notes use kind 1.
Articles use kind 30023.

To support both types, the scheduler needed to store the event kind alongside the scheduled event ID.

This allows the scheduler to treat notes and articles uniformly while still publishing them correctly.

The scheduler table therefore includes fields such as:

Event ID
Kind
Publish timestamp
Status

This small addition made it possible to extend scheduling across different event types.

§Integrating the UI

Once the scheduler supported articles, the user interface needed to reflect the new states.

The article list view originally understood only two conditions:

Unpublished
Published

With scheduling introduced, a third state became necessary:

Scheduled

If an article has a future publish time, the interface now displays a scheduled badge along with the publish timestamp.

The publish button is disabled in this state, preventing accidental manual publishing while the scheduler already has a queued event.

This change keeps the interface consistent with how scheduled notes are displayed.

Consistency across the UI makes the system easier to understand.

§Updating the Article API

Another change was required inside the article API route.

Originally, the article list endpoint simply returned articles from the database.

It did not know anything about the scheduler.

To support the UI changes, the API now performs a join between the article table and the scheduled events table.

If an article has a scheduled publish entry, the API attaches additional fields such as:

scheduled_publish_at
scheduled_publish_at_local

This allows the frontend to display scheduling information without needing to understand the internal structure of the scheduler database.

The API acts as the translation layer.

§Publishing the Scheduled Event

When the scheduled publish time arrives, Continuum retrieves the signed event from the database.

The event is then sent to the relay manager, which attempts to publish it to all configured relays.

Relay responses are recorded so the UI can display relay coverage information.

Once publishing succeeds, the scheduler marks the event as published.

This prevents the scheduler from attempting to publish the same event again.

The publishing pipeline itself did not require major changes.

The scheduler simply feeds events into the same pipeline used for manual publishing.

§Maintaining Simplicity

One design goal throughout this process was simplicity.

Rather than introducing a separate scheduling service, the scheduler remains part of the main Continuum application.

Events are stored in the same database.
Publishing uses the same relay manager.
The UI reads from the same API routes.

By reusing existing components, the scheduler remains relatively small and easy to reason about.

Complexity is often the enemy of reliability.

Keeping the system straightforward improves its long-term maintainability.

§A Small Step Forward

The scheduler implemented today may not appear dramatic from the outside.

But it represents another step toward a fully local publishing environment.

Authors can now write, sign, schedule, and publish content without relying on centralized platforms.

All identity operations remain local.

Publishing remains optional and controllable.

The system becomes a personal publishing engine rather than a client for someone else’s platform.

That shift is subtle, but it changes the relationship between authors and the infrastructure they depend on.

Continuum continues to move incrementally toward that vision.

§Work With Me

If you’re exploring:

• Nostr authentication
• Sovereign identity infrastructure
• AI-assisted workflows
• Local-first containerized systems

I offer a limited number of advisory and implementation sessions for builders, teams, and ministries working in these areas.

Typical engagements include:

• Architecture session (90 minutes) – $500
• Implementation sprint – starting at $2,500
• Ministry / Foundation advisory engagement – $2,500

§Early Adopters

I’m also looking for early adopters interested in running Continuum, a local-first publishing and identity system built on Nostr.

There is no cost for early adopters, and I’m happy to personally help with installation and setup.

Even if you’re just curious and want to see how it works, feel free to reach out.

Feedback from early adopters directly influences the direction of the project.

Contact: andrewgstanton@gmail.com
or DM on Nostr:

@Akamaister

You can also support this work as a Continuum Patron ($250).