rel="alternate"is about alternate representation of a specific document, not “alternative records the page is associated with”
This is a good shout. I think @fabricatedtechnobabble.com is saying something similar. Perhaps something more like at:associated is a better name for this?
Like meta tags, you can always expect to find it there and at that name, if provided.
Yeah you got it! That’s one of the things we’re looking for and we think the ecosystem needs. A field such as you suggest makes some sense to me. I especially like the “alternate” term here being used to note that an alternate resource for this atproto records lives at https://… which seems to fit the spirit of that semantic more closely.
@fabricatedtechnobabble.com thanks for your input! Exciting to hear that you’re integrating, looking forward to checking that out.
Have just a couple thoughts, hopefully I’m understanding your points correctly 
Breaks if it assumes 1 account (
DID) = 1 app = 1 domain
I think Jim’s first item is more about establishing a pattern for an app to denote a user of their app. This is independent of Standard.site, and would be app specific: pub.leaflet.actor.profile rather than something like site.standard.actor.profile.
There are probably more examples of this out there, but to note one instance, the community has drafted this lexicon for apps to declare their metadata, as well as accountIndicators to tell give integrators some indication of who’s using their app.
Jim’s point about “consumers get a second thing they need” is suggesting that a profile on (for example) Leaflet could potentially specify the URL pattern(s) they “own” on Leaflet, and help integrators know if they can safely associate records with the URLs they found them on (via at-tags).
Yes to
at:author—really useful for multi-author org blogs
I could be wrong here, but one thing to note is that at the moment, there’s no way for an author who is not the repo DID to bi-directionally verify that they authored/co-authored a record. Example: I could publish an article and output metadata specifying you as a co-author.
From trusted sources such as Google, we may be be able to fudge it. But we hope that some of these convos around bidirectionality and associated ref records may help find a pattern for record co-authorship as well.
standard.sitealready closes the loop
Yep! And they really paved the way here, making it really easy for us to integrate Standard.site quickly. But for arbitrary records on atproto, we’re looking to help establish a pattern to do the same sort of URL attestation.
If we find an article by an author on both good.com and evil.com, we need a way to know if the author has expressed trust in one or both of these URLs.
Shortlinks +
at:canonicalincardyb
This is a really good point that hasn’t come up in a while, but I’ll add it to the meeting agenda this week. I believe we avoided this because of how we write these external embeds, as you note in the next point.
Basically it’s this, iirc: at the time of posting, we resolve metadata from cardyb and write it directly to the record. A bit.ly may indeed resolve to good.com at time of writing. But the owner of the shortlink could change the target to evil.com later on, and the external embed in the post would still appear like good.com
As you note, there are things we could explore here. Let us know if you have other thoughts!