Post

On the first two points I believe the team is planning to fix the TID constraint and move to at-tags!

I didn’t fully follow the point you were making about backlinking though, was wondering if you could expand on that? What does the content field have to do with discoverability via backlinking?

Constellation reads records that come through and check them for URLs. If the document content field contains URLs, it means it can record backlinks from the document to other records. So that's discoverability via backlinking! Not of the record itself, but of other things

For back links, we plan to add a proper `links` array for interoperable linking and data without having to standardize content shape

"Putting your content on the protocol, making it public and accessible, is at odds with bringing visitors to your site" yup.. this is something i wish people would take more seriously. we could call stansite a discovery lex and just leave it at that. forcing people to redirect to show the content

"we should remove the type restriction on record keys for documents and let people use what they want, including things like post slugs" we're planning on this. but one thing to remember, these rkeys need to be immutable. once set, they shouldnt be changed otherwise references break

Good writeup! I think there is a more radical approach to your last few points: remove the content field completely. Content should be authored in a separate record type and linked via a strongRef (or just a URI). Open unions are a bad approximation for generic types. Let the records be linked!