FIQ stands for Frequently Ignored Questions. The intent of this document is to act as a "counterweight" to the Freenet FAQ, which I feel reads too much like a marketing brochure - presenting a too-optimistic picture of Freenet's capabilities and failing to address some important issues.
I'm an architect/developer specializing in distributed filesystems, most particularly on the problem of dealing with geographic-scale latencies without sacrificing features such as data consistency. My past and current work for a large storage company inevitably affects the research directions I pursue actively - focus on block-level storage, data availability, more centralization than I'd like - but does not significantly affect my "core interests". A fuller bio, plus bunches of essays I've written on this and other topics, can be found at my website.
No. From a research perspective I think Freenet is a great project. I've had a lot of very rewarding interactions with several Freenet developers. However, I feel that Freenet is often misrepresented and/or misunderstood and I think "the public" deserves a more accurate, balanced picture. In the interests of full disclosure, I should also mention that I have been involved in some significant public disagreements with Ian Clarke and others about some of what's in this document, and there is as a result no love lost between us.
Firstly, anyone who believes that Freenet's core goals of anonymity and censorship-resistance are important to them. This includes all manner of dissidents and whistle-blowers, plus anyone who is concerned about how continual monitoring by governments and marketing organizations erodes individual privacy rights. This includes people who don't personally take advantage of the anonymity; the more users there are, the stronger the anonymity becomes.
Secondarily, people who wish to take advantage of Freenet's performance/scalability characteristics, such as distributing free content to large numbers of users.
People for whom Freenet's design goals and strengths - notably anonymity - are less important than its "non-goals" and omissions. Lawyers and archivists would probably find Freenet unsuitable for their needs, for example, because Freenet lacks data permanence and that is an important feature for those audiences. Similarly, people whose security interests revolve around access control and auditability rather than anonymity might find Freenet's security model inconvenient to work with.
Freenet was not designed to be a permanent data store. Infrequently requested data can drop out of Freenet's caches, and no attempt is made to prevent this. Unfortunately, when most people hear "data store" they do assume permanence. They expect it to be "disk-like" or "filesystem-like" in the sense that data will not leave the system unless/until it is explicitly removed or overwritten. This is simply not Freenet's model, and people who are not clearly warned of this fact are likely to find themselves disappointed by Freenet.
Anecdotal accounts suggest that data loss is an extremely rare occurrence in the current public Freenet. However, this (unquantified) rarity cannot rationally be expected to persist indefinitely as both technology and the Freenet user base continue to change. While a solipsist might claim that no data storage is truly permanent or ever can be, a realist must make distinctions between systems that make serious efforts to ensure data availability even in the face of hardware/connectivity failures and systems that drop data without warning or recourse even in the absence of such failures.
Yes and no. You can do it, and it will improve the odds of your file remaining present, but it does not guarantee anything. The improvement of your odds is unknowable and likely to be very small, so it's probably not worth it.
Also, the additional requests will increase load on the Freenet network, decreasing efficiency. The additional load might even be interpreted as a form of flooding or DoS attack, to which Freenet will - rightly, in accord with its goal of foiling censorship attempts - respond in ways that defeat the original purpose. If data permanence were a goal, other methods would be both more efficient and more robust.
The FAQ does try to address this:
Currently, a document posted to Freenet with the same name as one already present may actually serve to propagate the existing document. There is also currently no means of deleting a document from Freenet. Documents that are never requested are eventually removed through disuse.
One may employ a date-based redirect (DBR), though -- these are evaluated according to the current time and date. A DBR with a frequency of a day will point at a new target key every 24 hours. If this new target is always inserted before the DBR rolls over, the illusion of having the "same" document that is still updatable is achieved. If nothing resides at the current target, it appears as if the content were "deleted".
DBRs are, obviously, a hack. It's hard to tell exactly how much of a hack, because they're very poorly documented. For example, it's not clear how useful they are for documents that change at irregular intervals. What is clear is that they do not help with respect to consistency; in fact, the behavior mentioned in the first sentence would exacerbate consistency problems.
It's also worth noting that Freenet operates on keys, not files or blocks. If keys are associated with files (the most common case) there is no way to update a single block in a file without reinserting the whole file. A little-documented effort has also been made to associate Freenet keys with individual blocks within files, but this presents some additional problems. Performance is obviously one such problem, as each block must be searched for and validated separately; other problems include failure scenarios when only some blocks are available, difficulty in implementing any kind of prefetch, metadata management (see section 3.5) and namespace pollution. While this approach does offer the possibility of updating single blocks within files, there is still much work to be done before Freenet can be compared to other systems that also allow such updates using more conventional means.
Not as such. SSKs have some directory-like behavior, and there are other ways of linking to one Freenet file from within another, but these mechanisms are more like web URLs than directories as they would be understood from a filesystem perspective.
Weakly. An arbitrary piece of metadata may be embedded within a file at the beginning, and a piece of Freenet metadata (metametadata?) transmitted with the file identifies where the boundary between it and the real data lies. There is a standard (based on the Dublin Core) for the format of this "inline metadata" and some tools apparently expect this format to be adhered to. In other words, the Freenet protocol has minimal hooks to support metadata, and some code written as part of the Freenet project uses those hooks, but surprises might be in store for anyone who expects the sort of data/metadata interactions (e.g. writes updating a modification time) that are commonplace in other systems.
Because Freenet does work, pretty much. You can insert files, tell people the keys, and reasonably expect that they'll be able to retrieve those files. They'll do so quite efficiently because of Freenet's caching, and Freenet's basic goals of anonymity and censorship-resistance will be met. There is great value in all of this...if those are your goals, and they often are. The issues discussed above only matter if you have other goals or expectations for a distributed data store.
This section contains both questions and answers provided by others besides the primary author. Identities are revealed, or not, at the submitter's discretion.
Well, it depends what you're looking for. If you want privacy for fetching your mp3's or porn, then you should be fine. If you really are a dissident needing to publish or retrieve information anonymously,you should wait.