As the ATProtocol network of applications expands, we as developers are going to need to start to come to a consensus on some more lexicons. Even though the barrier for introducing new datatypes into the Atmosphere, there's going to be a lot of benefit in having some standard shapes that we work with for certain datatypes.

Standard Site

This is the first of such cases in the Atmosphere to standardize some kind of datatype across the Atmosphere. Standard Site formalizes the data model behind the ownership and federation of, usually, blog content. Publication records define the ownership of a publication, subscription records define the ownership of a subscription license (even if that license is free), and document records define which publication owns them.

Extensibility of Standard Site

One of the important features of site.standard.document lexicon is the content field within the record, which allows any kind of structured data within it. This means that implementers are free to define the content themselves while standardizing on ownership and federation models. While it creates more implementation overhead both for publishing and reading applications, this extensibility allows for the competition of certain content features within each application.

Structured Data Fallbacks

For compatibility, there's also the convention to store the full text of a site.standard.document record in a textContent field. This allows for tools to work outside of the structured content if they aren't able to consume the lexicons that are defined within the content field.

Applying This Elsewhere

There are many different data primitives that would also benefit from this interoperable, consensus-based standard for lexicons across the internet. Productivity datatypes like calendar events, emails, tasks, and notes could all be implemented in the same kind of way, allowing for different implementations of the records.

Examples: Skej and Atelier Calendar

As an example, I'll discuss how calendar events would benefit my own applications. Skej is a social media management tool released in alpha that allows users to schedule posts to their PDS using at.skej.schedule records and a worker fetches the records and creates an app.bsky.feed.post record for the post at the specified time. One of the extended features that's currently in development is a content calendar for a high-level view of the upcoming posts in the pipeline for the target account.

While this works for users within Skej to keep tabs on the content pipeline, it doesn't help product managers who might not be in the weeds on the actual post content that's coming out but would still like to be able to know what's coming down the road. Atelier Calendar is a conceptual calendar application I'm designing that would be able to consume the calendar records written by Skej for non-marketing users to keep up with the schedule.

How Will These Bodies Form

Right now, we're in the wild west of lexicon schemas, but as the Atmosphere matures, we'll likely start to see these standards bodies working together to design the shape for ownership and federation of various different data primitives across the internet. Trying to build these from the top down is only going to cause problems, so our best course of action is to let them form naturally. Creators of competing lexicons shouldn't be too precious with the data model they've designed, but should be willing to explore working with other creators to implement a shared shape. Like how site.standard.document records don't strictly define the content field to allow for publishing tools to extend the lexicon in a way that best fits their own needs, other lexicons formed this way should not be overly prescriptive with content, but define a generic shape that can be extended to the needs of the individual implementers.