lexicon feedback #1

overall I think this is great! some quick notes from a skim of the lexicon. these aren't intended to be normative, just conversational:

feels like "title" and "content" should be required; and maybe "publishedAt"
seems like the rkey has mostly been TID syntax, not "any"
we have had a semi-norm of createdAt for timestamps; but I like publishedAt in this situation and would stick with it
an optional "description" field might be good, with a long-ish limit (2000 graphemes?). an example use-case would be RSS feeds, summary pages, and search indexing. also embedding and social cards
#hashtags
I don't love the field name content for any of the blobs, but maybe that is just me. I would have done text for the main record field, and data or file or blob or media in attachment
the mimetype restriction on the main text blob could be text/* for flexibility? we don't have a norm/guidance but i'd be kind of tempted to append that to the existing values; that would make the existing values something like "known values you could consider" as a hint (that kind of hint could also go in the description)

some other thoughts:

personally I like it when blog URLs are like /2025/07/title-slug. I guess with "any" rkey, the actual rkey could be "2025-07-title-slug" and be unfolded? maybe there are also some hacks where a TID rkey can be parsed to extract a year. maybe none of these cases are good though, and publishedAt and is used, so the year/etc can be updated after the fact w/o breaking AT-URI refs
seems tempting to me to add a "filename" string filed on attachments, required; and use that both in URLs and for references between the main text (eg markdown img refs) to the specific blob. instead of CIDs, which will change if you crop or transcode image files (for example). a bit unfortunate we can't do key/value maps in lexicon (yet), otherwise it could be an object with the filename as key