• Why Continuum Works This Way
• What Continuum is NOT
• “This is harder than a normal Nostr client”
• “Does this mean convenience doesn’t matter?”
• “When would I actually use this?”
• “Why would I run something locally?”
• “I already work locally (Word, Office, backups, etc.) — isn’t that the same thing?”
• “Most users won’t care about sovereignty”
• “Why not just use Substack or WordPress?”
• “Why not make this a mobile-first app?”
• “Will Continuum become easier to use?”
• “This feels like overengineering”
• “Why does Continuum run as a local web app (even in the native apps)?”
• “Why separate signing and publishing?”
• “Why would anyone pay for this?”
• “Why isn’t Continuum open source? Wouldn’t that add more credibility?”
• Closing

§Why Continuum Works This Way

Responses to the most common questions and objections about Continuum’s design.

Andrew G. Stanton - Friday, April 24, 2026

Continuum is not trying to be the easiest way to post to Nostr.

It’s solving a different problem — one that most tools don’t even attempt to address.

If you’re expecting a typical client, some of the design decisions here may feel unnecessary, or even confusing at first.

That’s understandable.

Most software today is designed around convenience, speed, and continuous connectivity. Continuum is designed around something else: authorship, identity, and control that persists beyond any single platform or moment in time.

This page is a response to the most common questions, concerns, and objections that come up when people first encounter Continuum.

Not to convince everyone — but to clarify what it is, and why it exists.

§What Continuum is NOT

Before getting into specific objections, it helps to be clear about what Continuum is not:

• not a social feed
• not a hosted platform
• not optimized for instant posting
• not trying to replace every Nostr client

§“This is harder than a normal Nostr client”

Short answer:
Yes — at the beginning. Not where it matters.

Most Nostr clients are optimized for immediate interaction: open the app, write something, hit publish.

Continuum introduces a different flow:

• write locally
• manage your identity intentionally
• sign events under your control
• publish when and where you choose

That adds a small amount of upfront friction.

But it removes a different kind of friction entirely — the kind that shows up later:

• lost drafts
• fragmented identity
• dependence on a single client or interface
• inability to work offline

Continuum shifts effort to the front so that you’re not paying for it later.

Principle:
Ease at the start often creates dependence later.

§“Does this mean convenience doesn’t matter?”

Short answer:
No — it matters a lot.

Convenience is not the enemy. Poor tradeoffs are.

Most modern tools optimize heavily for convenience — but often by centralizing control, hiding complexity, and introducing long-term dependency.

Continuum is taking a different approach:

• preserve control first
• then reduce friction on top of that

The goal is not to make things harder.
The goal is to make things simpler without giving up ownership.

That’s a more difficult problem.

But it’s the right one to solve.

Principle:
Convenience should not come at the cost of control.

§“When would I actually use this?”

Short answer:
When your work matters enough to keep.

Examples:

• writing articles you don’t want to lose
• maintaining a long-term archive of your work
• publishing without depending on a single platform
• working offline and publishing later
• managing multiple identities across contexts

Continuum is not for every post.

It’s for the work that matters.

§“Why would I run something locally?”

Short answer:
Because what matters should exist under your control first.

When you run Continuum locally:

• your drafts, identities, and keys remain under your control
• your archive exists independently of any service

A hosted system can be convenient, but it introduces a dependency:

• on uptime
• on policy
• on access
• on long-term availability

Continuum doesn’t remove publishing or distribution — it simply makes them secondary.

You still publish to relays.
You still interact with the network.

But the source of truth lives with you.

Principle:
If it matters, it should exist under your control first.

§“I already work locally (Word, Office, backups, etc.) — isn’t that the same thing?”

Short answer:
It’s similar — but not the same.

Working locally with tools like Word or offline editors gives you control over your files:

• you can write without an internet connection
• you can keep drafts and backups
• you’re not dependent on a platform to access your content

That’s a good foundation.

But Continuum is solving a different layer of the problem.

It’s not just about storing files locally — it’s about:

• identity (who authored this?)
• authorship (can this be verified?)
• integrity (has this been altered?)
• portability (can this move across systems without losing meaning?)

In a typical local workflow:

• authorship is implied, not proven
• identity is tied to the device or file system
• publishing requires exporting, copying, or trusting another platform

In Continuum:

• every piece of content is cryptographically signed
• authorship is verifiable, not assumed
• identity is portable and independent of any one machine
• publishing is a separate step — not a dependency

So yes — working locally is part of the story.

But Continuum extends that idea into something more complete:

• local control plus verifiable identity
• offline writing plus independent publishing
• files plus signed events

That’s the difference.

Principle:
Local storage preserves your files.
Signed authorship preserves your identity.

§“Most users won’t care about sovereignty”

Short answer:
Most users don’t care — until they do.

If everything works, centralized systems feel fine.

But when something breaks — access revoked, platform changes, data lost, identity compromised — the lack of control becomes obvious very quickly.

Continuum is designed for those moments:

• when you need to trust your own system
• when you need your work to persist
• when you need your identity to remain intact

It’s not built for passive consumption.
It’s built for durability.

Principle:
Systems should be designed for failure conditions, not ideal ones.

