Clarifying non-use of #main suffix in $type fields

[bnewbold]

When atproto data references it's own schema in a $type field, there has been ambiguity about whether to include the #main suffix for the "main" definition within a Lexicon schema. Bluesky (the company) code and examples use just the NSID, and omit the suffix for this specific definition name. The specs hint that #main should not be used, but are not explicit, and Bluesky typescript reference code has not enforced this at record creation or validation time.

We want to clarify that #main "MUST NOT" be used in $type in atproto data (records, messages, requests, etc).

We are updating the specs to be clearer on this, and will soon enforce this in our validation code at the PDS, and downstream. Unfortunately there are some existing records that may become invalid as a result of this change.

@mozzius I think greysky may have been impacted by this at some point, for example an embed with "$type": "app.bsky.embed.external#main" back in October (2023). Our bad for not having defined and enforced behavior around this.

[mozzius]

Yep, my bad. Sorry about that.

I believe the reason I made this mistake was that at the time, social-app wasn't public yet, so I was pretty much just working off the @atproto/api source for what stuff should look like. The code for the typeguard functions looks like this:

export function isRecord(v: unknown): v is Record {
  return (
    isObj(v) &&
    hasProp(v, '$type') &&
    (v.$type === 'app.bsky.feed.post#main' || v.$type === 'app.bsky.feed.post')
  )
}

Hence the confusion. Sorry for all the invalid records 😅

[snarfed]

@bnewbold are you all still planning to add this validation to the PDS and appview? Looks like they still allow $type: ...#main in records, eg at://did:plc:k6acu4chiwkixvdedcmdgmal/app.bsky.feed.post/3lagdncjsu22y, posted today:

{
  "$type": "app.bsky.feed.post#main",
  "createdAt": "2024-11-08T08:18:49.096Z",
  "tags": [
    "tag1",
    "tag2"
  ],
  "text": "this post should have extra metadata"
}

[bnewbold]

Thanks for reporting!

Good test case for interop test suite 🤔.

@devinivy @dholms we should probably consider these invalid records at the data layer? And block their creation even if lexicon validation is disabled.