Proxied content from gemini://
regarding: pet name system

↩ go back to index

regarding: pet name system

march 4, 2021

a response to ew0k's post

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.

a few issues

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

something to think about

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.

↩ go back to index

like this post!

view likes and comments



-- Copyright © 2021 nytpu - CC BY-SA 4.0

Proxied content from gemini://

Proxied from my capsule on the Gemini Protocol

Gemini request details:

Original URL
Status code
text/gemini; lang=en-US
Proxied by

Be advised that no attempt was made to verify the remote SSL certificate.