Open josephmturner opened 1 year ago
I did a little research and found some applicable RFCs:
/.well-known
URI, which is already widely used on the Web. It defines a directory which can have files for various purposes.host-meta
file, in both XML and JSON forms (I'd suggest the JSON one, of course).So if Hyperdrive standardized on this, clients could access, e.g. hyper://PUBLIC-KEY/.well-known/host-meta.json
, and that file could contain, e.g. a public alias for a hyperdrive, which could be displayed to clients next to the public key, as well as various other information, such as the author's name, a link to an about page, etc.
And clients could store any number of other useful files in the /.well-known
directory for various use cases, regardless of file-specific RFCs.
FWIW, we've implemented support for this in hyperdrive.el
now, and it works well: when the user loads a hyperdrive and that file is found, a public name defined in it is displayed next to the URL with the public key (which is much friendlier to humans than the key).
Relative to the Web, it can serve as a kind of analog to DNS, or a reverse form of it: since, on the Web, sites are accessed through DNS, it gives the user a useful way to refer to the site, as opposed to using an IP address. On hyperdrives, even if a public key is bookmarked by the client software, it's not very human-friendly to expect the user to remember associations between public keys and content or authors, so this would allow a helpful alternative.
Do you have a standardized location where clients should store public metadata about a hyperdrive?
In hyperdrive.el, we want to display a human-readable name instead of a public key in the UI when users have supplied one. We are considering storing that public name, along with other potential public metadata, in a JSON file at a well-known location.
If there's a precedent for storing public metadata, we'd prefer to follow suit.