How flexible are record keys/PDS paths? #844
-
Hey Bluesky team! Are you all parsing or otherwise validating record key paths against any specific format? https://atproto.com/guides/data-repos#identifier-types says they should be based on TIDs, Thanks in advance! Somewhat related: |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 3 replies
-
Rkey is left intentionally flexible. You can see in many of the record lexicons, they declare their key type. We only have two supported key types right now:
Additional rkey semantics are possible & supported, however I'd encourage you to think twice before doing so. Do you have anything in particular in mind? TIDs are useful because they order collection contents by rough creation time. When syncing some slice of a repository, it is likely that you'll be doing so based on time & this allows creates smaller aggregate proofs. An example of this is follows. Wouldn't it make sense to key them by did of the account that you're following? |
Beta Was this translation helpful? Give feedback.
-
Thanks! This is very helpful.
Yes! I'm currently working on adding Bluesky federation (jumping the gun, I know, apologies!) to https://fed.brid.gy/, which is a bridge to/from IndieWeb sites. This means it won't be a standard PDS; instead, it's adapting posts and other user interactions from their existing authoritative sources elsewhere, specifically users' web sites. That means those posts already have canonical ids: their http URLs. I can definitely mint TIDs and make compatible rkeys and store the mapping, and that layer of indirection may be useful regardless, but I was just curious whether I could drop in their full (encoded) URLs as rkeys. Sounds like the answer is...not right now, and possible but not likely in the future. Totally ok! |
Beta Was this translation helpful? Give feedback.
-
This is pretty well covered in the specs now: https://atproto.com/specs/record-key Going to close as outdated, but feel free to re-open if you disagree... or if you think the spec should be different. |
Beta Was this translation helpful? Give feedback.
Rkey is left intentionally flexible. You can see in many of the record lexicons, they declare their key type. We only have two supported key types right now:
tid
(for most collections)literal:self
(for collections that should only have one record in them)Additional rkey semantics are possible & supported, however I'd encourage you to think twice before doing so. Do you have anything in particular in mind?
TIDs are useful because they order collection contents by rough creation time. When syncing some slice of a repository, it is likely that you'll be doing so based on time & this allows creates smaller aggregate proofs.
An example of this is follows. Wouldn't it make sense to key them…