Connecting records, web pages and apps

Discussion
4

We recently integrated standard.site on the Google Open Source Blog (opensource.googleblog.com, running on Blogger) and just added <meta name="at:canonical"> to our live template alongside <link rel="site.standard.document">. Here is the short version on your three points, with a little context below:

TL;DR

  1. App profile records:
    • Breaks if it assumes 1 account (DID) = 1 app = 1 domain.
    • Needs to support 1-to-many accounts (one author publishing across multiple apps/sites, or one organizational DID hosting multiple blog domains).
    • For publishing, site.standard.publication already handles domain routing; an optional generator / app field on the publication or document record (like Atom’s <generator>) seems cleaner than a per-account singleton.
  2. Adopting at-tags in standard.site:
    • Yes to at:canonical—we just rolled it out live on opensource.googleblog.com as a 1-line addition alongside <link rel="site.standard.document">, and it cleanly avoids the RFC 3986 <link href="at://..."> validator issues.
    • Yes to at:author—really useful for multi-author org blogs where the repo DID is the organization (at:me), not the individual writer.
    • Caution on at:alternate—pointing at:alternate at a parent publication or comment thread breaks HTML alternate semantics (and risks clients redirecting an article URL to the blog homepage or a comment thread). Explicit tags like at:publication and at:blog:comments feel safer.
  3. Closing the loop (bi-directional URL attestation):
    • standard.site already closes the loop for a single canonical URL (<meta name="at:canonical"> → site.standard.document → site.standard.publication ↔ .well-known).
    • The missing piece is multi-URL attestation—both for syndicated/cross-posted articles (@esb.lol’s point) and for shortlinks (goo.gle, bit.ly, etc.).

Details & crossover with shortlinks / third-party schedulers

I posted a related question earlier today (Standard Site, cardyb and shortlinks) that overlaps quite a bit with #2 and #3:

  • Shortlinks + at:canonical in cardyb: Almost every org and foundation uses shortlinks (goo.gle, mzl.la, bit.ly) for campaign tracking. Right now, cardyb follows the 301/302 redirect to grab OpenGraph <meta> tags from the landing page, but drops standard.site verification because the shortlink hostname doesn’t match the destination domain. If cardyb reads <meta name="at:canonical"> on the resolved page (and checks .well-known against the resolved <link rel="canonical"> origin), or if “closing the loop” lets a site.standard.document record attest to its official shortlink alongside its canonical URL, shortlinks wouldn’t break record linking.
  • Write-time (cardyb) vs. index-time linking: Many teams post via third-party schedulers (Sprinklr, Buffer) that construct app.bsky.embed.external directly via the API and never call cardyb to attach associatedRefs. Even with at-tags in HTML <head>, those posts won’t connect back to the AT record unless AppViews/indexers also resolve links (or match attested URLs on records) asynchronously after the post hits the firehose.