• Step 1 — kind:1 notes
• Step 2 — kind:30023 articles
• Why this is different from normal Nostr app behavior
• The final result

Andrew G. Stanton - Thursday, May 21, 2026

Today I continued working on the new Archive Sync Service inside Continuum.

This work is about making sure local events can be persisted into a structured archive layer directly from the application runtime itself.

That archive layer is separate from relays.

It is also separate from workspace backup/export.

The goal is not merely to “post” events somewhere.

The goal is to preserve authored events as durable records.

§Step 1 — kind:1 notes

The first test was kind:1 notes.

That worked.

Continuum can now take kind:1 events from the local database and persist them into the archive structure.

That means the note is written into the local archive repository as ordinary files.

The archive stores both:

• the raw JSON event
• a markdown projection of the event content

It also updates the history tracking for that npub and kind.

Then git is used to commit and push the archive changes.

This confirmed the basic model:

local event → local archive → git commit → remote archive sync

The important part is the order.

The archive is updated locally first.

Git comes after.

So if a git push fails, the local archive write may still have succeeded.

That distinction matters.

A failed push is not necessarily a failed archive.

It may only mean remote synchronization failed.

§Step 2 — kind:30023 articles

The next step is kind:30023 support.

This matters because kind:30023 events are the long-form article layer.

Notes are important, but articles represent a different kind of authored work.

They are longer-lived and carry more context (and I’m also using THIS article to test this particular step)

Articles (kind:30023) are often the work that most needs to be preserved.

The goal now is to run the same archive sync pattern against kind:30023 events.

That means taking long-form articles from the local Continuum database and writing them into the archive structure as durable files.

The archive should preserve:

• the raw event JSON
• the markdown/article projection
• the history entry for the npub
• the event’s relationship to the broader archive index

This gives the article a life outside the database and outside relays.

It becomes part of a structured archive.

§Why this is different from normal Nostr app behavior

Most Nostr apps are centered around posting.

The usual flow is something like:

write event → publish to relays → appear in feed

Continuum is moving in a different direction.

The flow is becoming:

author locally → persist locally → archive → synchronize optionally → publish when ready

That is a very different model.

The archive layer is not just another feed.

It is a durable historical record.

It can include published events, unpublished events, edits, tombstones, markdown projections, raw JSON, RSS entries, and index files.

That starts to become something closer to personal publishing infrastructure than a social client.

§The final result

The final result I am working toward is a managed Archive Sync Service inside Continuum.

Instead of opening a Docker shell and manually running scripts, Continuum should be able to run the archive sync from inside the application.

Eventually that means a user can click something like:

Sync Events to Archive

and Continuum will handle the rest.

The service will be able to:

• check whether archive sync is available
• verify that the local archive repositories exist
• verify that git is available
• persist events into the archive
• commit local archive changes
• push remote archive updates
• show sync status
• expose runtime logs
• avoid duplicate overlapping sync jobs

This is still being built step by step.

Kind:1 worked.

Kind:0 worked.

Now kind:30023 is next.

After that, the remaining pieces are tombstones, RSS updates, and the global archive index.

Once those are wired together, Continuum will have a much stronger local-first archival flow:

every meaningful event can be preserved outside the database, outside relays, and outside any single app surface.

That is the direction.

Not just posting, backup or exporting, but a structured archive of authored events.

(crossing fingers)