Farcaster Articles are made of ordinary casts. Here's the format.

By Kazani

Farcaster launched Articles this morning. The launch post says "Behind the scenes, an article is a chain of casts," and I wanted to check that. So I read the raw casts from one source on each of the two Farcaster networks. Then I published and deleted a throwaway article to see what happens when you change one.

The claim holds. An article is a set of ordinary casts, and at least one other app already reads them that way. farcaster.xyz also keeps its own copy, though, and a published article has no edit button.

How an article is stored

On 13 Nov I read the launch article's casts from two places. One was farcaster.xyz's own index, which follows Snapchain. The other was a free public Hypersnap node run by Quilibrium. Both returned the same two casts, with the same hashes and the same text, byte for byte.

Embeds are attached to a cast as a list, separate from its text. So the body marks where each embed goes with a line of its own:

(In the real cast, each `[$N]` sits alone on its line. I added the arrows here so this article's own embeds don't get swapped into the example.)

`[$1]` is the first embed on that cast and `[$2]` is the second. Headings, bold text, lists and tables are plain markdown in the text.

Any app can rebuild an article from that. Take the first line of cast 1 as the title and its image as the cover. Then add the text of each reply in the chain, and swap each `[$N]` line for embed N. farcaster.xyz's public website code reads articles the same way. It takes the title from the first line, and it drops the `[$N]` lines when it builds a plain-text preview.

The split isn't always a short preview plus a long body. My test article had two short lines of text and one embedded cast. Reading it from the Hypersnap node, cast 1 held the title and all the text, and cast 2 was a plain cast whose whole text was `[$1]`, carrying the embedded cast. farcaster.xyz's index agreed that the article had two casts. The cast type follows the length. In both articles I looked at, only the cover sat on cast 1, and the other embeds went on later casts. Two articles is a small sample, so treat that as a pattern, not a rule.

farcaster.xyz keeps its own copy

You write in farcaster.xyz's editor, which is web only for now, and it saves your draft on its own servers as you type. For the launch article, that saved copy was created about 31 minutes before publishing. At publish time farcaster.xyz turned it into casts, signed with its app key, within about a second.

The article page on farcaster.xyz is built from that saved copy, not from the casts. Usually the difference doesn't show. For the launch article, the copy and the casts matched.

Drafts stay private. I tried to read my own draft from a logged-out session, and later my own unpublished article. I couldn't read either one. Published articles are readable by anyone.

Other apps can rebuild it without farcaster.xyz

Quilcast is an open-source client on Hypersnap, and it shows the full launch article, with the title, cover, embedded cast, image and table. I watched which servers its page talked to. It used the Hypersnap node and Quilcast's own spam scorer, and nothing from farcaster.xyz. So on Hypersnap, the casts alone are enough to show an article.

Quilcast did file its own ticket to support Articles the same morning. An app without that support will show cast 1 as a normal cast with raw markdown, and the body as a reply under it.

Which network the casts came from

Farcaster now runs on two networks. Hypersnap, a community fork, went live around 12 Nov, and a relay copies messages between it and Snapchain. For the launch article, the casts themselves were identical on both. The Quilcast check is Hypersnap only, and the saved copy is farcaster.xyz's own. Casts posted only on Hypersnap may not reach Snapchain, so if you test this yourself, say which network you read.

Here's where apps stand, based on public casts and repos on 13 Nov. The list is incomplete. "Working" is the builders' own word, except for Quilcast, which I watched work.

A published article can be replaced, not edited

A published article has no edit button. Its menu offers copy link, duplicate, unpublish (which moves it back to drafts) and delete. So I published a throwaway two-cast article, unpublished it, changed one word in the draft and published it again. After each step I read the casts from farcaster.xyz's index (Snapchain) and the Hypersnap node.

What I saw:

The two copies stayed in step. But on the protocol, a republished article is a new post. Likes, recasts and replies point at one specific cast, and nothing moves them.

My test article had no likes or replies, so I looked at deleted casts I could find instead. On the Hypersnap node, 14 of them still list likes or replies, including other people's, and all of them point at a cast that no longer exists. On farcaster.xyz, a deleted cast's own page says "Cast not found." I opened four of the surviving replies. Three showed their parent as "This cast has been deleted," and the fourth, from an account with no username, didn't load at all. I'd expect the same for an article's old casts after a republish. I haven't watched it happen to an article, though, and I only tested a tiny two-cast one.

After the delete, the old casts were gone everywhere I could look without an API key. I checked the Hypersnap node that Quilcast and several other Hypersnap apps read from, farcaster.xyz's index, farcaster.xyz's own page ("Cast not found") and Quilcast. Gone from those places isn't the same as gone everywhere. The other nodes I found are private or paid, I found no free public Snapchain node, and any app or indexer that saved the text before the delete can still have it.

So preview the article and read it twice before you publish. If you must fix something, do it in the first few minutes.

For builders

If your client doesn't show Articles yet, the job is small. The first line of cast 1 is the title, and its image is the cover. Follow the replies, swap `[$N]` for the embeds, and render the markdown with a renderer that blocks raw HTML.

I write about AI security and how systems work under the hood. My work is at kazani.pages.dev.

Drafted and edited with Claude from tests I ran on my own account. I chose what to claim and reviewed the final text.