Should `indieauth-metadata` be discoverable by DNS?

[samuelgoto]

I'm finding (somewhat to my surprise) that some developers (example) have an easier time updating their DNS records than adding markup to their websites.

I don't know if this is largely true or not, but because I ran into this twice, it seemed worth investigating further if it would be possible to offer a version of indieauth-metadata that could be discovered via DNS (TXT?) records, rather than <link> tags.

Context

In trying to implement this https://indieweb.org/FedCM_for_IndieAuth here https://github.com/fedidcg/FedCM/issues/240, I think I can move most of the metadata to DNS, for example https://github.com/fedidcg/FedCM/issues/580 but if there is a single thing that needs to be a link han it defeats the point (because if you can set up a link you can set up many).

[aaronpk]

That's an interesting idea! I can certainly sympathize with the challenges of adding markup to sites that use CMSs like WordPress. There is already the option for setting HTTP headers instead of adding an HTML tag, which can be easier in some cases, tho I'm not sure what that would take for WordPress specifically.

There is of course precedent for people adding custom DNS entries delegating to external services for things like email, so editing DNS records isn't an entirely foreign concept for this audience.

The big implication here is for client developers, since adding this as an additional option means clients have to support both methods going forward. Clients already have to look at HTTP headers as well as HTML link tags, so this would be adding a third place to look for the indieauth-metadata URL.

I'm not entirely opposed to this, but I would like to collect more data about how difficult of a barrier this is for people.

[mfosterio]

It doesn’t hurt to make it an option for those folks that might not have access to the web server but own the domain. It gets us closer to an orthogonal network of verification. @aaronpk does it have to be on all three? Also what if there was a mismatch on dns and the meta variables? Good topic!

[aaronpk]

oh don't get me wrong I'm excited about adding this as an option on the publisher side, but it does mean additional complexity as an IndieAuth client because now you have to support all 3 in order to cover all your bases.

As far as the mismatch issue goes, the current spec already has text describing the priority order: HTTP Link tag first, if none is present then check HTML <link> tag. I would probably recommend DNS as the first option, since if it succeeds it would result in having done the least amount of work by the client.