ipfs / kubo

An IPFS implementation in Go
https://docs.ipfs.tech/how-to/command-line-quick-start/
Other
16.15k stars 3.01k forks source link

IPNS #1716

Open whyrusleeping opened 9 years ago

whyrusleeping commented 9 years ago

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

BrendanBenshoof commented 9 years ago

What is the current state of IPNS?

whyrusleeping commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

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

jbenet commented 9 years ago

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

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

whyrusleeping commented 9 years ago

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 commented 9 years ago

so long as that node stays online to republish records

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

whyrusleeping commented 9 years ago

@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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

alternatively, help us implement it ;)

harlantwood commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

pawal commented 8 years ago

@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 commented 8 years ago

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

kaliwdsn commented 7 years ago

How do I set dnslink?