Add AT URIs as alternate links #172
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
2 Skipped Deployments
|
WillCorrigan
approved these changes
Oct 26, 2024
This was referenced Oct 26, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm trying to start a convention that allows tooling (eg. crawlers, browsers, extensions) to link the web representation of a record to it's canonical
at://URI. I see no better way to try this than to start doing it in frontpage and atproto browser.There are multiple representations of the same URI on atproto, due to the authority section being either a handle or a DID. My recommendation is to prefer the DID-based representation, but including the handle is valid also.
Important
The convention I've landed on is
<link rel="alternate" href="<AT URI>">. Note: notypeattribute because specifying one doesn't really make sense, it's up to whatever tooling that is consuming these URIs to decide how to fetch the record.In the future we can potentially pickup on these URIs when submitting links to Frontpage to maintain a reference to the record on the protocol.
Some examples of the links in this PR:
at://did:plc:2xau7wbgdq4phuou2ypwuen7at://did:plc:2xau7wbgdq4phuou2ypwuen7/fyi.unravel.frontpage.post/3l7dwhqjru623at://did:plc:2xau7wbgdq4phuou2ypwuen7/fyi.unravel.frontpage.comment/3l7bzyhx3ry2rat://tom.frontpage.teamat://did:plc:2xau7wbgdq4phuou2ypwuen7/app.bsky.feed.post/3l7emhqdj6f2sNote, the mapping is slightly different between the two apps. For Frontpage I've chosen to always show a DID but on atproto-browser I've preserved the handle where relevant because it matches the intent of the application.