Ipns Filesystem Semantics

[whyrusleeping]

Hey, Just creating a discussion space for figuring out how the filesystem interface for ipns is going to feel!

[whyrusleeping]

Warning, Brain Dump:
I want to have /ipns be listable, and have it show two things: your own public key hash (aka, your ipns routing entry) and "local" which will just be a convienence symlink to the aforementioned pubkey hash. I would like to be able to freely change any of the files under /ipns/local and then type something along the lines of "ipns commit ." to add the whole directory to ipfs, and update the ipns entry for my pubkey hash.
This also brings up an interesting thought, Being able to pin ipns entries, so that, when they change, you request all the new updates to them. That way a user could essentially subscribe to someones content, and have it always be the latest when they browse it.

[whyrusleeping]

I also feel like any other ipns entries (aka, other peoples public keys, and dns resolved names) should be a symlink over to /ipfs/thehashitresolvesto. Since the files denoted by those paths are NOT mutable, i feel this makes the most sense

[whyrusleeping]

The ability to publish multiple different ipns pubkey entries would be nice, so as well as having your peer pubkeyhash in ipns, i propose we have a system where users can generate new keypairs through the ipns tool.

Idea:

ipns create [friendly name]

creates a new keypair which should be stored either in the config file, or in a separate file and referenced by the config file. Specifying a friendly name will symlink /ipns/thatname -> /ipns/newpubkeyhash.

[jbenet]

I like all these ideas. some of them may run into problems with FS semantics, or with naming expectations.

listing

Main issue with listing is we cannot list the full directory. POSIX semantics tend to be either list the whole thing or don't, so not clear whether we'll break things if we only list some directory entries. I agree it makes sense on our end, so maybe this should be a togged option.

> ls /ipfs
# list all locally pinned hashes, plus these special files:
add # adds data written as objects to IPFS applying default blocking algo.
pin  # pins a hash

> ls /ipns
# lists all local names, plus these special files
publish # write (pk, hash, sig) to publish a name.

(or this sort of thing)

OR maybe:

> ls /ipfs
cached/ # list all locally cached objects (inc pinned)
pinned/ # list all locally pinned hashes, plus these special files:
add # adds data written as objects to IPFS applying default blocking algo.
pin  # pins a hash

> ls /ipns
cached/
pinned/
local/ # lists all local names, plus these special files
publish # write (pk, hash, sig) to publish a name.

that way, listing is always the same. issue though is that now resolving /A/B/C works even when ls /A does not reveal /A/B but this may still be ok.

friendly local names

ipns create <friendly name> is good for something like that to exist, but wouldn't want people to think that friendly name would be pushed to the world. A way to address is to push people more towards this:

(just experimenting)

> ipns init
# generates pub/key pair
created new name Qmzmxmzcmxvmzxmvcmvzmcvmz

> ipns [--id <pk hash>] name foo .
# take current directory's ipfs hash (say it's Qbbbbbbbbbb)
# add sub-name 
mapped Qmzmxmzcmxvmzxmvcmvzmcvmz/foo to Qbbbbbbbbbb

> ipns resolve Qmzmxmzcmxvmzxmvcmvzmcvmz/foo
Qbbbbbbbbbb

so your "friendly names" are pushed out as named tags/branches to your home "repo/domain".

[jbenet]

oh and +1 to commit idea

[whyrusleeping]

although, ive been talked into thinking publish is a better name for the operation than commit

[jbenet]

More notes on this:

ipfs publish tool

This tool's interface will be pretty tricky to get right. Dumping some notes here.

publish should be a porcelain command that simplifies the common ipns name-publishing process. I think publish should operate on a versioned namespace: it publishes human-readable names in a versioned directory. So, say we have:

• /ipns/H(<pk>) points to a commit object.
• commit object points to a map (tree/directory/namespace) of names.
• map points to the published refs.

ipfs publish <name> <ipfs ref (hash or path)> [-m <message>]
# does:
# 1. add the mapping `<name> <ref>` to current namespace state (modify object, add new obj to ipfs)
# 2. create a commit pointing to this new namespace state + to last commit (with -m message), add to ipfs.
# 3. publish the new name mapping `H(<pk>) -> commit`

[whyrusleeping]

i like that. Curently /ipns/H(<pk>) simply points to an ipfs hash. I can make those changes after tonight (when all the homework is due)

[whyrusleeping]

Rough draft of commit structure:

type Commit struct {
    //Commit Message
    Message string

    // Parent commit, previously published commit
    Parent []byte

    // Published value
    Value []byte

    // Time of publish
    Date time.Time

    // Incremental commit count for this chain
    Version int
}

Although, after writing this out, im mildly opposed to it... since it means one more retrieval that needs to happen (and consequently, more latency)

[jbenet]

https://github.com/jbenet/node-ipfs/blob/master/submodules/ipfs-objects-git/git-objects.proto#L36-L44 - but that's actually wrong.

Some points on yours:

• I don't think the incremental version makes sense. the numbering may come into consistency issues when doing things like merges. We can walk the graph. These objects will be tiny and easy to bundle up + transmit together.
• there can be multiple parents.
• needs author(s).
• parents + authors + value are all actually links in the link table. (one important question that remains is: do we duplicate the link hashes in the actual object data? Or should this data be smart about understanding the datastructure (ipfs object) it lives within? this is tangential to the type field being outside the data)

Another draft:

// Let's look at it like an interface for simplicity
type Commit interface {
    // Parent commit(s) (obj.links["parent[0-9]+"])
    Parents() []Multihash

    // Authors (obj.links["author[0-9]+"] + in obj.data)
    Authors() []Authorship

    // Published value (obj.links["value"])
    Value() Multihash

    //Commit Message (in obj.data)
    Message() string

    // Time of publish (in obj.data)
    Date() time.Time
}

type Authorship struct {
  // ptr to the identity of the author
  Author Multihash

  // ptr to a role like "author", "committer", "publisher", etc.
  Role Multihash
}

it means one more retrieval that needs to happen (and consequently, more latency)

This latency will be amortized after the first fetch + by smarter bitswap strategies. The flexibility of supporting arbitrary datastructures (the model) is much more important here, as we can address the sequential RTT issues.

[whyrusleeping]

Okay, I like that. My reason for having a version number was that I assumed the only person publishing a certain priv key is that priv keys owner, and since a given /ipns/H(<pk>) can only have one value at a time, i didnt see how you could have multiple 'chains' or 'parents' of a single commit.