Petnames for multihashes

[JesseWeinstein]

I think it would be good to add a minimal implementation of Petnames (as described by http://www.skyhunter.com/marcs/petnames/IntroPetNames.html ) to IPFS (specifically, go-ipfs).

Here are some thoughts on how this could work:

• It would be a peer/daemon-specific mapping between multihashes and arbitrary strings (containing anything except a forward slash)
• It could be written as /petname/blahblahblah (or /pn/blahblahblah if we wanted a shorter prefix)
• at the most basic, it could consist of one subcommand: ipfs petname [multihash] [name]
• to unset a petname, just provide only the multihash
• if there was a petname defined for a multihash, anywhere the multihash was displayed, the petname would be displayed instead (maybe with options --petname and --no-petname to switch between the petname and the hash for particular calls)
• initially at least, I don't think we need any nickname support, or any automated checks for similar existing petnames
• to avoid breaking API compatibility, display of the petnames would be defaulted to off, and require enabling it in the config.

This is somewhat related to https://github.com/ipfs/go-ipfs/issues/1145 .
Thoughts/concerns/encouragement GREATLY appreciated.

[dignifiedquire]

I would love to have this! One thing that could make it even more awesome would be the ability to import and export petname definitions. This could be a simple bash script though if ipfs petname would spit out the list of all currently defined names.

[JesseWeinstein]

Exporting makes sense, but importing would break one of the petname guidelines: "The petname must be assigned to the key only by explicit user action."

[dignifiedquire]

Wouldn't running an import be an explicit assignment?

[JesseWeinstein]

No, because the imported file might contain hashes that the user hadn't explicitly checked over. It's a gray area, but it doesn't seem like a good idea to me.

[jbenet]

I think this functionality is provided by ipfs files already-- meaning pet
names on files are similar to just having a file hierarchy with a well
known root

I think pet names are better suited for peers/keys ? Though similar thing
can happen there too. At the end we care about having a directory of some
kind to map name to longer value. You can do this in one level (a
dictionary) or many levels (a filesystem / pathed namespace)

I'd like

ipfs swarm connect /friends/whyrusleeping
ipfs swarm connect /mine/erebor

Where the root is given by $reporoot/peers or something. Where $reporoot is
the ipld root of an ipfs repo.

Note this is equivalent to

ipfs files cat /myfiles/foo

In that these can be addressed at $reporoot/files
On Wed, Aug 17, 2016 at 21:00 JesseWeinstein notifications@github.com
wrote:

No, because the imported file might contain hashes that the user hadn't
explicitly checked over. It's a gray area, but it doesn't seem like a good
idea to me.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#157 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIcoWY3TlCvwsJEepNWEoHBaR4fbY5Xks5qg665gaJpZM4JmNdz
.

[JesseWeinstein]

Hm. I agree that a petname system could be implemented using the existing unixfs directory object as the place to store the mapping (although I'm not sure how good the performance is for lookups) -- but that doesn't help with having the petname shown everywhere the hash would be, or facilitating editing the link names. At least, as far as I understand it yet...

[jbenet]

Doesn't have to be unixfs dir, just an ipfs object (with sharding)

Well we shouldn't do replacing of hashes for petnames in outputs of
plumbing commands. Maybe porcelain but even then it's likely to be more
confusing that helpful as people won't be able to copy paste lists of
hashes and so on. There's be an additional "unpetting" (resolution) that
would need to happen at the source (and only the source
On Wed, Aug 17, 2016 at 22:58 JesseWeinstein notifications@github.com
wrote:

Hm. I agree that a petname system could be implemented using the
existing unixfs directory object as the place to store the mapping
(although I'm not sure how good the performance is for lookups) -- but that
doesn't help with having the petname shown everywhere the hash would be, or
facilitating editing the link names. At least, as far as I understand it
yet...

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#157 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIcoebb7WBODJr-4IvpTdZZvKAadXo3ks5qg8pegaJpZM4JmNdz
.

[JesseWeinstein]

Why does sharding matter?

With regards to output -- all the commands would have --petname and --no-petname options, so the plumbing ones, if used in scripts, could simply specify --no-petname. And as for copy/paste, that could be supported by always also showing the key (i.e. the multihash), although as long as they were only copy/pasting to the same daemon, the petnames would work as well.

But it does sound like you may have a fundamental conceptual objection to applying petnames to ipfs daemons (although I certainly may be mis-reading), in which case, we'd need to discuss and reach consensus on that before working on the details.

[pawal]

Petnames could be put into DNS, at least for forward lookups:

ipfs swarm connect whyrusleeping.example.com
ipfs swarm connect foo.net

That could lookup _ipfs.foo.net to get the multihash.

Reverse is harder, but perhaps include that as some additional metadata, and validated by a forward lookup.

[ghost]

I have something in mind for this, dnsaddr, which works similar to dnslink.

> dig +short TXT _dnsaddr.bootstrap.ipfs.io
/ip4/1.2.3.4/tcp/4001/ipfs/Qmfoobar
/ip6/1:2:3::4/udp/4001/utp/ipfs/Qmfoobar

> dnsaddr boostrap.ipfs.io /ip4/tcp
/ip4/1.2.3.4/tcp/4001/ipfs/Qmfoobar

> ipfs bootstrap add /dnsaddr/bootstrap.ipfs.io

> ipfs swarm connect /dnsaddr/bootstrap.ipfs.io