Locating Humans with DNS
landshark.io
landshark.io
Then your address book would have an entry like http://bob.tel/ which would always contain your contact's latest info.
It turns out that most normal people see a decaying address book as a feature, not a bug. If you are a meaningful contact - you'll send me new details. If not, the data can rot.
Telnic still offer this service - but I had a tel name since the start, and never saw anyone else use their features.
Here's their cheesy product marketing video from back in the day https://youtu.be/8jyB_7sh2S8
Even better: imagine being able to set reverse DNS in this scenario. I call someone who doesn't have me in their address book, and their phone shows "<my nickname>.tel".
DNS is the only global scale example of a broadly functional directory service with decent degree of flexibility in its decentralization. The PSTN is the opposite: it uses carriers, national infrastructure and a plethora of relatively closed systems to achieve the same. Observe: national carrier mobile number portability hacks. It is amusing that, after so many years, directory services for telephones are still under discussion.
Looking around in 2021, it turns out that the complexity associated with running DNS means it has effectively slowly migrated to a smaller number of outsourced infrastructure providers, despite strong decentralization support in the protocol. To put it bluntly, it's more hassle than it's worth to run your own servers when you can outsource for ~free to globally distributed infrastructure that's professionally run and DoS resistant.
We might also note that most voice calls in the world are now placed through IP software services with centralized identifier directories and never touch PSTN at all. Turns out humans like free, free likes cheap-to-provide, and centralized means cheap-to-provide. Turns out the market values users, so funding is a non-issue.
It's sad that, as a result, the oldschool internet is being lost. But the internet was never inclusive, as it required too much technical nouse and good-behavioural assumption. Maybe the internet is just growing up. It's now the digital commons.
While I applaud the effort for this protocol, and I frankly would be the first to sign up for a contact infrastructure service that provided reliable and best-effort security integrations for all legacy channels (SMS, fax, PSTN, mail, VPN) ... I can't see this effort turning the tide. After all, we already have dynamic DNS registrations and IPv6 mobile features, neither of which has been broadly adopted. Instead, I think we will see these protocols co-opted commercially or ignored.
The age-old elements of the protocol are still very reliable. I cannot agree with your conclusion that "its more hassle than its worth" to run DNS servers. Depends on the use case. DNS isn't just for companies. I use run DNS at home and I could not live without it. A third party provider would/could never offer the customised, creative solutions I created myself.
There is a learning curve but I think it is less than, say, email service. Maybe not. You can run DNS without third parties and IMO you should. I think the stuff it allows you to do is well worth it. I think the reason I spent the time to learn DNS is that it is very fast. Instant, short text response. Much more pleasant than what websites have turned into.
The old school is alive and well, but it does not need to hype anything, so what you see and hear is people hype-ing crap, not the good stuff that old, unsexy is much more reliable.
All the third party DNS services could go down and it would not affect me much at all, because I have so much stored DNS data. Most of the DNs traffic I produce never leaves the loopback. Makes the UX much faster.
This sounds a bit nutty until you realize that DNS is essentially an infinitely scalable eventually-consistent database.
Add `overflow: auto` to `.content` to fix the overflow issue.
Source: https://twitter.com/bhathos/status/1357859138433413123
Because they aren't the same thing. RP records designate the person responsible for the domain, which may or may not be the person that the domain identifies.
RP records also assume the user has an email address. That's been a bad assumption for long time now.
And this is on top of cryptocurrency addresses and other addresses.
[0]: ENS: https://ens.domains/
[1]: EIP 634: https://eips.ethereum.org/EIPS/eip-634
[2]: Gilani.eth: https://app.ens.domains/name/gilani.eth
Not the case for sci-hub
IndieAuth[1] let's you use dns-as-identity too and extends it to support authentication.
I'd love to see more use of this but alas the internet has been trained that everything should be add-supported and otherwise free.
In the case of pay for identity (like phone numbers) it was guarded as a potential source of additional revenue for multiplay offerings and micropayments.
A couple of decades along we’re sleepwalking into a time where our personal identity will become the property of big corporations that do not protect our privacy or interests.
Signal, WhatsApp, iMessage etc use phone numbers (and email with iMessage) as a not quite anonymous “lookup key” for an identity.
Perhaps now is the time to look at reinventing something like the ENUM RFC for persistent identity.
https://en.m.wikipedia.org/wiki/Telephone_number_mapping
A million years ago (before hotmail or gmail) I had a bigfoot.com email address that forwarded to your actual address - maybe there is a scope for a community funded modern equivalent now that allows the creation of genuine lifelong “email” identities.
standard protocol like DNS makes lot of sense.
people should be able to publish link to public key as well.
and changes can also be captured in a blockchain .
some of the fields should be protected as configured by the user and who is asking for the information should be logged as well. some data can be permissioned and available on approval only, this could be resume link, physical address, government issues ids
Do you have a link you can share?
> people should be able to publish link to public key as well.
There's a actually a standard for this: https://www.df7cb.de/blog/2007/openpgp-dns.html
I would prefer if you could just dump the whole key in DNS itself, but TXT records are limited to 255 bytes.
> and changes can also be captured in a blockchain .
What's your use case for wanting to know the delta over time?
> some of the fields should be protected as configured by the user and who is asking for the information should be logged as well. some data can be permissioned and available on approval only, this could be resume link, physical address, government issues ids
I was mostly thinking in terms of "public" information. I can see wanting permissions for things like physical address.
The article you've linked also mentions CERT RRs, which include keys themselves, and there's also DANE's OPENPGPKEY [1].
Besides, each string of a TXT record is limited, but they can consist of multiple strings, so whole keys can be stored in those as well (as it's done for DKIM records, for instance).
See: https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s...
Edit: here’s DeCSS:
http://www.yak.net/fqa/126.html
I think RSA was distributed similarly.
What I want is a single ID source which you can provide access to from multiple service providers that need certain components. I’ve just changed address and the nightmare of updating each individual service makes me want for a common framework that all bank, utility, retailers use.
It would only work as part of a compelling product. Maybe something like this will show up in the next generation of censorship-resistant messaging apps.
...does the author mean DNS? Literally spitting text at a server over UDP? As opposed to the comparatively simple json/js/tls/dns hybrid monstrosity which I’m sure would be the end result of his curl prototype.
Don't mistake "simple" for "widely-known".
But DoH is by no means a requirement. If you like the DNS protocol, then by all means have at it.
Still not convinced? Imagine a world where APIs are only called from inside proprietary binary blobs that are built and released by the API provider. In that world the indirection is in the wrong place, at the process invocation level. Luckily this doesn't apply to (most) APIs these days, although it does apply to certain areas of software, like embedded programming (or so I hear). But this is analogous to using a specific binary tool to interact with DNS vs HTTP.
Yes, I'm sensitive to the argument that we shouldn't abandon the other parts of the network stack, and forget that there is more to doing networked applications than just TCP+HTTP. But honestly, for practical reasons there should be very compelling reasons to "drop down" the stack and pick something like UDP+DNS for your application.
I don't have to imagine it. It exists, and it was created by people who insisted on building ridiculously complex software stacks which have made it increasingly difficult to write your own stack. And the few open source stacks are slowly winnowed down because it becomes a feature arms race and eventually the last option standing is the "free" crippled version of some corporate developed library.
Sending and receiving a DNS UDP query, and extracting your RR of interest, takes a few dozen lines of C code. (Using TCP is just as easy if not easier.) Now imagine doing something so simple, but first having to build the SSL and HTTP stacks (or, shudder, QUIC). Nobody would do it. Everybody would just use the same piece of software.
This is exactly how we ended up with Chrome and an unimaginably empowered Google. And it was for the same reasons--"imagine how easy it will be for a web developer to implement feature FOO if we simply added feature FOO to the browser and he could just call do.FOO!"
Not sure what you mean, here. HTTP-based APIs have been really good, I think, for the world overall, and not just because exposing services this was allows you to tunnel arbitrary application data through firewalls!
Are the real blobs you're referring to the browser? I don't think that's fair, because a browser does far more than curl. And curl-level functionality is a lot simpler.
>a few dozen lines of C code...
...built and executed in a specific runtime environment. And since we are talking about distributed programs, by nature, you will be faced with solving all of those painful lessons we've learned about security, performance, and scale, but this time with your own custom starting assumptions.
I think it's quite fair to accept the "curl abstraction" (expressed in callback hell form as get(request, callback(response)) as a basic building block of your system, as opposed to doing something lower level.
https://www.num.uk/blog/announcing-num
HN discussion: https://news.ycombinator.com/item?id=24354559
* Your name, address, and other details are exposed in Whois DB linking all your details to a real name / address.
* You are subject to regulations on domain name use. For example if you have an .eu domain and you live in the UK, you had to either have a new address in the EU after brexit or abandon it.