Is TID the best choice for rkeys? #7

It appears this is just the recommended rkey for most things. I agree though, this being a standard, perhaps any as the rkey type makes more sense.

Wondering if there are implications in how standard.site documents are aggregated by clients that might impact rkey choice though. Do we have enough insight from some of the existing clients supporting the standard that might inform this?

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.

self should only be used when it is expected to be the only record in the collection. See: https://atproto.com/specs/record-key#record-key-type-literal-value

TIDs are the most commonly used rkeys.