From @chriscool on Sat Apr 25 2015 06:16:16 GMT+0000 (UTC)
According to @whyrusleeping this doc should be updated and elaborated on:
https://github.com/ipfs/examples/tree/master/examples/ipns
Copied from original issue: https://github.com/ipfs/faq/issues/16
From @wking on Sat Apr 25 2015 15:49:57 GMT+0000 (UTC)
On Fri, Apr 24, 2015 at 11:16:17PM -0700, Christian Couder wrote:
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.
From @jbenet on Tue Sep 15 2015 21:26:00 GMT+0000 (UTC)
would be great to expand on this FAQ here
From @rsynnest on Thu Sep 17 2015 22:08:56 GMT+0000 (UTC)
I have several questions, all related:
From @jbenet on Thu Sep 17 2015 22:24:25 GMT+0000 (UTC)
> - 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.
From @rsynnest on Sun Sep 20 2015 03:31:34 GMT+0000 (UTC)
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.
From @Ghoughpteighbteau on Fri Jun 24 2016 18:07:53 GMT+0000 (UTC)
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?
From @zweicoder on Wed Jul 13 2016 09:10:21 GMT+0000 (UTC)
Is it a goal to have more user friendly names with IPNS instead of the user identity which is also a hash?
From @Ghoughpteighbteau on Wed Jul 13 2016 21:49:07 GMT+0000 (UTC)
@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.
From @rotemdan on Sat Oct 22 2016 21:21:59 GMT+0000 (UTC)
Question moved to the ânotesâ repository
From @mitar on Sun Mar 05 2017 18:55:55 GMT+0000 (UTC)
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.
From @lgierth on Mon Mar 06 2017 03:55:37 GMT+0000 (UTC)
@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.
From @lgierth on Mon Mar 06 2017 03:56:06 GMT+0000 (UTC)
@mitar for more info on these paths you can check ipfs/specs#152
From @mitar on Mon Mar 06 2017 08:07:47 GMT+0000 (UTC)
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?
From @mitar on Mon Mar 06 2017 09:07:28 GMT+0000 (UTC)
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.
From @JayBrown on Fri May 12 2017 21:39:46 GMT+0000 (UTC)
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â.
From @whyrusleeping on Sat May 13 2017 01:03:21 GMT+0000 (UTC)
@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)
From @lidel on Sat May 13 2017 11:15:00 GMT+0000 (UTC)
@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)
From @JayBrown on Sat May 13 2017 19:12:48 GMT+0000 (UTC)
Agree on GC for data.
Is there an option to run some scripts in IPFS to perform some operations automatically, triggered by events or initiated by the client app.?