What is IPNS, how does it work and how to deal with mutable content?

[chriscool]

According to @whyrusleeping this doc should be updated and elaborated on:

https://github.com/ipfs/examples/tree/master/examples/ipns

[wking]

On Fri, Apr 24, 2015 at 11:16:17PM -0700, Christian Couder wrote:

https://github.com/ipfs/examples/tree/master/examples/ipns

There's more detail and some more elaboration in this paper 1, but
it's a bit stale now. Still, the things that are stale are what the
DNS entries look like [2](now here [3]). It still gives a good
overview of why we need mutable content and how we handle it.

[jbenet]

would be great to expand on this FAQ here

[rsynnest]

I have several questions, all related:

• If I publish content to my IPNS namespace, is that content globally viewable?
• If so, does this mean I can't store private data (think credit card numbers) within my namespace, or anywhere else on IPFS for that matter, unless it's encrypted?
• Can someone explain how IPNS would be used to build a dynamic web application (assuming all user content needs to stay private)?
• Wouldn't a dynamic application necessitate giving both the user and the application itself read/write privileges to private user data?

[jbenet]

• If I publish content to my IPNS namespace, is that content globally viewable?

depends on the "routing system" your node is part of. by default ipfs nodes are part of a global, public DHT. you can build your own subnetworks, etc. and later on be able to use different routing systems.

• If so, does this mean I can't store private data (think credit card numbers) within my namespace, or anywhere else on IPFS for that matter, unless it's encrypted?

yes, keep sensitive data encrypted. we'll have native support for this soon enough, just not there yet.

• Can someone explain how IPNS would be used to build a dynamic web application (assuming all user content needs to stay private)?

For private data, look into capabilities, in particular e-rights, tahoe LAFS, and so on. there are plenty of models available. we'll implement one soon and have it be native, but not there yet.r ight now you need to do your own encryption.

For a better case, use IPNS to point to latest versions (think of it like a git branch, really) if you try to model how you would do it with git files, commits, and branches, you have a a very good working model of how to do it in ipfs. (thought you can do CRDTs for much better data).

• Wouldn't a dynamic application necessitate giving both the user and the application itself read/write privileges to private user data?

depends on the application, and in those cases you can (a) scope access appropriately, (b) use capability models for this, and (c) use more advanced crypto primitives (like multisig) to require approval from multiple parties.

definitely if you want to build a completely distributed crypto-secure webapp with no central agent that processes things, you need to think about the update model. i encourage you to do this, it's the right way to build distributed applications. however you can get started by translating webapps of today and only storing the data on ipfs, keeping the processing in one place. then, move to the distributed case.

[rsynnest]

Thank you for the thorough answers. Glad to hear encryption is on the road map. I will look into Tahoe LAFS, smart contracts, multisig etc. Hopefully whatever you guys bake into IPFS won't be too different, and ideally won't be too difficult for devs to migrate existing application architecture.

[Ghoughpteighbteau]

Thinking in terms of a fully distributed application built on IPFS. IPNS will need to be used to facilitate new communication between the nodes. Will applications each have their own IPNS public private keypair?

Currently IPNS has a Time to live system (as I understand it). I assume this means that others that have resolved this address will be capable of responding to resolution queries for that address within that timeline? What if the publisher republishes an update? Do you have to wait out the RecordLifetime period? What other potential strategies might be implemented here?

If the owner of that IPNS address dies or goes away, will the swarm be capable of giving you the last seen resolution to that address? Or will it be a broken link?

Should IPNS be considered when it comes to semi-realtime communication? Or should it just be used to bootstrap something else?

[zweicoder]

Is it a goal to have more user friendly names with IPNS instead of the user identity which is also a hash?

[Ghoughpteighbteau]

@zweicoder Really, the answer is no. IPNS is there as a way to have an unchanging link to changing data. in IPFS the link is the hash of the data, so you can never change the data without changing the link.

This means IPFS cannot support dynamic content (by itself), IPNS is a way to have an unchanging link refer to changing content. That's its goal.