§“Why not just use Substack or WordPress?”

Short answer:
Because those are publishing platforms. Continuum is an authorship system.

Platforms optimize for:

• engagement
• distribution
• growth
• retention — not ownership

Continuum optimizes for:

• ownership
• identity
• continuity

On a platform:

• your work lives there
• your identity is tied to their system
• your distribution is controlled by their rules

With Continuum:

• your work exists locally first
• your identity is cryptographically yours
• publishing is something you do, not something you depend on

You can still use platforms.
Continuum just ensures you’re not defined by them.

Principle:
Convenience platforms optimize for engagement, not authorship.

§“Why not make this a mobile-first app?”

Short answer:
Because writing and identity management are not mobile-first activities.

Mobile apps are excellent for:

• quick interactions
• short posts
• passive consumption

They are not ideal for:

• long-form writing
• managing multiple identities
• handling keys and signing
• maintaining an archive

Continuum is built around the act of authorship — not just posting.

That said, mobile absolutely matters — and will play a role.

Principle:
The primary environment should match the primary activity.

§“Will Continuum become easier to use?”

Short answer:
Yes — significantly.

Reducing friction is a core focus going forward.

That includes:

• improving onboarding and identity setup
• simplifying the writing and publishing flow
• reducing unnecessary steps without sacrificing control
• exploring mobile and companion experiences

The challenge is not whether to make it easier.

The challenge is how to do that without breaking the underlying model.

That takes time.

But it’s the direction Continuum is moving.

Principle:
Ease should be built on top of solid foundations — not used to replace them.

§“This feels like overengineering”

Short answer:
It feels that way because most tools hide the complexity somewhere else.

Continuum surfaces things that are usually abstracted away:

• identity
• signing
• storage
• publishing

Other systems simplify the experience by centralizing these responsibilities.

Continuum separates them.

That separation is what makes:

• offline workflows possible
• identity portable
• publishing flexible
• systems durable

It’s not complexity for its own sake.
It’s clarity about where things actually live.

Principle:
Simplicity on the surface often comes from complexity hidden elsewhere.

§“Why does Continuum run as a local web app (even in the native apps)?”

Short answer:
Because it provides the best balance of flexibility, consistency, and control.

Continuum uses a local web app (served on localhost) as its interface, even when packaged as a native app.

This is a deliberate design choice.

It allows:

• a consistent experience across Mac, Windows, and Linux
• faster iteration and improvement without maintaining multiple UI codebases
• a simpler architecture for managing identity, signing, and storage

More importantly, everything runs locally on your machine:

• your keys never leave your environment
• your drafts and archive are stored locally
• no external service is required to use the core system

This approach may feel unusual at first, especially compared to traditional native apps.

But under the surface, many modern applications use similar patterns — combining local services with web-based interfaces.

Continuum makes that model explicit.

Over time, the interface and experience will continue to improve — including how this is packaged and presented.

But the underlying goal remains the same:

Keep the system:

• local-first
• portable
• and fully under your control

Principle:
Architecture should prioritize control and consistency — even if the implementation looks different at first.

§“Why separate signing and publishing?”

Short answer:
Because authorship should not depend on connectivity.

In most systems:

• writing and publishing happen together
• you need a connection to complete the act

In Continuum:

• you can write and sign offline
• the event is complete once signed
• publishing can happen later, from anywhere

This enables workflows that are otherwise impossible:

• writing without internet access
• transferring work between machines
• publishing on your own schedule
• separating creation from distribution entirely

This is not a minor detail — it’s a fundamental shift.

Principle:
Authorship should not depend on connectivity.

§“Why would anyone pay for this?”

Short answer:
Most people won’t. The right people will.

Continuum is not designed for:

• everyone
• casual users
• passive consumption

It’s designed for:

• writers who care about their work
• builders who care about identity
• individuals and organizations who value control

The value isn’t in convenience.
It’s in what you retain:

• ownership
• independence
• durability

Those are not always visible immediately — but they matter over time.

Principle:
Not all tools are meant for everyone.

§“Why isn’t Continuum open source? Wouldn’t that add more credibility?”

Short answer:
Eventually, yes — and it will be.

Open source can absolutely increase transparency and trust, especially for technical users.

Continuum is not opposed to that.

At the same time, there are a few practical considerations:

• the project is still evolving rapidly
• the architecture is being refined in real-time
• documentation and structure are not yet where they need to be for a clean public release

Releasing too early would create confusion rather than clarity.

There is also a business reality:

• this is a solo-built system
• it represents a significant investment of time and effort
• and it needs to become sustainable

The current approach is:

• continue building and refining
• reach a baseline level of sustainability
• then open it more broadly

So this is not a rejection of open source.

It’s a matter of timing and readiness.

Principle:
Transparency matters.
But timing matters too.

§Closing

Continuum is not trying to replace every Nostr client.
It’s not trying to compete with every platform.

It exists for a different reason.

If your goal is speed, convenience, and minimal setup — there are already excellent tools for that.

If your goal is to own your work, control your identity, and publish without dependency — Continuum will make sense.

It may take a little longer to see it.

But once you do, it’s difficult to go back.