ATProto & Fediverse Markdown 2026: Decentralized Publishing

In the last week of June 2026, organizations that publish on Bluesky started moving their post archives to Eurosky - one of several non-Bluesky-hosted ATProto providers that have launched in 2026. The Hacker News thread sat at 141 points for two days, and the migration story spread to Mastodon and the broader fediverse within hours. The interesting part for content creators who draft in Markdown is not the provider swap itself; it is what the swap reveals about who actually controls the content. ATProto's design pushes the post body into a Personal Data Server (PDS) the user picks, so the post survives a provider change - but the Markdown source, the rich-text payload, the conversion pipeline that produced it, and the app where the creator types live outside the protocol entirely. This article walks through what ATProto and fediverse publishing look like for a Markdown creator in 2026, why the conversion step is worth keeping client-side, and where md2rich fits in a decentralized pipeline.

What ATProto and the Fediverse Actually Change

The fediverse is not one protocol. The two relevant protocols for Markdown-creator publishing in 2026 are ATProto (the protocol behind Bluesky) and ActivityPub (the protocol behind Mastodon, Misskey, Pleroma, GoToSocial, and a long tail of smaller instances). Both are federated: a post published from one server shows up in the feed of users on any other server that has federated with the origin. Both support long-form posting as of 2026 - Bluesky shipped long-form on May 28, Mastodon has accepted long posts since version 4.0 in 2022.

What is new in 2026 is the Personal Data Server (PDS) layer. Under ATProto, every account lives on a PDS, and the PDS can be hosted by Bluesky (the company), by an independent provider like Eurosky or Blacksky, or by the user themselves on a $5 VPS. The account is portable: an export from one PDS imports cleanly into another, and the user keeps their handle, follower list, and post history. This is what the Eurosky migration wave is exercising - the protocol works as advertised, and the migration cost is measured in minutes, not weeks.

For a Markdown creator, the relevant property of PDS portability is that the post body format is invariant to provider. A post published from bsky.social, Eurosky, or a self-hosted PDS uses the same rich-text schema (a JSON structure of text and marks called Facets), and the same client apps render the result the same way. The provider choice affects operations, latency, terms of service, and regulatory jurisdiction. It does not affect what you can put in a post or how the post is rendered. From a Markdown drafting standpoint, the converter output that works for Bluesky works for every ATProto provider in 2026.

The Eurosky Migration Wave (June 2026)

The Hacker News thread that surfaced on June 27, 2026 (rooted in a Waag Foundation post about moving Bluesky data to Eurosky) gathered 141 points and stayed on the front page for two days. The post itself is short, but the comment thread surfaces the actual reasons organizations are migrating:

1. Provider concentration risk. Bluesky the company is the default PDS for most accounts. A single company's terms-of-service change, funding shock, or acquisition can lose an organization's entire post history. Even when the export format is open, the operational hassle of explaining a migration to non-technical users is high enough that several teams are pre-emptively moving.
2. Audit and regulatory pressure. EU organizations with GDPR scoping questions sometimes prefer an EU-hosted PDS for the data-residency argument alone. Eurosky is hosted in Frankfurt; Blacksky and a few smaller providers match regional residency preferences.
3. Feature and rate-limit differences. Eurosky ships generous write API quotas without the gated approval process that bsky.social uses. Independent providers can experiment with email relay, custom feeds, and moderation policies faster than the central team.

The migration itself is straightforward: export from bsky.social using the standard ATProto account export, create an account on the new PDS, import the export, redirect the handle. The whole sequence takes under an hour for an organization with a few thousand posts. Posts already published do not need to change format - they sit in the new PDS unchanged.

Where the migration gets interesting for content creators is the moment they realize the post body format does not survive every platform intact. A long-form post that started as Markdown, was converted to ATProto Facets, and was stored as a JSON structure on one PDS, will re-render cleanly when imported into another PDS using the same Facets. But the same Markdown source pasted into a Mastodon instance (an ActivityPub server) will not render the same way, because Mastodon accepts Markdown input at publish time and converts it server-side to HTML. Two protocols, two schemas, two different paste outcomes from the same source.

Why Client-Side Markdown Conversion Matters More in a Federated World

The standard argument for client-side Markdown conversion (no upload, no server round-trip, deterministic output) holds regardless of where the post eventually lives. What ATProto and ActivityPub add is a stronger version of the argument: the conversion pipeline is now a part of the creator's stack that the protocol does not regulate, the provider does not regulate, and the client app does not regulate. The protocol specifies what arrives at the PDS, not what shaped it.

