命名數據網絡項目（The Named Data Networking project以下簡稱NDN）是網絡領域的以信息為中心的旗艦項目。該項目正在構建一個網絡層，以信息為中心（即內容可尋址）的協議棧。始於約十年前，由NSF資助以及美國10所大學合作研究。
IPFS和NDN擁有在內容可尋址網絡上的相同的願景，但是運作方式卻截然不同。 NDN是本地網絡層模式，而IPFS是應用程序層模式。
鑑於項目的共同願景，我們對本次展示環節非常興奮，尤其是討論和反饋。共有20多人參加了此次演講。
以下是在演示過程中提出的問題的摘要。
問：區塊大小是多少？用戶可以使用不同的大小塊嗎？
答：使用的默認塊大小為256 KB。是的，用戶/應用程序可以使用ipfs add命令的-s（–chunker）選項來定義塊的大小以及塊算法。
問：Merkle-Tree是如何創建的？
答：當用戶將文件添加到其本地IPFS節點時，會在本地創建Merkle-DAG結構（稱為行星際鏈接數據或IPLD）。在IPFS網絡中發布文件時，該文件不會在其他節點中復制。這是有意為之的，目的是避免在未經用戶端同意的情況下將內容添加到用戶端的本地存儲。取而代之的是，該文件最初由用戶端分發，並根據請求將其發佈到網絡。同時，任何從初始文件中進行檢索的節點也可以充當資料的提供者，從而為內容創建緩存網絡。當將文件發佈到網絡時，“提供者記錄”會放在DHT中以指向本地節點進行檢索。如果網絡中的其他用戶端希望成為文件的永久提供者，則也可以“鎖定”文件。如果他們沒有鎖定文件，那麼文件最終將被執行“垃圾回收”操作。
問：從體系結構的角度來看，如何將文件添加到系統中？特別是，您如何讓全世界知道您添加了什麼以及位置在哪裡？同樣，我如何知道其他人已添加到系統中？
答：IPFS體系結構中沒有任何機制可以跟踪在網絡中發布的文件。如果想讓全世界知道有新添加的內容/ CID，必須“離帶（off-band）”發生。該主題與IPFS社區中正在進行的有關“去中心化搜索引擎”的討論有很大關係，但是迄今為止，還沒有任何實質性的成果。也就是說，這個話題引起了Protocol Labs和整個社區的極大關注。 IPNS，及其支持的PubSub協議是傳播有關新發佈內容信息的另一種方法。應用程序可以使用此選項在應用程序本身的領域內傳播（即推送）有關新內容的信息。當IPNS在DHT之上運行時，它也可以進行拉動式（pull-based）工作。
問：我是否需要具有Merkle-Tree的整個結構才能對其中的一部分進行檢索？如果我只想檢索部分文件，那CID根似乎還差點意思。
答：用戶不需要具有Merkle-DAG的整個結構即可對其中的一部分進行檢索。為了僅對Merkle-DAG的一部分（由一個或多個CID塊組成）進行檢索，用戶需要持有這些特定的CID。此外，您可以使用根CID和路徑符號來訪問Merkle-DAG中的文件，例Qmcri6S86LuivUY4FDcM1phu5REXcFYootxn1GsRoqnFN5 / path / to / some / file.png。
問：一旦為區塊分配了CID，該區塊是否會一成不變
答：是的，一旦計算出區塊的CID，它將永遠保持不變。眾所周知在SVN，git等版本控制系統中，這便是“永久Web”的基礎理念。我們認為這是存儲和交付系統的重要屬性。當然，該塊本身並不是一成不變的，可以對其進行更改。但是，新文件的CID將與舊文件會不匹配，因此必須單獨添加新版本（除非內容是通過IPNS在公共密鑰下發布的）
問：如何從IPFS網絡撤銷CID？
答：這樣的CID是永久性的，並且不能被“撤消”，因為它是特定內容的哈希值（請參見上面對“永久性網絡”的評論）。不再希望提供對某些內容的訪問權的用戶可以簡單地停止“提供”該內容，換句話說，停止發布相應的提供者的記錄。但是，這並不意味著內容會從網絡中消失，因為已檢索到該內容的其他用戶端可能仍將其保留在其緩存中並進行提供。另外，Protocol Labs提供的IPFS網關具有CID拒絕列表。 ，此列表中的CID被雙重哈希處理以保護其內容，並且IPFS網關在提供內容之前會進行檢查是否已拒絕/阻止該內容。
問：是否可以檢查特定的CID的刪除狀態（即是否已被添加到拒絕列表中）？
答：要檢查CID是否在給定網關的拒絕列表中，您可以嘗試在網關上解析該CID並獲取HTTP響應代碼，該代碼將通知您是否已拒絕它。每個拒絕列表都由運營組織單獨維護-整個IPFS網絡沒有全局拒絕列表。
問：拒絕者列表似乎並不屬於去中心化的基礎架構。
答：任何個人或組織都可以運行公共IPFS網關並操作自己的拒絕列表。從這個意義上講，拒絕列表的（內容）不是由集權式實體決定的。
問：IPNS記錄保存在哪裡？
答：IPNS使用與內容路由相同的基礎架構，即DHT。用戶端公鑰的多重哈希值在DHT上註冊，以指向可變內容。同時，還有其他分發IPNS記錄的方法：為此目的，使用了稱為gossipsub的pubsub協議（也是一種規範），作為快速分發IPNS記錄的一種方法。如前所述，PubSub與DHT上IPNS的區別在於推動（PubSub）與拉動（DHT）模式的差異。
問：他節點如何知道它們擁有名稱的正確密鑰？
答：當節點在DHT上查找IPNS名稱時，它會從DHT指定的所有用戶端檢索記錄以存儲數據。由於記錄具有序列號，因此客戶端可以輕鬆確定與IPNS密鑰相對應的最新值。還有一個DHT查找快捷方式，用戶無需等待查找完成就可以決定等待接收記錄的定額Q（當前設置為Q = 16），然後再確定它有足夠的信息來確定此最新的記錄。
問：如果存儲IPNS記錄的節點脫機，則IPNS記錄會丟失，並且如果有人未在24小時內更新它，則無法提供該記錄？
答：這是正確的，IPFS記錄的發布者（即不變的CID）也是如此。可能發生以下兩種情況之一：如果已請求該內容，並且該內容已由其他某個節點檢索和緩存，則可以由緩存節點為其提供服務。
如果已檢索（和緩存）該內容的一個（或某些）用戶端決定繼續保存/提供該內容，則可以“鎖定”它，這意味著它們已成為該內容的永久提供者。
問：緩存內容時，系統如何知道緩存的內容以及如何使用/解析該內容？
答：緩存內容的用戶端還將提供者的記錄發佈到DHT，以聲明它們也是其緩存中所有內容項的提供者。
問：緩存的內容是否與內容的原始副本相同？
答：直到下一個“垃圾回收”日期之前，在該時間段內，可以解析和提供緩存的內容，除非“鎖定”緩存的內容（否則，將永久複製，直到用戶做出改變），否則過期。請注意，在撰寫本文時，默認情況下，垃圾收集處於關閉狀態。
問：您必須確切地知道要尋找什麼。 DHT很好，但是很難知道其中有什麼。 CID和真實身份信息之間的綁定在哪裡進行？
答：IPFS是一個分佈式文件系統，用於在面向最終用戶的內容髮現（例如，當前如何使用HTTP尋址/託管Google搜索服務的站點）。 IPFS管理為特定CID提供，存儲和獲取內容；其餘的（將用戶連接到與該應用程序相關的CID或首先找到該應用程序）必鬚髮生在IPFS本身之上的一層。
問：在談話開始時，您提到目的是從網絡（即外部實體）中去信任。你能詳細說明嗎？您如何相信某個內容將通過某個密鑰發布？
答：通過自己的哈希命名內容並將其發佈在分佈式P2P網絡中，從本質上克服了與將信任放入外部實體（例如內容託管和內容解析實體）相關的一些問題。內容可以自我驗證，因此可以在本地驗證。只要該內容是由發布者的私鑰進行簽發的，內容消費者就可以在不依賴外部實體的情況下驗證內容的真實性。
感謝所有參加此次演講的人，以及NDN組織這次活動並邀請我們！
