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.

I have a few thoughts on this, and they add up to my support for a key type of any.

I also want to address some of the points above for TIDs. Up front I want to say that I think TIDs are great, and I certainly don't think we should prevent their usage. The question is what value they bring to the table here and whether they are a requirement/facility for the consumer side vs. the publisher side (which can always choose to use them). I will also outline a specific use case for the any key type. TLDR: using stable ids from existing publishing software opens some interesting doors to really simplify standard.site integrations.

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...

If readers and aggregators having a creation time is a requirement I think the best place for it would be a datetime field in the record itself. In addition to making it more codified/explicit, it would also be friendlier to these tools to hand them a date string in the data rather than a TID, which doesn't travel with the record and is a bit of a bespoke format to parse a date out of.

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).

That is really interesting. I think the value here is on the publisher side. If they key type is any publishers could still totally use TIDs like this! There's no interop issue here for general-purpose consumers.

But you should simply be able to omit the rkey during record creation to get at protocol to create it for you.

It is nice in some cases for the rkey to be created for you by the PDS, and I've heard this as a case against anything other than a TID key type. But you don't have to give that up with the any key type: the PDS will still generate a fresh TID for you if you don't specify an rkey.

And I think that brings me to the use case I'm interested in that doesn't work so neatly with TIDs. I believe it would be great for standard.site to be easy to adopt for long-time existing publications and publishing software. These are integration details that I think we can remove from the publisher side:

• Connect the user's Atmosphere account.
• Publish a record to the user's repository during their own article/document publish flow.
• Take the output of that (an at-uri) publish process and use it to place a new link tag in the head of the document.

I believe we can simplify the integration for documents down to:

• Place a link tag in the head of the document.

Downstream tooling, e.g. an app designed for managing standard.site publications, can detect that and automatically create a record with the given at-uri for you. The bulk of the integration is then hoisted out of the publication itself and into a general-purpose tool.

The reason TIDs are difficult here is because they need to be generated and stored on the publisher side. TIDs are a bespoke format relative to most existing software that also already has a stable identifier for their documents. It would be awesome if an integration could piggy-back the stable ids from these existing systems and look more like a simple template update:

<link rel="site.standard.document" href="at://did:plc:mydid/site.standard.document/{{post_id}}">

I believe this template-based approach to standard.site integration would work well with WordPress, Ghost, Hugo, Jekyll, Eleventy, and lots of older (and perhaps more... "custom") blogging software. And in turn bring standard.site further across the web!

Hi there! I'm the author of Mastro and that blog post. Sorry, for the trouble! I didn't realize TIDs were actually required by the schema, because site-validator.fly.dev didn't flag them, it works on Bluesky, and nowhere on https://standard.site does it even mention the word TID.

If you have a TID as an rkey, the proposed semantics (which not everybody will be aware of) are that this tells you what time the record was likely created, correct? But it doesn't tell you when the blog post itself was allegedly created, for which there's the document.publishedAt field. I cannot think of a possible use-case for the former, because you cannot rely on it anyway? Lots of people now syncing their existing blog with the Atmosphere, and the TIDs are all over the place: you cannot even rely on the order, because often people will first publish a trial record for their latest blog post (not the oldest), and then backfill the rest.

Conversely, deterministically deriving the rkey from an existing unique identifier (like a database ID or URL path) makes things a lot easier for a lot of existing setups. Especially static sites where you cannot just add another database column, but need to add a new commit to the repo to add more info, or alternatively have to fetch all existing records from the PDS whenever you generate the HTML for your blog in what seems like an unnecessary point of failure. (What do you mean I cannot build my static site because my PDS is down?!)

And from what I can tell, this is exactly what rkey type any was created for? From the official docs:

This may be used to encode semantics in the name, for example, a domain name, integer, or (transformed) AT URI. This enables de-duplication and known-URI lookups.

That's why from my perspective at least, it seems it would make a lot of sense to change the schema from type TID to type any. People that prefer TIDs can still use them (e.g. for versioning like @mrpowershell.com outlined above). But I haven't read anything in this thread about why requiring a TID would be advantageous? But perhaps I don't know enough how others consume these records? What specific interop issues are you thinking of?

Want to add another vote for loosening the type requirements for record keys, especially for documents. When I wrote a little script to publish my blog posts to atproto using standard.site, I did the same thing Mastro above did, I used the slugs as nice stable identifiers that let me deploy my website statically with the linked at-uri already in it and publish the doc without having to go back and forth.

I've even played around with building a little app that syncs your static blog to atproto using your RSS feed for discovery, but running into the same issue there. Having TIDs for record keys means the blog owner has to re-implement my deterministic TID function so they can add a matching link in the post, or to have to come back and update their post after the document is automatically created to add the link.

another vote for loosening the requirements around record keys

at Buttondown, we are currently adding standard.site integration to our app, likely making us the first non-atproto-native newsletter service to do so. and as an external integration, it would be a lot easier on us if we can make assumptions about atproto, standard.site and how its services behaves, one of which is determinism.

TID is the only non-deterministic factor standing between Buttondown and standard.site, right now we are inclined to hash the email's ID to get a deterministic TID that we can use.

just violate it and do slug as rkey anyway /shrug