BREAKING: Stable frontpage lexicon

[tom-sherman]

Goals:

• Make room for different post types (future)
• Allow for richtext comments with embeds (future)
• Move the lexicon to the fyi.frontpage namespace

Changes

Post "subjects"

To allow for different post types in the future (eg. longform text, media, polls) we add a subject field to post. This is an open union with currently one defined value: a URL. The open union allows for non-breaking extension later.

Block-based comments

Comments are now made up of an array of blocks. For now a block can simply be a paragraph, but in the future could be an image, codeblock, etc. The paragraph that is supported is simply a string and matches the semantics of the old comment schema.

When we add richtext in the future it'll be heavily inspired by bluesky-social/atproto#2830 but likely defined in userspace. There'll be a new "richtext paragraph" block type to support this, with a Frontpage facet type that extends the Bluesky ones and adds our own union members.

Adding length constraints on longform block-based richtext content is tricky. We take the following approach:

• Max length on each individual block
• That same max length is also applied to all of the content. This is kind of intentionally unspecified (ie. up to the implementor ie. us), essentially acts as an additional constraint applied to the whole comment at the appview level
• Similarly a max record size, applied at the appview

Not being able to describe these constraints in the lexicon is unfortunate but I don't think there's a better way forward without compromising the user experience. Suggestions welcome!

fyi.frontpage namespace

Moves to the stable fyi.frontpage NSID. It's a good time to do this because the above changes are backwards incompatible (breaking).

Rollout

• Gather and implement any feedback
• Merge PR and publish lexicons to atproto using lexicon resolution
• Implement support for ingesting new lexicon in Frontpage AppView for testing
• 4 weeks after merging/publishing (TBC: is this long enough?) start creating records with the new lexicon

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
frontpage	Ready	Preview	Comment	Oct 4, 2025 9:18am

3 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
atproto-browser	Ignored	Preview		Oct 4, 2025 9:18am
frontpage-oauth-preview-client	Ignored	Preview		Oct 4, 2025 9:18am
unravel	Ignored	Preview		Oct 4, 2025 9:18am

[Copilot]

Copilot wasn't able to review any files in this pull request.

Files not reviewed (6)

• lexicons/fyi/frontpage/feed/comment.json: Language not supported
• lexicons/fyi/frontpage/feed/post.json: Language not supported
• lexicons/fyi/frontpage/feed/vote.json: Language not supported
• lexicons/fyi/frontpage/richtext/block.json: Language not supported
• lexicons/fyi/frontpage/richtext/facet.json: Language not supported
• lexicons/fyi/frontpage/subject/url.json: Language not supported

[ThisIsMissEm]

I'd suggest doing a block as being "some text, facets, and embeds (links, images)" or "embeds, blobs, or text with facets"

So you'd have a type link: fyi.frontpage.content_block which is a union of:

• fyi.frontpage.content_block.link
• fyi.frontpage.content_block.image
• fyi.frontpage.content_block.video
• fyi.frontpage.content_block.text

And fyi.frontpage.content_block.text would be made up of text and facets as properties.

Then for fyi.frontpage.feed.comment it has an array of fyi.frontpage.content_block as the blocks property or content property.

This gives you the ability to have rich text inline, but have video, images and link embeds be first-class alongside the text segments.

Edit: oh, and why content_block instead of block? To avoid confusion with an actual block type for like blocking someone. You could also remove the _block suffix. I probably wouldn't use richtext here since it's vastly different to another richtext lexicon, and richtext is likely needed for the "text" content block.

[ThisIsMissEm]

Maybe fyi.frontpage.richContent.* or something? If you want to be specific. Another word might be "contentFragment" or something

[ThisIsMissEm]

So maybe the key change would be to move:

{
  "type": "union",
  "refs": ["fyi.frontpage.richtext.block#plaintextParagraph"]
}

Out of the fyi.frontpage.feed.comment namespace and into fyi.frontpage.richtext such that it's reusable across your application and has a specific type, rather than an anonymous list of union

[ThisIsMissEm]

Is there a reason for the extra object here? Can't this be a union directly?

[tom-sherman]

I don't think so, at least lex-cli errors when you have a union at the top level of main. I'll verify that though.