IPNS

[whyrusleeping]

This issue will be used as a central place to track progress of a complete and reliable ipns implementation.

[BrendanBenshoof]

What is the current state of IPNS?

[whyrusleeping]

The current state of ipns is that you can publish a single entry with ipfs name publish <hash>. This entry is broadcast to the network in a suboptimal way (not sent to as many peers as we would like, but enough that it still works). After 24 hours, the entry will drop from the network unless you run publish again.

When a newer record is published, the old record may still exist in the system, and depending on your routing table, you may receive the old record when resolving the entry.

To address this, we are going to have two phases of fixes for ipns, the first phase will be a 'quick patch' to address the problems listed above, and make ipns a bit more reliable. The second phase will be a rewrite of the ipns code, to use the records spec for the ipns entries stored in the dht.

[BrendanBenshoof]

What is your "quick patch" solution?

The easy one seems to be ensuring that old records are overwritten. Keep a list of the servers that you stored to last time and attempt to update their record if they are still around then also preform a default kademlia store procedure.

This is one of the places that the "fuzziness" of kademlia gets in the way.

[whyrusleeping]

my quick fix has three-ish parts, part one is to add a 'sequence number' to the ipns record fields, which allows us to deterministically choose the 'most up to date' from a set of records, then i'm going to break the dhts GetValue into a GetValue with the current functionality, and GetValues that returns a set of records that were retrieved. GetValue will use the sequence number in the ipns records to pick the best value returned from a get values call. It will then do a PutValue of the 'correct' record to the nodes that had sent it outdated records.

The other part is to implement a simple routine that republishes your current ipns entry periodically.

[chriscool]

Arrgh! There were plans, patches and discussions at some points to add "generation numbers" to Git but it was not implemented as there are ways to get around that (it was mostly to speed up things) and it might introduce some complexity. (And yeah I contributed to shooting down this idea.)

Here are some pages about it:

http://git.661346.n2.nabble.com/RFC-PATCH-0-5-generation-numbers-for-faster-traversals-tt6571507.html
http://git.661346.n2.nabble.com/Git-commit-generation-numbers-tt6584414.html#none
http://stackoverflow.com/questions/6702821/git-commit-generation-numbers

[jbenet]

@chriscool interesting discussion on generation numbers.

this is different though. IPNS records need to be totally ordered (and they may not be chains or may not have an ancestry relation at all -- i.e. they may be "peers" in height/generation/etc). see https://github.com/ipfs/specs/tree/master/records

[muneeb-ali]

@whyrusleeping wrote:

When a newer record is published, the old record may still exist in the system, and depending on your routing table, you may receive the old record when resolving the entry

Looks like an issue stemming from not having consistent "global state" for these records. How frequently are people expected to update these mappings/records?

[whyrusleeping]

@muneeb-ali read the rest of that comment and my other comment in the thread.

[jbenet]

@muneeb-ali this all still has to be written down, but:

• IPNS records are written to "IPRS" (our "record store")
• IPRS storage backends (i.e. "content routing systems") vary, some are DHTs, some can be mDNS, some can be blockchains, etc. etc. (this is the "Routing" layer in the papers/talks)
• So lifetime (and freshness guarantees) of an IPRS record strictly depends on the storage backend. this makes IPNS depend on the nodes' choice of Routing. E.g. nodes distributing records over a DHT look very different than those distributing records over a blockchain, than those over multicast (pub/sub), etc.
• For the DHT, long term we're moving towards more secure DHTs, but for the next few months you can expect typical Kademlia guarantees:
  • record lifetime of 24hr
  • recommended republish interval: 12hr (though we will default be set to 4hr for a while)

More on how we're making records here https://github.com/ipfs/specs/tree/master/records

[whyrusleeping]

Current State of IPNS as of ipfs version 0.3.8

Ipns is now a good deal better than it previously was. Records published by a given node should stay around on the dht indefinitely, so long as that node stays online to republish records. Records each are given a unique sequence number that is one higher than the previous largest seen before. When retreiving a record, a number of records are grabbed through the dht, and the one with the highest sequence number and newest timestamp is selected. Any node that sent an outdated record during a 'get' operation will be corrected with the selected 'best' record.

[ghost]

so long as that node stays online to republish records

Do the records persist over restarts of the node? Asking for two reasons:

• republishing after restarts
• sequence numbers need to be higher than the largest known to the network

[whyrusleeping]

@lgierth restarting the node has no effect on the persistence of the record. Once the node is back online, everything will resume as if nothing happened.

[CompulsiveCoder]

Is there any way to create and use multiple IPNS hashes from the same computer, tied to different folders?
Or are we still limited to only one IPNS hash per computer at the moment?
I'm stuck on a project I'm building unless I can have multiple folders on my computer, each with its own IPNS hash, and be able to update them independently of each other.
Is there any workaround or alternative approach for the time being?

[ion1]

@CompulsiveCoder: As a workaround, you could use /ipns/<hash>/nameA, /ipns/<hash>/nameB, /ipns/<hash>/nameC instead of /ipns/<hashA>, /ipns/<hashB>, /ipns/<hashC> for now.

[CompulsiveCoder]

Thanks, I'll experiment with that. I had been considering trying a similar approach but I wasn't sure if it would be a good idea.
Is there a time line for when that IPNS limitation will be resolved?
I'm eager to use IPFS for various projects, because it seems like quite a revolutionary technology.

[jbenet]

@CompulsiveCoder it's after the dev0.4.0 merge. coming in a few weeks.

try what @ion1 suggests. it will likely be good enough for most use cases.

[jbenet]

alternatively, help us implement it ;)

[harlantwood]

The other workaround is to init multiple configs with ipfs -c configdir ... then you can have multiple ipns streams from one IPFS executable I believe...

[doesntgolf]

Is there any way to create and use multiple IPNS hashes from the same computer, tied to different folders?
Or are we still limited to only one IPNS hash per computer at the moment?

it's after the dev0.4.0 merge. coming in a few weeks.

Did publishing multiple IPNS hashes from one node end up being part of the 0.4.0 release?

[ghost]

@doesntgolf there hasn't been progress yet -- in the meantime, give ipns-pub a try: https://github.com/whyrusleeping/ipns-pub

[pawal]

@jbenet The link above, https://github.com/ipfs/specs/tree/master/records is missing.

Anyway, as a DNS person I would like to ask you to reconsider the use of TXT directly in a domains apex. Perhaps you could prefix the dnslink entry with [_ipfs|_ipns].example.com?

The TXT RR has been way overloaded already. Current thinking within IETF/dnsop is to create an IANA prefix registry for these kind of TXT records.

[Kubuxu]

We are currently allowing the use of both, _dnslink. and the . for compatibility reasons with the _dnslink. being preferred.

[kaliwdsn]

How do I set dnslink?