I thought it would be fun to mark my personal blog as a standard site publication. It's statically generated, so I was just going to add the well known file and manually update my PDS records.
Initially, I thought just adding
at://did:plc:6e7msnu5o3mdboitzv7oxbxm/site.standard.publication/self
would be a good choice, but I realised that the spec says I should use a timestamp for the key.
Why does my publication need to record what time it was created?
I've been thinking this thru as a well, and while I'm not sure a timestamp id is the best solution, I actually think it might have some unexpected benefits.
If I'm thinking of exposing a public url for a standard.site.document, it's already effectively provided me with a unique(ish) identifier with the .path
Now imagine I update the content.
My new record has the same .path, but a different rkey and different timestamp. So if I'm rebuilding the site, I know which is newer, and can either only display the correct link or give people the option to "view history" by looking at previous records.
Initially I felt I would want a key to match the path, until I realized that the timestamp gives me this additional feature "for free".
Now let's flip it around:
Imagine I'm migrating / publishing content to standard.site from a "non-standard" source.
If I have a final url where content might lie, I can look at my own feed to see if that content has already been published. If it has not been published, I can then publish it. If it already has been published, I can check if it changes (and, if it has, I can update it).
Once again, the ability to have multiple "keys" for a given url is helpful, because it gives me a revision history (and can help me avoid "spamming" at proto when migrating/syncing/publishing content).
And so I've come around to believing that tid is really the right rkey.
This is just me sharing my thoughts on this issue; please let me know if those thoughts make sense and if you have any additional thoughts to share.
Why does my publication need to record what time it was created?
This is helpful information to provide to tools like readers and other aggregators, and is generally the suggested format for rkeys in atproto, (see @seth.computer's comment). But you should simply be able to omit the rkey during record creation to get at protocol to create it for you. We tend to avoid implementing things that require some computation on the creation/consuming sides where it makes sense.