I saw it more as “alternate representations of the content on this page”. MDN says of canonical:
Preferred URL for the current document.
So at:canonical would be like “the preferred AtURI when referring to this page”. The “if you gotta choose one, this is the most appropriate”.
Alternate is:
Alternate representations of the current document.
So this is other AtURIs the current document could represent. Imagine for example a page that has a blog post but the website (or post) is also about a certain event. You could use at:alternate to indicate that the page is also representing an event. It doesn’t say too much about what the relationship is, but it gives a hint. If you drop that page in a event viewer, it can choose to use the hint to e.g. let you RSVP.
Making a at:publication (or at:standard.site:publication) still remains open as future extensions! People may try to use the more precise type if/when one exists, but it’s good to have a generic fallback so there isn’t an explosion of types just because. The ecosystem already ““knows”” (or is trying to figure out) how to handle NSIDs, and this is a way to help them find them by looking up simple properties. Then it may also help add more precise context where there’s available grammar (e.g. me vs author) not representable in the record itself.
I don’t think we should hurry into a bunch of namespaces/properties that we don’t have a discoverability or grammar history for, especially when they just duplicate existing info. It doesn’t feel impossibly harder to aggregate at:alternate and get the NSID (and we can add data- properties to help), but it will spare us a lot of chaos and confusion in the future.
You can try to mandate one, but I think the history of the web shows “people will be people and there’s a vested interest in being accommodating”. The old software adage “be liberal on what you accept but precise in what you return” comes to mind: there should be The Preferred Format™ (I’m for consistency, so all with at://), but enforcement may be less strict.
I’ll add another +1 liking the at:canonical and at:alternate proposals, but I think that current usage I’ve seen of the site.standard.document property in link tags is intentionally different.
I agree with how you’ve defined canonical and alternate, which is representative of the historical usage beyond atproto. I expect that some services will interpret both of those as indications that instead of sending a user to that page, they should direct the user to a rendering (either within that service or on another app) of the atproto content. This is a great flow when the lexicons can be natively supported, and is currently how bsky.app links (who’s pages set the alternate link tag) are handled in mu.social - it just opens mu.socials rendering of that page rather than sending the user to the actual page linked.
But I’ve also seen many blogs use this alternate meta tag, and I’m not sure if they would be expecting mu.social to do the same thing if mu.social started natively supporting rendering this site.standard.document lexicon. Especially with the current state of analytics in atproto, the author get’s something tangibly different depending on where the content is consumed. So I think we still need another “base” property (e.g, at:related) to indicate the connection to the post (validating 2-way linking, etc) without impacting user flow. We could say then they should continue to use the lexicon as the property (like is done now with site.standard.document), but I think there is value in having a unified cross-lexicon version.
Close to finishing a draft of this community protocol and a small reference implementation/test suite. In the mean time I did stumble upon some more history about this topic:
older discussion about a atprotocol:creator property. semble is using tag <meta name="atprotocol:creator" content="at://did:plc:bnqkww7bjxaacajzvu5gswdf">
Frontpage is also adding<link rel=”alternate”> with at URIs.
I want to second my strong interest in element tagging, which I admit is somewhat out of scope, but also, it seems like this is such an elegant way to get both!
I filed at-tags#1 before seeing the discussion here.
Just wanted to voice support for this. I’m building an AT Protocol native link aggregator and I’d like to support users dropping in a link to any app.bsky.feed.post record, regardless of web UI, and have it render as a post rather than as a link.
Right now it’s exceptionally hard to do that, it doesn’t really seem like there’s a way to sniff any platform except for Blacksky. I can hack it with Bluesky but it’s not ideal.
I’m planning to update the draft to use the standard name attribute, rather than the non-standard property attribute that Open Graph uses. The WHATWG considers OG tags an incomplete proposal because of this. I checked in with the HTML standard and I don’t think there are any concerns of collisions, nor has anyone claimed the at: namespace yet. This means the latest draft is:
It’s worth noting that link relationships are also extendable and no one has claimed the at: namespace for them either. I also learned that the IndieWeb drafted a spec for the atproto rel, but its for linking the ATProto profile URL, not a DID. I’m still in the boat that we shouldn’t be using <link> though.
does the set of name values need to be bounded? It could be extremely interesting to do <meta name="at:lexicon:<$type>" content="at://did:plc:abc123/nsid/rkey" />
that way it’s more extensible in the future for whatever $types become mainstream
@bnb.im the proposal includes namespaces for additional relationships to be defined, so the community is more than welcome to add their own AT-specific relationships.
As we talked about earlier in the thread, I would be weary of lexicon specific tags as we are more trying to define semantic relationships rather than the shape of a relationship.
Speaking of, the current draft indicates namespaced properties as at:<namespace>:<property>, which means at:lexicon:app.bsky.feed.post is a perfectly valid tag. I wouldn’t want to close off the system to avoid this happening, but I would spell the “this is about semantic meaning, not lexicon” more strongly in the spec.
Speaking of which, the example in that same section uses <meta name="at:standard.site:pub" content="at://.../site.standard.publication/..." /> which breaks this nuance at first glance. A better example may be something like <meta name="at:standard.site:syndicated-by" content="at://.../site.standard.publication/..." /> to indicate that the publication syndicates this content.
The way I’d frame it is:
name should add additional nuance that the content by itself doesn’t carry ⇒ deleting name should result in a meaningful loss of…well, meaning
the “AtUri” carries the record type, but the name tag carries the relationship of the record to the page (before: “the record in this page is a publication”, after: “this page is syndicated by the publication in this record”.)
I know people have repeatedly brought up using at:{nsid} here, which is why I believe it’s important to document a rule of thumb for how to tell whether it’s a good idea.
In other news, the biggest point of contention with this proposal about whether to use <link> or <meta> tag might have been answered today at IETF. It doesn’t sound like they will be moving forward with updating the URI spec, which, to my understand, means we can’t use <link>.
I’ve also drafted PR that implement this proposal for the social-app and semble
Shipped the head-tag version on Sifa ID yesterday and the pages are already rendering with this on Sifa profiles. A single profile page renders records from across (currently) 16 collections: positions, skills, certifications, talks. E.g. my own profile renders 380 records. Personal pages.sifa.id websites also split those across per-section pages, so career.html and education.html render different subsets and emit identical head tags.
The head tags only ask which record the page is. There is one answer (the profile record) and zero alternates. Something like a career or education entry isn’t another version of the page, it’s a piece of the page/your CV.
So the head is complete at one tag, describes none of the 380 pieces, and can’t tell two of those pages apart. Not that this blocks me, the pages work fine as they are.
But if element-level tagging happens, the `itemid` variant makes sense to me: a career entry *is* a record with its own identity, not a property of the div that renders it.
Thanks for sharing Guido. Perhaps this reveals a case for a page tag not targeting a particular record URI, but a lexicon collection? Though I would wonder what the linking purpose behind that would be. My inking would be that if a page doesn’t represent any one particular record that it simply should not tag one. There are going to be lots of webpages in this situation, namely any page that shows an aggregation of multiple records. A Sifa page that shows, for example, all of my professional experience, doesn’t represent a single canonical record. Maybe linking to my profile record makes sense if the page is scoped to just my experiences. But that’s a product decision for you. I largely agree that element tagging is what will cover these use cases. A feed on Mu, for example, might use the feed definition record as the canonical, with individual posts tagged with their own post URIs.
All this to say, if there isn’t a clear canonical record, it’s ok not to tag one!
Hey all, I started a new thread that’s very germane to this one and also includes a few more ideas as we continue exploring how to bring more of the Atmosphere into the Bluesky app.
).