Context

A group convened in person at Atmosphere Conf 2026 to discuss updates to the standard site spec. All new fields discussed would be optional, and no breaking changes would be introduced.

TLDR

• Fields to add

  • Links

  • Recommend

  • Contributors

  • Self Labels

• Fields that require more thinking

  • Analytic/View tracking

  • Langauges

• Fields discussed and passed over for now

  • Comments

  • Mentions and Quotes

  • Corrections and Community Notes

  • Platform/Generator

  • Payments and CTA's

  • Better Tags and Categories

• Other things

  • Better docs for content

  • Bring current fields up to date with Open Graph

  • Generally agreed to meet again next year

Links Array

We will add Links. It will be an array of objects containing a type, NSID/URI, and optional other data

• This would be a generic way to achieve lots of different use cases

  • pulling backlinks out of formatted content, indexing links in general, CTAs, linking across blobs if the post is too long to fit into one, linking to Open Graph data, etc.

Reactions

We will add "recommend" that is functionally a simple "like". It is up to platform render it as they like. We won't do a more generic "reaction" right now but will wait to see if/how platforms implement something like that.

• Emoji/enum reactions vs simple like

  • Only one like makes it easier to ecosystem to build tooling (like recommendations) on top of it

  • One option might be to have both

    • A more default "like" with more optional "react" that doesn't affect recommendations as much

    • However, it is already possible to do this at the platform level without encoding it into the shared lexicon, so this is overkill

    • We can wait and see how platforms implement a reaction lexicon before adopting it into the spec.

• Recommend language

  • Rather than call this thing a "like", we will call it "recommend" because it directly implies what is actually happening when you do this action

  • It is also more intentional action than a "like"

  • However, individual platforms can call this whatever they like in their own UIs

• Should we also add a "deboost" or "downvote" sort of reaction

  • It seems useful and not immediately harmful but recommendation systems are delicate and there is not pressing need to include it.

  • We will leave it out for now, and wait to see if/how others implement a system like this

Contributors

We will add contributors. It will be an array of objects containing a did, an optional role, and and optional display name.

We still need to explore whether or not is necessary to bake in a consent system for accepting authorship in a record attributed to you.

• It needs to be possible to attribute a post in a pds to some other did (in cases like work for hire).

• Publications should decide their own goverance

  • Valid options for contribution governance are too varied to be baked into the spec

  • ie, perhaps authors would rather keep their own work in their own pds anyway, with publications pulling it in. Perhaps its better for both parties to keep separate copies of the post.

  • in the case of multiple authors, it perhaps makes sense to create a new group did

• Consent / Accepting attribution

  • It may be useful/necessary for there to be a native consent mechanism so that authors can verify that an attribution is legitimate

  • This introduces significant friction both to the attribution process and for platforms implementing attribution flows. If it is added to the spec it would need to be optional

• Could this be approximated by the Links array?

  • Yes, but being top level is useful. Lots of platforms and publications need this information

New Preview Modalities

We will bring the spec up to parity with the Open Graph Standard. Other newer modalities can be explored later as platforms implement them.

• It would be interesting to open up new media types in the rendered links to a post in readers

  • Open Graph does support many things, and we should at least be up to date with that standard.

• Great use of the Links array

  • Link the media in the array

Content

We will improve our docs so that there are some simple suggestions for formatting the content field (like linking to a markdown converter)

• Should we recommend/enforce a format so that readers can pull content more easily

  • no, we gain a lot from a fluid content field including dramatically easier adoption.

  • however, we can recommend some sort of thing in our docs to suggest an unenforced format for content

Self Labels

We will add self labels. It mirror the way that Bluesky and Pckt current do this.

• This would be for tags like NSFW and other content warnings

• Labelers do somewhat handle this, but its insufficient

Analytics

We will write a more concrete proposal to shop it around the ecosystem before making a decision.

• It would be useful to have some solution for analytics to collect view numbers, etc

• It would be dicey to publish read records to a reader's pds, even if it's opt out. We'd rather not get into hardcore tracking and the slope is slippery.

• Maybe we can have an XRPC endpoint for publishers and platforms to opt in and collect view numbers?

• Something to aggregate stats even if the post content is rendered inside of a reader (rather than at the original site) would be useful to publishers and recommend algorithms.

Language

We need to do more research here. Perhaps we should put out a RFP for someone more informed than we are.

• It would be very useful to filter by language

• This is actually much more complicated than it seems.

  • Multiple standards exist but none of them are perfect

Comments

We will wait on comments for now.

• Formats for comments vary wildly. We don't have enough information to make a good decision

• Comments can become quite complex, including comments will blow up the spec

• Platforms can implement comments on their own anyway, so we can wait and see what others implement before moving on a standard

Mentions/Quotes

We will wait on mentions and quotes for now.

• Many apps have an implementation for this currently

• However targeting parts of a post in which the content format is not common in type is difficult

Corrections/Community Notes

We will wait on corrections or community notes for now.

• It seems useful for moderation and community building

• Labelers and other lexicons exist (like margin) to handle this.

• It's a difficult lexicon to write

Generator (Platform)

We will wait on generator or platform for now.

• This would include the platform that the post was created on

• It is useful for platform discovery and virility, and was a boon for older platforms like twitter in the early days

• However, it's possible to roughly tell what platform a post was generated on by looking at the content lexicon

• It would also be a frictional experience for publications that are non-native to the atmosphere

• Its pretty low risk, but it's not a pattern we've seen emerging, and we don't know how people would use it.

Payments / Optional CTAs

We will not add this, as it can be achieved via the Links field.

• Would be useful for the ecosystem economy

• Just a link button that send the reader to a place of the author's choosing

• If it's just a link, it can be done in the links array

Tags and Categories

We will not include anything new for tags. Our current implementation is sufficient for now.

• Our current tag implementation is very basic, and people use it both for global tags and for internal organization.

• We could introduce a new "internal" tag field

• But its not really necessary right now

Other Things Discussed

• Standard Site Governance

  • We generally agree to meet annually to discuss updates to the spec. It doesn't need to be in person however, and subsequent meetings will likely be online.

  • No formal processes for decision making as of yet

  • For now, we are a small enough group that this should be sufficient