Scheduled Publishing Without Key Custody
- The Hidden Problem with Scheduled Publishing
- A Different Model
- Signing vs Publishing
- Local Storage and Event Queues
- Handling Offline Conditions
- Why This Matters
- A Step Toward Sovereign Infrastructure
- Work With Me
Andrew G. Stanton - Monday, March 9, 2026
The Hidden Problem with Scheduled Publishing
Scheduling content is a standard feature of most publishing platforms.
Blogging tools allow authors to queue posts for later. Social media platforms allow posts to be scheduled days or weeks in advance. Marketing teams often depend on these systems to plan content calendars.
But behind the convenience lies an architectural assumption that is rarely questioned.
In almost every mainstream platform, scheduled publishing requires the platform itself to hold your credentials.
Twitter holds your account keys.
Substack holds your publishing access.
LinkedIn holds the credentials required to post on your behalf.
When a post is scheduled, the platform itself becomes responsible for publishing that content later.
In other words, the platform becomes a custodian.
For traditional systems this arrangement is normal. But for systems built around self-sovereign identity, that model is fundamentally incompatible.
If someone else holds the keys, they ultimately control the account.
A Different Model
Continuum approaches scheduled publishing from a different direction.
Instead of storing credentials remotely, Continuum stores a signed event locally.
The process works like this:
- The author writes the content locally.
- The event is signed locally using the author’s private key.
- The signed event is stored locally in the Continuum database.
- A scheduler waits until the designated publish time.
- When the time arrives, Continuum publishes the already-signed event to configured relays.
The key distinction is subtle but important.
The scheduler never needs the private key.
It only needs the signed event.
This preserves the fundamental boundary that Continuum is designed to protect: the separation between identity custody and network publishing.
Signing vs Publishing
Many systems blur the distinction between signing and publishing.
Continuum treats them as two separate operations.
Signing is an identity action.
Publishing is a network action.
Once an event has been signed, it becomes immutable. The scheduler does not modify it, re-sign it, or alter its contents in any way.
It simply decides when to publish the event.
This architecture aligns naturally with Nostr’s event model, where events are cryptographically signed objects that can be distributed independently of the signing process itself.
By preserving this separation, scheduled publishing becomes a safe extension of the normal publishing workflow.
Local Storage and Event Queues
Scheduled events are stored locally in the Continuum database.
Each entry contains a small set of metadata:
Event ID
Event kind
Scheduled publish time
Status (scheduled, published, or failed)
The signed event itself already exists in the local database. The scheduler simply references that event when it is time to publish.
This approach avoids duplication and keeps the scheduler logic simple.
The scheduler does not need to understand the contents of the event. It only needs to know when to publish it.
That simplicity reduces the chance of failure and makes the scheduling system easier to reason about.
Handling Offline Conditions
One of the most important design considerations for Continuum is resilience.
Many scheduling systems assume that the machine performing the scheduling will always have an active network connection.
Continuum does not make that assumption.
If the scheduled publish time arrives while the machine is offline, the event simply remains in the scheduled state.
No failure occurs.
When the machine reconnects to the network and Continuum restarts, the scheduler detects that the publish time has already passed.
The event is then published immediately.
This behavior ensures that scheduled posts are never lost simply because the network was temporarily unavailable.
In other words, offline conditions delay publishing rather than breaking it.
For local-first software, that property is essential.
Why This Matters
At first glance, scheduled publishing may seem like a minor feature.
But implemented correctly, it becomes an important building block for sovereign publishing systems.
The difference lies in where trust is placed.
Traditional platforms require authors to trust centralized services with their publishing credentials.
Continuum allows authors to retain full custody of their identity while still gaining the convenience of automated publishing.
Signing remains local.
Scheduling remains local.
Publishing remains optional.
The author remains in control.
A Step Toward Sovereign Infrastructure
Continuum is still evolving, and many features remain ahead.
But small architectural decisions like this shape the long-term direction of the system.
Scheduled publishing implemented without key custody demonstrates that convenience and sovereignty do not have to be mutually exclusive.
It is possible to design systems that provide automation without sacrificing control.
The scheduler introduced today is a modest step in that direction.
But it points toward a broader vision: publishing infrastructure that respects identity ownership by default.
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:
You can also support this work as a Continuum Patron ($250).
Write a comment