FAQ questions about ipfs HOT 11 CLOSED

Could Tahoe-LAFS be relevant as a storage system? There's an I2P version of it which mimics Freenet in behavior, allowing you to publish content addressable data (or more specifically, it is identified by the combination of publisher public key and file identifier, followed by a read OR read-write key if you're going to look at the contents, allowing for resources to be edited without changing names). One could publish an IPFS repository in a publicly readable Tahoe-LAFS directory, where only the maintainer has write access. The directory identifier would always be constant, and you don't need any servers to find and verify it, just access to storage nodes.

from ipfs.

When I do an ipns lookup, how do I know I have retrieved the most recent value? I may be overlooking something, but I don't see this addressed. One thought I had was that entries could have a TTL, and I would be expected to re-publish my ipns entry every TTL.

from ipfs.

One thought I had was that entries could have a TTL, and I would be expected to re-publish my ipns entry every TTL.

@justinsb great observation, thats right. there are a number of things that have been addressed in building https://github.com/jbenet/go-ipfs/ and this is one of them (expect a DRAFT 4 when i can come up for air). The thought is to do the following:

IPNS records include their own notion of validity (this is basically an opaque field -- will be size limited), which implementations/applications use to decide on the validity of a record.

this means that a record can specify its own notion of validity, like so:

• (network time) valid until <timestamp> (vulnerable to clock drift and clock spoofing)
• (network time) valid between <timestamp1> and <timestamp2> (vulnerable to clock drift and clock spoofing)
• (blockchains) valid between <block x> and <block x> + 10 (to use "blockchain time")
• (revocation) valid until a newer record appears (vulnerable to replay attacks and update supression)
• <insert more ways to specify validity here>

This is possible by making sure applications/implementations can make sense of the validity field. I'll probably cal for standard implementations to include a number of default validity notions, but really, ipns seeks to be a PKI-defined namesystem, and shouldn't get in your way by baking in assumptions or ascribe to a particular notion of validity.

Btw, an important issue this sidesteps is that "agreeing on time" is a really hard problem. Though dns does, a cryptographically secure system cannot rely on NTP (network time), although that may be just fine for many applications (like my personal calendar). Basically, IPNS should be compatible with those of us who have atomic clocks, those of us who rely on cryptographically secure notions of time (distributed consensus), those of us who run ntpd, and those of us who want to manage revocation their own way.

from ipfs.

You might want to look at how Factom (blockchain based) proves there's only ONE valid successor to a previously submitted document, not more.

from ipfs.

Hi, I just discovered ipfs, and have a few questions that as far as I can tell aren't addressed in the papers/on the site. 1) There's a reference to using ipfs as a personal filesytem. Does this mean the go-implementation supports setting up a private swarm? Can I run ipfs on my server with a few tb of disk at a hosting provider, and on my home-server in order to have two mirrors, and additionally on my workstation for pushing data? Can I do this easily, and still know that my data is secure (in transit etc)?

2. If I push a few TB of data into ipfs (say some media files, install isos etc) -- is that a reasonable use of the technology? How could/should I assure that the network has the capacity to safely store the data, with suitable redundancy?

Edit: See ipfs-inactive/faq#4 ipfs-inactive/faq#5

from ipfs.

@e12e would you mind asking these in our brand new https://github.com/ipfs/faq ?

from ipfs.

Done. Is there a pointer to the new FAQ anywhere? Perhaps this whole thread should be moved over/deleted -- and replaced with a link to the faq?

from ipfs.

Moved to https://github.com/ipfs/faq

from ipfs.

Is there a reason we have 2 sets of FAQs? One on https://github.com/ipfs/ipfs, one on https://github.com/ipfs/faqs?

Can we move all FAQs to https://github.com/ipfs/ipfs/faqs?

from ipfs.

@mekarpeles thanks, @RichardLitt just brought this up too. My thought was to keep the one in the readme because it's a super quick run down of quick information about the project. but maybe we can just rename that section "About" (maybe change the Q/A format for prose) and add a section "FAQ" that has a link to https://github.com/ipfs/faq/ and tells people to ask there.

Thoughts?

The readme is due for some serious updating anyway. It needs to list:

• implementations -- links to main impls
• api clients -- links to all known api clients

@RichardLitt maybe we can just compress project-directory (remove whitespace, make it more like the awesome lists) and put it directly in the readme?

from ipfs.

but maybe we can just rename that section "About" (maybe change the Q/A format for prose) and add a section "FAQ" that has a link to https://github.com/ipfs/faq/ and tells people to ask there.

This sounds way cool to me. I think two FAQs is confusing.

@jbenet I think compressing project-directory makes sense. @mekarpeles is working on a PR for removing it, which might make sense - we should probably be automatically generating it anyway, as it is just the links + the description. I think automatically generating one, semantically sorting it, and hosting that on ipfs.io/docs makes a lot of sense to me. Then we can keep only the good ones we need in a mini-list (like in #124) in the README.md.

from ipfs.