Oh yes, I’ve seen the preference around! And to clarify: sidecar records have their uses (allegedly), my main concerns with them are the above.
Overall, the lack of discoverability hurts less when your Lexicons are visible/known in the ecosystem, because people are more likely to be aware of them and look them up. So—no shade, I swear!—it’s easier to prefer them from Bluesky PBC’s vantage point.
In this case I’m not worried about discoverability (this is likely to be popular), but I’m more concerned with the second point (how to find them).
Speaking of which:
Finding Sidecars
So this may be me misunderstanding something, but assume I have two 2 collections:
place.stream.livestreamapp.bsky.feed.post
I (will) have pages on my website for both of them, but there’s no guarantee of these records having a unique tid (ironically, also because of sidecar lexicons):
The same TID may be used for records in different collections in the same repository. This usually indicates some relationship between the two records (eg, a “sidecar” extension record).
So, even knowing the tid, I cannot be sure which of the two records a community.lexicon.link is associated with, or how I’d deal if both needed theirs. To your point, this is worse when record keys are not tids. Even more, the link is easily lost if the original record is given a new key.
If we think this is an acceptable risk, that’s fine—I mostly want to make sure we discuss it.
“Well-known” Fields
To clarify, what I’m suggesting is not “custom fields” per se. I suggest we define:
- A “standardized” field with a defined meaning
- Namespaced to a specific lexicon
- Whose value conforms to that Lexicon
So building on your example, we would have:
{
"textContent": "the content of the record",
// ....
"community.lexicon.links": [
{
$type: "community.lexicon.links#link"
"href": "....",
"rel": "canonical"
},
{
$type: "community.lexicon.links#link"
"href": "....",
"rel": "alternate"
}
// ...
]
],
"postedAt": "01-01-2027",
// ....
// ...more record data...
}
Then you can resolvecommunity.lexicon.links and find:
{
"lexicon": 1,
"id": "community.lexicon.links",
"defs": {
"main": {
"type": "array",
"description": "Links to related versions of the containing record. Intended for the community.lexicon.links field.",
"items": {
"type": "union",
"refs": ["#link"]
}
},
"link": {
"type": "object",
"required": ["href", "rel"],
"properties": {
"href": {
"type": "string",
"format": "uri"
},
"rel": {
"type": "string",
"knownValues": ["alternate", "canonical", "author"]
},
"mediaType": {
"type": "string"
}
}
}
}
}
…so that’s, well, “kinda custom”, but it still has a defined meaning you can pull up if you meet it in the wild.
There’s a couple of different trade offs here too, of course (e.g. you need record-editing powers to update the URL). But still! I will open a thread on this later cause I’m interested in the pattern regardless.