That said, currently it can support human readable names through the DNS system.

~ $ ipfs name resolve /ipns/ipfs.io
/ipfs/QmTzQ1JRkWErjk39mryYw2WVaphAZNAREyMchXzYQ7c15n

In this example, I ask IPNS (ipfs name) to resolve /ipns/ipfs.io

IPNS then asks DNS for any TXT records in ipfs.io

~ $ dig ipfs.io txt

; <<>> DiG 9.10.4-P1 <<>> ipfs.io txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2207
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ipfs.io.           IN  TXT

;; ANSWER SECTION:
ipfs.io.        119 IN  TXT "dnslink=/ipfs/QmTzQ1JRkWErjk39mryYw2WVaphAZNAREyMchXzYQ7c15n"

;; Query time: 97 msec
;; SERVER: 10.10.100.1#53(10.10.100.1)
;; WHEN: Wed Jul 13 14:45:24 PDT 2016
;; MSG SIZE  rcvd: 109

so as an alternate, IPNS can use the DNS system to create human readable names. Though this is a centralized system. So it sucks to rely on it to make human readable names, maybe one day IPNS will support something like https://namecoin.info/ ? or maybe another decentralized naming system.

[rotemdan]

Question moved to the 'notes' repository

[mitar]

Reading documentation here it is unclear to me what <ipfs-path> is. Is this /ipfs/<my peer ID> only, or could it be /ipfs/<my peer ID>/<key>?

So the issue is that I would like to store some data into IPNS for my app on top of IPFS. But I do not want to just override the whole IPNS entry, if there can be only one. Maybe the user of my app uses their IPNS also to host a website and so on.

[ghost]

@mitar <ipfs-path> is a data path as used e.g. on the gateway or in dnslinks: /ipfs/Qmdf6iGuPoQ7jmGM48nWoy46F5EwMiXYVif968cpwQXDrU

We'll have these paths better specified soon.

[ghost]

@mitar for more info on these paths you can check ipfs/specs#152

[mitar]

Hm. But it is pretty tricky to store a value under a key under inside IPNS. It seems it can point only to an object, and then I have to patch that object, and then redirect IPNS to that. But this is really fragile if I want to store different things under my IPNS name, apps, websites, datasets, etc.

So I am not completely sure what are current best practices here?

[mitar]

Hm, I see. I could generate additional key for my app using /api/v0/key/gen and then I can publish a value under that key.

[JayBrown]

Would love for my node to auto-republish to ipns. After 24h ipfs can't resolve the name, and I have to do it manually. I assume it will be implemented in one of the future updates? (Faintly remember reading something about this.) But to do that, I assume the node would have to remember the parent hash, the rsa-key etc. And it would also have to know when to stop auto-republishing, namely when the content (and therefore the parent hash) has changed, as soon as it was republished.

Would also be great to have an auto-pin-rm: if I change the content of a folder, I then add the new one to IPFS, then publish its hash to ipns under the same key, and the node determines that the previous hash that it (re-)published under that key for n times can be taken off the auto-republish list. With an auto-pin-rm argument, it would then also remove all of that hash's child objects from local storage that are not part of new publication anymore, but were part of the previous "edition".

[whyrusleeping]

@JayBrown for your default key, your node should be auto-republishing your entry every 12 hours. For secondary keys (ones created through ipfs key gen) you have to manually rebroadcast them. This should be fixed fairly soon (a contributor is working on it)

[lidel]

@JayBrown I really like "auto-pin-rm" idea!

Automatically removing pins for content that was a part of resource tree in previously published version of IPNS name, but is not present in the latest one would be a very cool opt-in feature 🚀

(I think removing pins is enough, removal of actual data should be left to GC)

[JayBrown]

Agree on GC for data.

[madavieb]

This issue has been moved to https://discuss.ipfs.io/t/what-is-ipns-how-does-it-work-and-how-to-deal-with-mutable-content/457.