Look up existing post link rel="site.standard.document" hrefs
So turns out document rkeys having to be TIDs is really annoying for us. Because the blog owner has to add `<link rel="site.standard.document" href="<aturi>" /> with the correct aturi in it, and it contains the rkey, and the rkey has to be a TID, it means either we generate it and the blog owner then has to copy paste and redeploy their blog, or we use a deterministic TID implementation based on eg post publish date, which means they have to use the exact same one. We just can't generate the rkey for the user.
It would be much easier if standard.site allowed other rkeys, so that you could eg use the RSS feed post guid. That would make it trivial, blog owner uses their guid (eg slug) and we do the same.
Of course, all this led to me realizing that the cleanest way to build this is to rely on the blow owner to set the link aturi and we just use that. So the blog owner generates a TID when they post their blog post, eg deterministically from publishing date, but we don't have to match the exact implementation of the algorithm, or they just get a random one and store it on their side. They can deploy once and we discover the aturi from the post.
Problem solved!