Generic atproto tools can approach arbitrary records in different ways. Exposing the raw record data directly is great for inspection and debugging, and PDSls-style tools are useful exactly for that reason.
Some tools, though, may want to present records in a more compact or viewer-friendly form. For example, records that use extension points such as app.bsky.embed may contain valid types that a client does not know how to render. Experiments such as Inlay seem to explore one side of this broader problem: defining views that can be applied to records. The question I’m interested in here is a related side of the problem: how a generic viewer discovers whether any record-type metadata or fallback hints exist, and where to find them.
There has already been related discussion around Lexicon embeds and renderer discovery. This thread is trying to look at one part of that space: how viewer-facing metadata would be published, discovered, and treated as authoritative, before getting too far into any particular payload format.
A small example
A tiny example payload could be a primary text hint.
For example, a sidecar metadata record might say that a post-like record should use its text field as compact fallback text:
{
"$type": "example.viewer.metadata",
"source": "com.example.post",
"items": [{
"$type": "example.viewer.metadata#field",
"field": "text"
}]
}
For an action-like or edge-like record, where there may be no useful standalone text field, it could instead provide a fixed label:
{
"$type": "example.viewer.metadata",
"source": "com.example.like",
"items": [{
"$type": "example.viewer.metadata#literal",
"text": "Like"
}]
}
The exact schema name and shape here are placeholders. This is only meant as a motivating example, not a concrete proposal.
The example is intentionally tiny. More expressive payload features, such as templates or reference hydration, seem like separate questions rather than something to settle here. Even if a rich view declaration is added, it will not have a significant impact on the discussion of discoverability. Just put the link.
Possible directions
Some possible places for this kind of metadata to live are:
- as fields embedded directly in records
- as annotations in Lexicon schemas
- as sidecar records in the Lexicon authority repository
- in viewer-local registries
- in community or third-party registries
- in AppView-specific responses
In my personal opinion, sidecar records using Lexicon resolution is the easiest way to achieve it.
Questions
I’d be interested in thoughts on these questions:
- Does this discovery problem seem real?
- Should first-party, community, and third-party metadata be explicitly distinguished?
- Are sidecar records a reasonable direction, or are there better patterns for this?
I’m not proposing a concrete schema here. I’m curious whether this framing makes sense, or whether there is a more natural way to think about the problem.