š¾ Archived View for nytpu.com āŗ gemlog āŗ 2021-03-04.gmi captured on 2024-02-05 at 09:55:47. Gemini links have been rewritten to link to archived content
ā¬ ļø Previous capture (2022-03-01)
-=-=-=-=-=-=-
A while back I had a silly suggestion for a DNS competitor that I joked about on IRC.
It's an interesting idea. Just because I've been itching for something to do, I'm gonna take it serious and look at a few engineering details and possibly (depending on how I feel after finishing this post) write a little implementation for it. A few things: I'm calling Pet Name Files āPNFsā or āPN Filesā for brevity, and the Pet Name System āPNSā.
So, I could only think of three ways to get this to work on a modern system without having to compile a Linux kernel with patched host support:
I'll be mulling over which would work best (custom browser would probably be easiest) as I go over some issues that I see here.
I don't see how you could have duplicates of a domain name for the DNS daemon without just picking one at random, unless you expect people to pop open a terminal and go `pnctl select <PETNAME>` to select which pet name to use before making a request to a domain that has multiple entries. If you're in a browser, you could just pop up a menu and say āwhich record do you want to useā same way qute-passįµ pops up a rofi menu when there's multiple passwords for one site.
The second issues is how you deal with multiple IPs for one pet name. Do you just try them in order, falling back to the next until you find one that works? Do you do the same with certificates? That's probably the easiest, but then what if you want to do the round-robin style like ew0k mentioned? The thing is, there's two (probably more) usecases for having multiple IPs: 1 is to have a new IP and an old IP, so when the new IP goes up then you start using that and then the old IP can be removed in a future PNF; 2 is to have round-robin load distribution to multiple servers, where you'd just randomly pick an IP from the list each time. Maybe add a new field to indicate which method to use, or just pick one as the standard. I'd probably go with the āfallbackā option because it makes it easier to migrate to a new server without having to have everybody switch their PNF at the exact time the migration happens. It also lets you switch certificates without running into the classic TOFU issues, people will use the second one until you switch over, then the first one will match. You can then update your PNF entry at your leisure to remove the old cert.
The question that then arises is how do you distribute PN files? If you have friends that already use Gemini then they can just send theirs to you as a āstarter pack,ā but what if you just found out about Gemini and don't know anyone? What if you want to start sharing your own content, unless you can convince people to add you to their lists no one will ever see your content. If you have a central registry that you can submit entries to, then that defeats the whole purpose of PNS, plus it will destroy any decentralized sharing because everyone will just use the ācanonicalā central registry. Sure, a registry ran by a group of people that we all know in Geminispace would probably be better than the hulking DNS system, but if that's all you want we could just run an alternate DNS root for Gemini instead of implementing a whole new system.
[a]: qute-pass - insert login information using pass and a dmenu-compatible application
When I first read ew0k's post I was all gung-ho about implementing this, even if it never goes anywhere it'd just be interesting, but at this point it's just meh. I might do it, but I don't really feel like writing a browser, but also not excited about patching an existing browser like amfora or something. We'll see, it is an interesting concept to think about at least.
ā