Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should indieauth-metadata be discoverable by DNS? #134

Open
samuelgoto opened this issue May 23, 2024 · 3 comments
Open

Should indieauth-metadata be discoverable by DNS? #134

samuelgoto opened this issue May 23, 2024 · 3 comments

Comments

@samuelgoto
Copy link

samuelgoto commented May 23, 2024

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
Copy link
Member

aaronpk commented May 23, 2024

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
Copy link

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
Copy link
Member

aaronpk commented May 23, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants