Matthew Finkel:
Some months ago, the petname system interested me enough that I started to write a proposal for it. At this point, it's wound up in bitrot. Though I'd spent a bit of time working on it, there was no comprehensive way to accomplish it. One thing to remember about petnames is that they are *user defined*. […]
The problem I ran into with this scheme is where the mappings should be stored - who is in control of this? In short, is this a mapping that Tor persistently stores or is it a client application that handles this. AND if it is a client application, that becomes a usabibility nightmare because if Tor Browser has an interface for it, then that's great but what if I'm using irssi and lynx on a headless system? If Tor maintains this database, then for the petname to perform as expected, every application would need to support a minimal Controller and have the ability to resolve the name mappings (and possibly append to them, also).
What looks like a possible way to solve the problem you describe:
The address book would be stored by the Tor daemon, in a persistent manner.
A new host extension would be introduced so that when an application tries to connect to `torproject.myonions` through Tor, it will connect to the hidden service that holds the name `torproject` in the local address book.
Editing the local address book would be done through commands sent through Tor control port. The Tor Browser could gain a new `about:myonions` page for GUI editing. Editing capacities could also be added to Arm for headless system. And we could even make the address book file human editable to have `vi` as a fallback.
(I don't really like `myonions` but I'm sure someone will come with something better.)
Usability wise, I wonder if we could implement some kind of web links that could quickly add a new name in the local address book (after user confirmation).