made using Leaflet

Standard.site what's next!

Standard Site Working Group Meeting Notes 3/29/26


Context

Standard Site Working Group Meeting Notes 3/29/26


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

Fields discussed

all these are optional and there will be no breaking changes

Reactions

emojis? enums?

if there's only one reactions, then it would be much easier to build things like recommendations around it

maybe we could have a default "like" and optionally you can add more reactions that don't affect the recommendations

Distinct reactions lex and recommend lex?

It maybe makes sense to start with simple recommends

We can wait to see how a reader implements a lexicon for other reactions before we implement it ourselves

deboost?

seems useful and we don't see any explicit harm

but also who knows, we don't need to include it

We will do a recommend lexicon

up to platforms to render it.

We won't do a more generic reactions lex, and wait to see how others implement

Contributors

It needs to be possible to attribute a post in your pds to someone else (in cases like work for hire)

The governance would be specific to each publication

the publication will decide if they want all posts to be published in their own pds, or authors could keep their posts and publishers pull it

What happens if the publication and the author each keep a copy of the record in their pds

it shouldn't happen, if the publication chooses to mirror, that's a separate copy.

If there's are multiple authors, then there would need to be a group did

If you are attributed by a pub, optionally, there may be a consent lexicon on the author side that proves that the attributor wrote it

this introduces lots of friction in the form of an extra step for the author and another step for the implementation. It needs to be optional

Do we need this, or could it be approximated in links rel

It makes sense to put it top level, lots of docs need it

It makes the content signing easier at the publication level

What does it include

Minimum, a did or string? to attribute to someone else who is not on protocol

Optional metadata like display name

It should be top level

consent mechanisms seem useful and good, we need to explore if thats baked into the standard

a list of dids and roles, with optional display name

Preview Modalities

Different ways to render a post in readers, with for example a video rather than an OG image

a great use of the links array

the links array might be too broad for the reader to know which to display

we should at least have parity with the Open Graph Standard

Links array

relations with NSIDs and a type

A very generic way to achieve a bunch of things that we may want

the content can be a blob while still having backlinks

and we can shove CTA's, and make indexing links easier, link blobs if the docs blog is too big, etc etc etc

Could link also to the OpenGraph data

design q's

open ref union?

or maybe an array of objects that are open ref unions. The links need to be a uri and type at the very least

We're doing it

array of objects: type, uri, data

Contents

should we recommend a format? So that readers can pull them?

this can be solved for now just by putting out better docs

Comments

Formats vary wildly, and will likely blow up the scope of the spec, so we will table this for now, as we consider the best way forward

this will wait for now

Mentions/Quotes

Many apps are already using their own implementation so it would be good to include

however, targeting parts of content that isn't common in type is difficult to do

sounds hard, let's wait

Corrections/Community notes

celine didn't catch the notes for this part, she is sorry, could someone backfill?

sounds hard and other people are doing it, we wait

Generator field

It was useful in twitter when you saw a post and saw the platform that created it, it was great for discovery/virality

For an atmosphere blog, its possible to tell based on the lexicon, but it's not perfect

just a text string? maybe a did?

did makes it friction-ful for blogs that are non-native to the atmosphere.

maybe instead of being in the lexicon, maybe it's part of the validation step?

relatively low risk but we also don't know much about how people will use it, so let's wait on it for now

Payment / Optional CTA

to direct people to where the payments are being triggered

it's a button link that sends the user to a place of the publishers choosing

This does expose a lot of potential problems

this could potentially be done with the Links array

Analytics

Not published in the record, but an XRCP endpoint for publishers to opt in to collect view numbers

Maybe we don't need it? it would be better for the platform should just collect its own analytics

maybe we write a more concrete proposal and shop it around

Tags and Categories

the tags a pretty messy right now, and people use them personally rather than as a global category system

Maybe an internal tag field?

sounds out of scope

Self Labels

NSFW, Content warnings

We specify a top level property like the way bsky and pckt does it

Language

But this is very difficult and seems like no one has a good solution

actually it looks really complicated lol, let's do some research and maybe put out a call for proposals or help?