Mapping web pages to canonical AT records

Discussion
25

Throwing in my strong support for stronger semantics in this representation, since it’s being rediscussed (I had meant to bring it up with the original design too, so it makes me happy to see :P)

The original issue being that:

<link rel="site.standard.document" href="at://did:plc:xyz789/site.standard.document/rkey">

is duplicating the same information twice, and tells me nothing(ish) about what that content actually is.

It also forces standardization over standard.site.publication, even if a different lexicon were to come along or I wanted to use mine.

Compare to (syntax slightly apocryphal):

<meta rel="alternate" content="at://did:plc:xyz789/my.own.lexicon/rkey" />
<meta rel="alternate" content="at://did:plc:xyz789/site.standard.document/rkey" />
<meta rel="author" content="at://did:plc:xyz789" />

which tells me both records are an alternate representation of this page, and who the author is.

Proposal

For an actual proposal, I think this could work by literally taking a page out of OpenGraph:

<meta property="at:author" content="at://did:plc:xyz789" />
<meta property="at:alternate" content="at://did:plc:xyz789/my.own.lexicon/rkey" />
<meta property="at:alternate" content="at://did:plc:xyz789/site.standard.document/rkey" />

With this syntax, the part after at: in property encodes the semantic meaning of the link, and not its lexicon or data type.

Encoding URI type

I’m not sure why it seems people want to encode at:did vs at:uri as part of the property itself. There may be a reason I’m not seeing, but it seems fairly easy to tell at parse time whether you’ve been handed a bare did or a full uri.

The one case I can think of where that’d be convenient is styling with CSS: selectors cannot distinguish an AtUri and a Did, and thanks to :has() you can now style body elements according to meta tags in the head. It’s very cursed, but you can.

Anyway, if we do want to carry that distinction explicitly, it could be its own attribute without getting baked into the property name:

<meta data-at-type="did" property="at:author" content="at://did:plc:xyz789" />

Extending the data types

The above keeps the property slot meaning what the record represents, the way og:title / og:description / article:author do, rather than encoding the value’s shape.

This opens up a whole lexicon-agnostic layer of standardization on ATproto. Other things that could be standardized with the same system:

  • at:event => the event the page represents [edit:] an event mentioned on the page, see later reply)
  • at:replies-to => what this blogpost is written in reply to (e.g. another standard.site document)
  • at:tag => A list of tags (represented via AtUris not as strings, which will happen as soon as fanfictions people start building tagging systems)
  • at:copyright => Who owns the copyright of this content (their did)

There’s a lot of vocabularies one could take inspiration from, like IANA link relations, schema.org, dcterms… people building will make up their own regardless, but we could settle on an obvious few to carry over (in a different thread).

Most important: with this, my application doesn’t need to hard-code every possible at:alternate lexicon just to parse a page and check whether it carries a given property. This is unlike site.standard.document, where I’d have to know the lexicon up front. It also still hands me more information than a bare at:did or at:uri would, and allows for the same AtUri to appear more than once carrying different semantic meanings.

4 Likes