Write Once… Render Everywhere?

Andrew G. Stanton - Friday, April 24, 2026

---

The Promise#

One of the most compelling ideas in Nostr is simple:

Write once. Publish everywhere.

No platform lock-in.
No walled gardens.
Your content, your identity, your distribution.

At the protocol level, this works.

You can publish a long-form article (kind:30023), and it shows up across multiple clients.

But then you start noticing something subtle.

---

The Reality#

The content shows up.

The rendering does not.

The same article can look:

• correct in one client
• broken in another
• partially rendered somewhere else

And it often comes down to something as simple as an image.

---

A Simple Example#

Let’s say you embed an image like this:

![California Digital ID](https://is.gd/wNdvuS)

On Primal: ✅ Renders correctly ❌ HTML is ignored

On Coracle: ❌ Markdown image may not render ✅ HTML <img> works

So you try this instead:

<p align="center">
  <img src="https://is.gd/kZZOtf width="500">
</p>

Now:

On Coracle: ✅ Looks great On Primal: ❌ Raw HTML shows up as text

The Result#

You end up choosing:

• Write for Primal
• or write for Coracle
• or write for neither and accept degradation

Which raises an uncomfortable question:

Is this really “write once, publish everywhere”?

---

To Be Fair…#

Nostr itself isn’t the problem.

The protocol:

• stores your content
• distributes your content
• preserves your authorship

It does not define:

how that content should be rendered

That responsibility is left to clients.

--

And That’s the Gap#

Each client makes its own choices:

• Markdown support (partial or full)
• HTML support (allowed or sanitized)
• Media handling (images, embeds, previews)
• Styling and layout decisions

So while the data is portable…

The experience is not.

---

Why This Matters#

This isn’t just about images.

It affects:

• formatting
• readability
• structure
• presentation
• perception of quality

An article that looks polished in one client can feel broken in another.

For writers, that matters.

---

The Workarounds (Today)#

Right now, you have a few options:

1. Target a specific client

Write for Primal or Coracle and accept tradeoffs elsewhere.

2. Use the lowest common denominator

Plain text + links.

Reliable—but limiting.

3. Duplicate formats

Include both Markdown and HTML.

Messy and not always worth it.

---

Continuum’s Approach#

Continuum takes a different path.

It doesn’t force a choice between Markdown or HTML.

It supports both.

You can:

• use Markdown-style embeds (Primal-friendly)
• use HTML when needed (Coracle-friendly)
• or mix approaches as needed during authoring

But more importantly, it points toward something deeper.

---

Author Once, Render Intentionally#

Instead of:

write once → render everywhere (uncontrolled)

Continuum opens the door to:

write once → render intentionally per context

For example:

{{image: digital-id}}

could become:

For Primal

![California Digital ID](https://is.gd/W217cP)

For Coracle

<p align="center">
  <img src="https://is.gd/67mq3j width="500">
</p>

For fallback

Image: https://is.gd/W217cP

same content.

Different render strategies.

---

This Extends an Existing Idea#

Continuum already separates:

• signing vs publishing
• offline creation vs online distribution

This is the next logical step:

authorship vs rendering

---

Why This Matters Long-Term#

If Nostr is going to support serious publishing:

• writers need predictable output
• readers need consistent experiences
• tools need to bridge client differences

Otherwise:

“write once, publish everywhere” becomes “write once, debug everywhere”

---

The Real Takeaway#

Nostr got the hard part right:

• identity
• authorship
• distribution

Now we’re discovering the next challenge:

rendering consistency

---

Closing Thought#

“Write once, publish everywhere” is still mostly true. But what we’re learning is:

Publishing is portable. Rendering is not.

Continuum doesn’t fight that reality—it embraces it.

“Author once. Render intentionally.”