|
@@ -635,6 +635,33 @@ The \texttt{/ipfs} prefix allows mounting into existing systems at a standard mo
|
|
/ipfs/<hash-of-baz>
|
|
/ipfs/<hash-of-baz>
|
|
\end{verbatim}
|
|
\end{verbatim}
|
|
|
|
|
|
|
|
+\subsubsection{Local Objects}
|
|
|
|
+
|
|
|
|
+IPFS clients require some \textit{local storage}, an external system
|
|
|
|
+on which to store and retrieve local raw data for the objects IPFS manages.
|
|
|
|
+The type of storage depends on the node's use case.
|
|
|
|
+In most cases, this is simply a portion of disk space (either managed by
|
|
|
|
+the native filesystem, by a key-value store such as leveldb \cite{leveldb}, or
|
|
|
|
+directly by the IPFS client). In others, non-persistent caches for example,
|
|
|
|
+this storage is just a portion of RAM.
|
|
|
|
+
|
|
|
|
+Ultimately, all blocks available in IPFS are in some node's
|
|
|
|
+\textit{local storage}. When users request objects, they are
|
|
|
|
+found, downloaded, and stored locally, at least temporarily. This provides
|
|
|
|
+fast lookup for some configurable amount of time thereafter.
|
|
|
|
+
|
|
|
|
+\subsubsection{Object Pinning}
|
|
|
|
+
|
|
|
|
+Nodes who wish to ensure the survival of particular objects can do so by
|
|
|
|
+\texttt{pinning} the objects. This ensures the objects are kept in the node's
|
|
|
|
+\textit{local storage}. Pinning can be done recursively, to pin down all
|
|
|
|
+linked descendent objects as well. All objects pointed to are then stored
|
|
|
|
+locally. This is particularly useful for nodes wishing to keep all their own
|
|
|
|
+files, or backup references to others. This also makes IPFS a Web where links
|
|
|
|
+are \textit{permanent}, and Objects can ensure the survival of others they
|
|
|
|
+point to.
|
|
|
|
+
|
|
|
|
+
|
|
\subsubsection{Publishing Objects}
|
|
\subsubsection{Publishing Objects}
|
|
|
|
|
|
IPFS is globally distributed. It is designed to allow the files of millions of users to coexist together. The \textbf{DHT} with content-hash addressing allows publishing objects in a fair, secure, and entirely distributed way. Anyone can publish an object by simply adding its key to the DHT, adding themselves as a peer, and giving other users the object's path. Note that Objects are essentially immutable, just like in Git. New versions hash differently, and thus are new objects. Tracking versions is the job of additional versioning objects.
|
|
IPFS is globally distributed. It is designed to allow the files of millions of users to coexist together. The \textbf{DHT} with content-hash addressing allows publishing objects in a fair, secure, and entirely distributed way. Anyone can publish an object by simply adding its key to the DHT, adding themselves as a peer, and giving other users the object's path. Note that Objects are essentially immutable, just like in Git. New versions hash differently, and thus are new objects. Tracking versions is the job of additional versioning objects.
|
|
@@ -666,32 +693,6 @@ IPFS is equipped to handle object-level cryptographic operations. An encrypted o
|
|
|
|
|
|
Cryptographic operations change the object's hash (defining a different object, as it should). IPFS automatically verifies signatures, and can decrypt data with user-specified keychains. Links of encrypted objects are protected as well, making traversal impossible without a decryption key. It is possible to have a parent object encrypted under one key, and a child under another or not at all. This allows securing links to shared objects.
|
|
Cryptographic operations change the object's hash (defining a different object, as it should). IPFS automatically verifies signatures, and can decrypt data with user-specified keychains. Links of encrypted objects are protected as well, making traversal impossible without a decryption key. It is possible to have a parent object encrypted under one key, and a child under another or not at all. This allows securing links to shared objects.
|
|
|
|
|
|
-\subsection{Local Objects}
|
|
|
|
-
|
|
|
|
-IPFS clients require some \textit{local storage}, an external system
|
|
|
|
-on which to store and retrieve local raw data for the objects IPFS manages.
|
|
|
|
-The type of storage depends on the node's use case.
|
|
|
|
-In most cases, this is simply a portion of disk space (either managed by
|
|
|
|
-the native filesystem, by a key-value store such as leveldb \cite{leveldb}, or
|
|
|
|
-directly by the IPFS client). In others, non-persistent caches for example,
|
|
|
|
-this storage is just a portion of RAM.
|
|
|
|
-
|
|
|
|
-Ultimately, all blocks available in IPFS are in some node's
|
|
|
|
-\textit{local storage}. When users request objects, they are
|
|
|
|
-found, downloaded, and stored locally, at least temporarily. This provides
|
|
|
|
-fast lookup for some configurable amount of time thereafter.
|
|
|
|
-
|
|
|
|
-\subsubsection{Object Pinning}
|
|
|
|
-
|
|
|
|
-Nodes who wish to ensure the survival of particular objects can do so by
|
|
|
|
-\texttt{pinning} the objects. This ensures the objects are kept in the node's
|
|
|
|
-\textit{local storage}. Pinning can be done recursively, to pin down all
|
|
|
|
-linked descendent objects as well. All objects pointed to are then stored
|
|
|
|
-locally. This is particularly useful for nodes wishing to keep all their own
|
|
|
|
-files, or backup references to others. This also makes IPFS a Web where links
|
|
|
|
-are \textit{permanent}, and Objects can ensure the survival of others they
|
|
|
|
-point to.
|
|
|
|
-
|
|
|
|
|
|
|
|
\subsection{Files}
|
|
\subsection{Files}
|
|
|
|
|
|
@@ -911,7 +912,7 @@ For example, \texttt{flattened tree} for \texttt{ttt111} above:
|
|
\begin{verbatim}
|
|
\begin{verbatim}
|
|
{
|
|
{
|
|
"data":
|
|
"data":
|
|
- ["tree", "blob", tree", "list", "blob" "blob"],
|
|
|
|
|
|
+ ["tree", "blob", "tree", "list", "blob" "blob"],
|
|
"links": [
|
|
"links": [
|
|
{ "hash": "<ttt222-hash>", "size": 1234
|
|
{ "hash": "<ttt222-hash>", "size": 1234
|
|
"name": "ttt222-name" },
|
|
"name": "ttt222-name" },
|