How to convert at:://
URI to https://
URL?
#2523
-
Hi, After creating a record, we get a |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
I'll give a pragmatic answer below, but first a protocol philosophy framing question: does it even make sense for there to be a "canonical" web (HTTPS) URL for record AT URIs? atproto URIs have the "authority" section scoped to an individual account (DID or handle), intentionally not scoped to a service (eg, web server), because the hosting location for the account could change over time. We don't want to over-centralize and have any one server or service be the "official" location for content in the network. One way to relax this would be to say that individual accounts do have a canonical host at any time, such as the handle or PDS host, and we could resolve AT-URIs to one of those locations to be redirected. That is nicely principled, but requires extra work by the account, and application-aware routing or display logic. Another mechanism would be to assign relatively canonical service hostnames for specific NSIDs (aka, record schemas or collections). We could say that https://bsky.app is the pseudo-canonical host service for the Pragmatically, today, if you have a bluesky post record and want to view it on the web, you probably want to link to https://bsky.app: it is the pseudo-canonical host for that content. The process is usually to look at the AT URI authority (DID), collection, and rkey segments:
Match on the collection: if it is
|
Beta Was this translation helpful? Give feedback.
-
Thanks for this deep and complete answer! |
Beta Was this translation helpful? Give feedback.
I'll give a pragmatic answer below, but first a protocol philosophy framing question: does it even make sense for there to be a "canonical" web (HTTPS) URL for record AT URIs? atproto URIs have the "authority" section scoped to an individual account (DID or handle), intentionally not scoped to a service (eg, web server), because the hosting location for the account could change over time. We don't want to over-centralize and have any one server or service be the "official" location for content in the network.
One way to relax this would be to say that individual accounts do have a canonical host at any time, such as the handle or PDS host, and we could resolve AT-URIs to one of those loca…