Thanks Matt! I've read BIP along with comments in github issue. You're very concise about HTTP drawbacks in there - a, b, c. , you don't have to expand on that a lot in DNS-focused spec obviously.. I just recall from my working experience dns is typically far away from what application has to deal with and would like to have dependency on To make changes. I need to go to another team in the company, engage external service provider if it's smb - this is a friction I was talking about. To top this with all the memes that often go around tech industry- "it's always DNS to blame"
I wonder if bitcoin payment scenario is close to OpenID, e.g. how keys are distributed for instance here https://accounts.google.com/.well-known/openid-configuration and what this protocol does in terms of authentication, signing access tokens, etc There are many software libraries for interoperability. it's still plagued by token theft, but smart guys in IETF and OASIS couldn't come with anything better over the years.
I am sure there are benefits to DNS, wildcard sounds easy !
I would definitely agree with your point here, if it weren't for the wildcard option. While I think its a sad state of affairs that most devs don't know anything about how the DNS works (which is sad cause its wayyyy more simple than HTTP(s)), I agree that its often the case. That's the reason for the wildcard option! With it, large custodial services don't need to know much about DNS, they can add one wildcard record and handle the rest at the app layer. Anyone running a solo name resolver can similarly just add one record, so its all pretty easy.
I assume you saw what a, b, and c referred to :) They're pretty important properties.
reply