For a creator publishing to multiple destinations from one Markdown source (Bluesky on ATProto, Mastodon on ActivityPub, LinkedIn via web, X Articles via their import flow, Medium via their editor), the conversion step becomes a switchboard. Each destination has a slightly different rich-text schema. Each destination's client app applies its own sanitization on paste. A paste that looks fine in Bluesky can land as escaped HTML in Mastodon, as monospace text in LinkedIn, and as broken formatting in X Articles - all from the same Markdown source.

The pragmatic move in 2026 is to keep the conversion step outside any of those destinations. The draft is Markdown. The conversion happens in a tool the creator controls (browser, local script, deterministic CLI). The destination's paste acceptance is the only variable the conversion has to navigate. A client-side converter like md2rich takes the Markdown, walks the schema differences for each destination, and emits the clipboard payload that the destination app actually accepts. No data leaves the creator's machine before they hit publish.

The privacy framing is not abstract. The Eurosky migration story is partly a sovereignty story, and sovereignty over the conversion step is something a creator can take for themselves regardless of which PDS they end up on. The decision to keep the conversion client-side is independent of the decision about which provider to host the account on - and is the easier decision to make.

A Real ATProto Long-Form Post Written in Markdown

The quick walkthrough below shows a creator writing a long-form post in plain Markdown, converting it client-side, and pasting into the Bluesky web app (or any compatible ATProto client - Ivory, Bluesky Social iOS, Deck, Blacksky). The pattern is the same regardless of which client app the creator uses.

The Markdown source the creator wrote in their editor:

# Why we moved our Bluesky archive to Eurosky

Three reasons drove the decision in our last team sync:

- **Provider concentration risk.** bsky.social is the default PDS for most accounts, and a single company's terms-of-service change can lose the whole history.
- **Audit pressure.** EU organizations with GDPR scoping prefer an EU-hosted PDS for the data-residency argument.
- **Generous write API quotas.** Eurosky removes the gated approval bsky.social uses.

The protocol makes the migration trivial: export from
one PDS, import to another, redirect the handle. The
post body format does not change - the same ATProto
Facets survive the move.

If your team publishes on Bluesky and you have not
asked "what happens if this provider changes terms
tomorrow?" - ask it.

That source goes through a client-side converter. The converter walks the Markdown structure, emits the ATProto Facet array the protocol expects, and puts the rich-text payload on the clipboard:

# clip.txt - rich-text payload for ATProto long-form
{
  "$type": "app.bsky.embed.record",
  "record": {
    "$type": "app.bsky.richtext.facet#text",
    "text": "Why we moved our Bluesky archive to Eurosky\n\nThree reasons drove the decision in our last team sync:\n\n- Provider concentration risk. bsky.social is the default PDS for most accounts, and a single company's terms-of-service change can lose the whole history.\n- Audit pressure. EU organizations with GDPR scoping prefer an EU-hosted PDS for the data-residency argument.\n- Generous write API quotas. Eurosky removes the gated approval bsky.social uses.\n\nThe protocol makes the migration trivial: export from one PDS, import to another, redirect the handle. The post body format does not change - the same ATProto Facets survive the move.\n\nIf your team publishes on Bluesky and you have not asked \"what happens if this provider changes terms tomorrow?\" - ask it.",
    "facets": [
      { "index": { "byteStart": 0, "byteEnd": 50 }, "features": [{ "$type": "app.bsky.richtext.facet#bold" }] }
    ]
  }
}

The creator pastes that payload into the Bluesky composer (or any ATProto client that accepts long-form drafts) and publishes. The post lands on bsky.social, Eurosky, Blacksky, and any other PDS that has federated with the origin - identical rendering on each. The Markdown source, the local file the converter read, and the clipboard payload never touched a third-party server.

Self-Hosting a PDS vs Hosted: The Cost-Benefit in 2026

The PDS portability model invites the obvious follow-up: should a creator self-host the PDS instead of trusting bsky.social, Eurosky, or any hosted provider? The honest answer in 2026 is "only if you already run the infrastructure for other reasons."

A working self-hosted PDS needs: a stable VPS (the ATProto team recommends 2 vCPU, 4 GB RAM minimum for a personal account with a few thousand followers), a domain name, a reverse proxy with TLS termination, daily backups of the PDS storage directory, and ongoing patching as the ATProto reference implementation releases updates roughly every two weeks. Outage on your PDS means your handle resolves to nothing until you bring it back up - which feels different from "Bluesky is down" because you own the responsibility.

The marginal sovereignty gain over a hosted PDS is real but narrow. A hosted PDS provider like Eurosky or Blacksky handles operations for free or a flat $5/month. They are subject to the same GDPR and operational scrutiny as any EU-hosted service. The realistic threat model for most creators is "the provider disappears or changes terms," and a monthly archive export committed to a private Git repo handles that threat whether the PDS is self-hosted or not.

The middle path is the practical recommendation for 2026: keep the account on a hosted PDS you trust, export the post archive monthly, commit the export to a private Git repo you control. That gives you most of the sovereignty upside without any of the operational burden of running a PDS. When the next migration story hits the front page of Hacker News, you have the data to participate in it.

Where md2rich Fits in a Federated Markdown Workflow

The federated Markdown workflow for a content creator in 2026 has four steps:

1. Draft in the editor of choice - Obsidian, iA Writer, VS Code, Vim, plain Notepad. The editor picks Markdown for storage, the creator does not care which.
2. Convert client-side - the Markdown source goes through a browser-based converter (md2rich or similar) and exits as the destination protocol's rich-text payload. No upload, no model, no API key, no registration.
3. Copy the formatted payload to clipboard - the destination payload is a single text/html or rich-text paste that the destination client app accepts on first paste.
4. Paste and publish from the chosen client - Bluesky web, Ivory iOS, Deck, the Mastodon web composer, LinkedIn's post editor, Medium's importer, X Articles. Each destination app sanitizes the paste differently, but the converter output is already aligned to that destination's schema.

md2rich handles step 2 in the browser. The conversion is deterministic (the same Markdown produces the same payload every time), does not touch a backend (no API call, no LLM, no analytics), and is publishable to any destination that accepts a paste. For a creator publishing to multiple destinations from one Markdown source - say, a long-form post on Bluesky plus a tweet thread on X plus a Medium import plus a LinkedIn share - the converter is the only piece of the pipeline that runs once and works in all four places.

The relevance to ATProto specifically is that the conversion step is independent of which PDS the account lives on. The same client-side conversion works for bsky.social, Eurosky, Blacksky, PinkSea, self-hosted, or whatever the next 2026 provider turns out to be. The provider choice is a hosting decision. The conversion choice is a creator decision. Keeping them separate is the practical move.

Cross-Protocol Publishing: ATProto, ActivityPub, X Articles, LinkedIn

The federated landscape gives creators options that the centralized platforms do not. The interesting constraint is that the rich-text schema differs across protocols, which means the same Markdown source needs slightly different conversion for each destination:

Destination	Protocol	Markdown support	Paste path
Bluesky long-form	ATProto	Headings, lists, bold/italic, code, links	Convert to Facet array, paste rich-text
Mastodon (ActivityPub)	ActivityPub	Server-side parsing; nearly all Markdown	Type Markdown directly into the composer
X Articles	Proprietary	Import from Markdown file or paste rich-text	Convert locally, paste into the long-form composer
LinkedIn	Proprietary	No fenced code blocks; otherwise limited	Convert locally, paste; verify code blocks survive
Medium	Proprietary	Most permissive - tables, code, all headings	Import from .md file is cleanest
Substack	Proprietary	Subset of Markdown via rich-text paste	Convert locally, paste into the editor

The takeaway is not "every destination needs Markdown support" - it is "every destination needs a paste-aware conversion pipeline." A generic Markdown sanitizer does not produce that pipeline; a destination-aware client-side converter does. The 2026 version of the creator's stack treats the Markdown source as the canonical artifact and the conversion step as the per-destination adapter. ATProto is one of the friendlier destinations because the Facet schema is well-documented and consistent across PDS providers.

What the Next Six Months Look Like

The Eurosky migration is the first wave. The second wave, which is already visible in the ATProto development Discord and the Bluesky public roadmap, is feature parity across PDS providers - things like custom feeds, list management, email relay, and moderation policies that should not depend on which provider hosts the account. The third wave is the harder problem: giving creators tools to publish once to multiple protocols (ATProto + ActivityPub + proprietary platforms) without per-destination re-authoring.

Markdown is the natural common format for that future. It is the editor-side input, the readable source archive, the diff-friendly artifact, and the only format that survives a paste into every destination with a sensible subset intact. The missing piece is a conversion pipeline that is destination-aware, client-side, and archival-quality. That is the role the converter layer (md2rich and a small set of similar tools) is filling in 2026.

For a creator who has been drafting in Markdown for years and pasting into one destination at a time, the practical advice is unchanged: keep the Markdown as the source of truth, keep the conversion step out of any destination's pipeline, and treat the PDS provider as a hosting decision rather than a writing-environment decision. The federated world does not require new tools - it rewards the discipline of keeping each step of the pipeline independent.