作者： fiatjaf https://fiatjaf.com/d5031e5b.html
IPFS的破損設計 #
2020-01-20
我曾經上過這個關於 “內容-地址 “的當。它聽起來非常好。你知道某個文件的存在，你知道可能有人擁有它，但你不知道它在哪裏，或者它是否被託管在某個域名上。有了內容尋址，你可以只說 “開始”，下載就開始了。你不需要關心。 其他解決常見難題的神奇屬性：網頁不會下線，鏈接不會中斷，有價值的內容總能找到它，其他人會爲你分發你的網站，任何內容都可以很容易地傳送給你附近的人，任何人都不必依賴第三方集中式服務器。 但你知道嗎？說一件事是好的並不自動使它成爲可能和有效運轉。例如：說東西是由他們的內容來解決的，並不能改變互聯網是 “location-addressed”的事實，你仍然必須知道擁有你想要的數據的peers在哪裏，並與他們連接。
這方面的解決方案是什麼呢？一個DHT!
DHT？ #
事實證明，DHT的激勵結構很糟糕（正如你所期望的那樣，沒有人願意免費持有和提供他們不關心的數據給別人），而且IPFS的經驗證明，即使在像今天的IPFS這樣的小網絡中也是行不通的。 如果你運行過IPFS客戶端，你會注意到它是多麼的堵塞你的電腦。也許你不知道，如果你很有錢並有一臺非常強大的電腦，但是，它仍然不適合在整個世界上運行，也不適合在網頁、服務器和移動設備上運行。我想象可能有很多未優化的代碼和技術債務造成了這些和其他問題，但DHT肯定是其中最大的一部分。IPFS在默認情況下可以打開多達1000個連接，並吸走你所有的帶寬–而這僅僅是爲了與其他DHT Peers 交換密鑰。
即使你在 “客戶端 “模式下限制了你的連接，你仍然會被那些不明連接所淹沒–而且把IPFS節點作爲客戶端運行是沒有意義的，這違背了讓每個人託管他們所擁有的文件和內容尋址的整個目的，使網絡中心化，使IPFS補創建時要取代的對立的客戶端/服務器出現了。
連接？ #
因此，DHTs對於一個計劃成爲大的和星際的網絡來說是一個致命的缺陷。但這並不是唯一的問題。 在IPFS上尋找內容是有史以來/最慢的體驗，而且由於某些我不理解的原因，下載的速度更慢。即使你在另一臺有你需要的內容的機器的同一局域網內，仍然需要幾個小時來下載一些你用=scp=幾秒鐘就能完成的小文件–這是考慮到IPFS設法找到另一臺機器，否則你的命令就會被卡住好幾天。
現在，即使你忽略了IPFS對象應該是可尋址的內容而不是可尋址的位置，並且知道哪個peer有你想要的內容，你去那裏並明確告訴IPFS直接連接peers，也許你可以得到幾秒鐘的（緩慢的）下載，但隨後IPFS將放棄連接，下載將停止。有時–但並不總是–將peer地址添加到你的引導節點列表中是有幫助的（但注意這根本不是你應該做的事情）。
IPFS應用程序？ #
現在考慮一下IPFS的營銷方式：它告訴人們在IPFS上建立 “應用程序”。它贊助在IPFS之上的 “數據庫”。它基本上把自己宣傳成一個這樣的地方：開發者只要把他們的應用程序連接到那裏，所有的用戶就會自動地相互連接，數據將被保存在他們之間的某個地方，並立即可用，一切都將以點對點的方式工作。 除了它根本不是那樣工作的。“libp2p”，用於連接人們的IPFS庫，已經壞了，每6個月就會重寫一次，但他們保留了他們美麗的登陸頁面，說一切都神奇地運行着，你可以直接插入。我不是說他們應該讓一切都完美，但至少他們應該對他們真正擁有的東西誠實。
它不可能與其他人連接，多年來沒有js-ipfs和go-ipfs的互操作性（但他們卻宣傳將有python-ipfs、haskell-ipfs、whoknowswhat-ipfs），連接被切斷，還有許多其他問題。
因此，基本上所有的IPFS “應用程序 “都只是想連接兩個peer的應用程序，但不能手動操作，因爲瀏覽器和IPv4/NAT網絡沒有提供簡單的方法，WebRTC也很難，需要服務器。他們與 “內容尋址 “沒有任何關係，他們不是要建立 “Merkle樹的森林”，也不是要分發或存檔內容，以便所有人都能訪問。我不明白爲什麼IPFS把它的核心信息改爲這個 “全棧p2p網絡 “的東西，而不是基本的內容可尋址的想法。
IPNS？ #
那數據庫呢？你怎麼能用一個應該改變的值來 “內容尋址 “數據庫？他們的方法是保存所有的值，過去的和現在的，然後用新的DHT條目來傳達什麼是最新的值。這就是IPNS。
顯然，就在提出了內容可尋址的想法之後，IPFS的人意識到這永遠無法取代正常的互聯網，因爲沒有人會知道存在什麼樣的內容，或者一些內容何時被更新–他們不想與正常的互聯網共存，他們想把它全部取代，因爲這個目標更大膽，可以獲得更多的資金，也許？
所以他們發明了IPNS，這個名稱系統將位置可尋址性重新引入本應只有內容可尋址的系統。
他們是如何做到這一點的呢？還是DHTs。它起作用了嗎？並非如此。它是有限的，緩慢的，比正常的內容尋址要慢得多，大多數時候它甚至在下班後都不工作。但是，儘管開發人員會告訴它還沒有工作，但IPFS的營銷人員會談論它，好像它是一個東西。
歸檔內容？ #
我對IPFS的主要使用情況是存儲我個人關心的內容，以及其他人可能也關心的內容，比如來自死掉網站的舊文章和視頻，有時是在整個網站被撤下之前。 所以我就這麼做了。在許多個月裏，我把東西歸檔在IPFS上。IPFS的API和CLI並不容易追蹤東西的位置。=pin=命令也無濟於事，因爲它只是把你釘的哈希值扔在哈希值和子哈希值的海洋中，你再也找不到你釘的東西了。 IPFS daemon有一個假的文件系統，其功能半生不熟，但允許你在樹狀結構中通過名稱對事物進行本地定位。更新或添加新的東西非常困難，但還是可以做到的。它允許你給哈希值起名字，基本上。我甚至開始爲它寫一個包裝器，但在經過許多星期的精心策劃和分發後，我在假文件系統中的所有條目突然消失了。
儘管沒有丟失任何文件，但我還是失去了一切，因爲我無法在我自己的電腦中的哈希值的海洋中找到它們。經過一些挖掘和IPFS開發者的幫助，我設法恢復了一部分，但這涉及到黑客。我的東西消失的原因是假文件系統的一個錯誤。這個錯誤被修復了，但不久之後我又遇到了一個類似的（新）錯誤。在那之後，我甚至試圖建立一個哈希存檔和發現的服務，但由於上面列出的所有問題開始堆積，我最終放棄了。還有內容規範化的問題，IPFS daemon 用於通過HTTP提供默認HTML內容的代碼，IPFS瀏覽器擴展的問題以及其他問題。
面向未來？ #
IPFS的核心宣傳特點之一是它使內容面向未來。我不確定他們是否使用了這種表達方式，但基本上你有內容，你對其進行哈希計算，你將得到一個永遠不會過期的地址，現在每個人都可以用同樣的名字來引用同樣的東西。事實上，這更好：內容被分割並在merkle-tree中的有哈希值，所以有細粒度的重複數據刪除，人們可以只存儲大塊的文件，當一個文件要被下載時，很多人可以同時提供它，像torrents一樣。
但接下來是協議的升級。IPFS使用了不同的哈希算法，不同的哈希格式，並將改變構建Merkle樹的默認算法，所以基本上相同的內容現在有大量可能的名稱/地址，這違背了整個目的，而且是的，使用不同策略哈希的文件並不自動兼容。 實際上，從一開始，merkle算法就可以由每個人在每個文件的基礎上進行改變（例如，你可以按章節或頁面而不是按字節塊來分割一個圖書文件）–儘管可能沒有人這麼做。我知道一開始就想出完美的合希策略是不容易的，但是處理這些問題的方式讓我懷疑IPFS的發起人並沒有真正擔心面向未來的問題，或者我們只是永遠處於Beta階段。
Ethereum？ #
這也是一個大問題。IPFS是由Ethereum的愛好者建立的。我無法讀懂IPFS背後的人的想法，但我可以想象他們對激勵機制的理解和以太坊的人一樣差，他們傾向於類似於騙子的行爲，比如爲投資者獲得一大筆資金，以換取他們不知道能不能實現的承諾（比如Filecoin和IPFS本身），基於半真半假的說法，在中途改變東西，因爲一些高層管理人員決定要改變（動作快，破壞東西），用花哨的名字如 “分佈式網絡”。
他們把IPFS（這不是IPFS最初設計的主要內容）作爲 “點對點雲 “來推銷，對以太坊開發者來說非常有誘惑力，就像以太坊本身一樣：作爲一個爲你運行你的代碼的地方，這樣你就不必託管服務器或承擔任何責任，然後Infura將向所有人提供內容。同樣，Infura這幾天也在爲以太坊開發者免費託管和提供IPFS內容。具有諷刺意味的是，就像以太坊騙局一樣，隨着它越來越中心化，IPFS點對點網絡可能開始對終端用戶更好地工作。
IPFS的問題。太多的不可更改性 #
有了描述每塊內容的索引或數據庫，內容尋址就無法使用。由於IPFS是完全的內容尋址，除非你有一個非IPFS的索引或數據庫，或一個動態和可更新的鏈接的內部協議，否則什麼都不能做。
IPFS的自負使他們選擇了第二種方案，這被證明失敗。他們甚至鼓勵創建一個由IPFS驅動的數據庫，這不能不說是一種誤導。
2019-01-08
IPFS的問題-太多的不可改變性 #
有了描述每塊內容的索引或數據庫，內容尋址就無法使用。由於IPFS是完全的內容尋址，除非你有一個非IPFS的索引或數據庫，或者一個動態和可更新的鏈接的內部協議，否則什麼都不能做。
IPFS的概念使他們選擇了第二種方案，這被證明敗。他們甚至激勵創建一個由IPFS驅動的數據庫，這不能不說是一種誤導。
2019-01-08
IPFS問題-混亂 #
大多數IPFS開源項目、庫和應用程序（不包括Ethereum的東西）是嚴重依賴動態數據和臨時鏈接的東西。在關注IPFS社區時，你會看到最常見的項目是聊天室和類似的東西。我已經見過幾十個這樣的聊天室了。還有一個著名的由IPFS支持的數據庫。你怎麼能用內容尋址來做這些事情是個迷。當然，他們可能依賴於IPNS或其他外部地址系統。
在IPFS上還有一堆的 “文件共享”。人們用來臨時爲第三方提供一個文件的那種東西。在IPFS上有圖像共享，在IPFS上有粘貼式文件，等等。人們似乎並不認同這裏對斷裂鏈接的關注。
2019-04-28
IPFS問題-垃圾幣工廠 #
IPFS從一開始就被宣傳爲以太坊社區 “存儲 “數據的一種方式，用於他們的 “dApps”。我不認爲這在任何方面是有害的，但由於某些原因，它可能導致IPFS開發人員過多地關注Ethereum的東西。有一次我看了一個講座，顯示libp2p開發者–儘管被Ethereum團隊忽視了（最終創建了他們自己的不可知的p2p庫）–投入了大量的工作，讓一個在瀏覽器中運行的libp2p應用與一個正常的Ethereum節點對話。
總是有點被遺棄的 “Awesome IPFS “網站是一個大的 “dApps “庫，其中一些甚至沒有他們的登陸頁面了，還有無用的以太坊智能合約，出於某種原因使用IPFS來存儲他們的用戶產生的任何無用數據。 同樣，以太坊人使用IPFS本身並不是一個問題，但它至少是令人困惑的，也許是誤導，當你搜索IPFS時，大多數的使用案例實際上是以太坊的無用案例。
IPFS問題- 社區 #
直到昨天，我還是一個狂熱的IPFS用戶。很多時候，我問一些簡單的問題，而這些問題我在互聯網上找不到答案，在#ipfs Freenode上的IRC頻道。大多數時候我都沒有得到答案，即使我得到了答案，也很少是對IPFS有深刻了解的人。我曾經在js-ipfs倉庫中的問題被擱置了一年之久–其中一個問題是提高了人們對一個問題的認識，而這個問題在幾個月後通過完全重寫得到了修復，我在幾個月後意識到這一點後關閉了自己的問題，我認爲負責重寫的人從未承認他修復了我的問題。 幾天前，我問了一些關於IPFS協議內部如何工作的問題，真誠地想了解在IPFS上尋找和獲取內容的低效率。我指出，最好能有一張圖來顯示，這樣人們就會明白其中的困難（我沒有），也不會因爲速度慢而感到生氣。我被告知要閱讀白皮書。我已經看過白皮書了，但又讀了一遍相關部分。白皮書並沒有解釋任何關於DHT和IPFS如何尋找內容的問題。我在房間裏說了這一點，被告知要再讀一遍。 在有人誤讀這部分內容之前，我想說，我理解如果你忙於開發具有星際意義的東西，在IRC上不斷回答別人是一件很痛苦的事情，而且我沒有付錢給任何人，也沒有被回答的權利。另一方面，如果你正在開發一個超級重要的協議，由數百萬美元資助，很多人在你的軟件上撞得頭破血流，卻沒有人幫助他們；你總是很忙，卻從來沒有提供給你的用戶帶來快樂的東西，那麼事情就很不對勁了。我真誠地不知道IPFS的開發者在做什麼，如果他們這麼說，我不會懷疑他們在做重要的事情，但我看到的–以及許多其他用戶看到的（看看IPFS Discourse論壇）是bug，到處都是bug，混亂的用戶體驗，幾乎沒有幫助。
2019-02-14
IPFS問題- 釘 #
“Pin “是IPFS團隊想出的一個很好的詞，用來指定告訴你的節點永久地存儲一些內容，不要把它當作垃圾來收集。這個想法是，你將存儲你獲取的所有內容，並自動將這些內容轉發給其他人，但每隔一段時間，你的節點上所有沒有明確 “釘住 “的內容都將被刪除，所以你不應該擔心存儲太多的其他人的東西，但也可以爲保持你喜歡的內容而做出貢獻。
然而，“釘 “有一個很大的問題：你無法知道你釘了什麼。你添加的每一個釘子都會被保存在你的電腦上，你將無法取消釘子，因爲你不知道什麼是什麼，最後你會留下一個裝滿釘子的磁盤，在對整個IPFS實驗感到沮喪之後，你可能會失去這個磁盤，或者刪除所有東西，爲其他東西打開空間。
審視一下這個模型中的激勵機制：我們依靠的是分享是由人們在不情願和不知道的情況下做出的。用戶在節點上花費電力，而這些節點應該是一直在運行併爲他人提供內容的。只有當有人決定釘住它們時，鏈接纔會保持不中斷，但由於沒有秩序，釘子註定會被到處抹去。
2019-02-14
IPFS問題-自負 #
IPFS正試圖做許多事情。IPFS的領導者是革命者，他們認爲自己比整個行業的其他人都要聰明。
他們首先提出了一個用於點對點分發不可改變的、有內容地址的對象的協議，後來又試圖用他們自己的半生不熟的解決方案（IPNS）來解決同樣的問題，這是一個例子。
其他的例子是他們以一種非常不具體的方式呼籲去中心化，他們過度的與以太坊的調情和他們永遠無法完成的永遠無法工作的/Filecoin/項目。
他們本可以專注於通過哈希值（不是說這實際上是一個好主意，但它有一些潛力）在點對點網絡上分配對象的基礎設施，但在試圖重新發明整個互聯網時，他們把一切都搞砸了。
2019-01-10
IPFS的問題-效率低下 #
想象一下，你有兩個IPFS節點，並且在第一個節點上有由你創建的獨特內容。從第二個節點，你可以連接到第一個節點，一切看起來都很正常。然後你試圖獲取這些內容。幾秒鐘後，內容開始出現，進度條開始移動，這很慢，非常慢，做rsync會快20倍。
進度條停止了。你調查了一下，第二個節點沒有再連接到第一個節點。爲什麼，如果那是我們試圖獲取的文件的唯一來源？這至今仍是個謎。你手動重新連接，進度條再次移動，停止了，你又被斷開了。你沒有重新連接，而是決定將第二個節點添加到第一個節點的 “Bootstrap “列表中。
我曾經試圖在VPS上運行一個IPFS節點，並在S3上存儲內容。有兩個S3數據存儲插件可用。在修復了其中一個的一些問題後，重新編譯go-ipfs，弄清楚如何從IPFS配置文件中讀取設置，創建一個init profile並再次重新編譯，我得到了節點的運行。它成功了。我的想法是在這個節點上託管一堆數據。數據將按需從S3獲取，所以從任何IPFS節點或網關都可以廉價而快速地訪問它。 IPFS開始每分鐘對S3進行數百次調用–如果我沒有在插件代碼中插入一些日誌語句，我是說在AWS的鉅額賬單到來之前，我不會知道這件事。很明顯，這是參與DHT的一部分。調整一些設置後，我的節點按照我的意圖變成了一個只聽不看的東西，但我不是100%確定它能作爲一個有效的內容提供者工作，而且我永遠不會知道，因爲內存和CPU使用率對我簡陋的VPS來說變得太高了，我不得不把它關掉。
2019-02-14
IPFS問題-動態鏈接 #
內容可尋址性很酷，我們都喜歡它，但我們也都知道，我們不能生活在一個沒有可讀和可記的名字的世界裏。IPFS從一開始就提出了IPNS，即星際名稱系統（名字確實非常酷）（也許是在IPFS的第一個想法之後的幾個月，這將表明這個問題是事後纔想到的）。
有人說IPNS的工作方式類似於Git頭和分支（這可能是Juan Benet在最初幾年大量重複的營銷宣傳的一部分，即IPFS是Torrents、Git和其他一些很酷的技術的混合）。然而，這仍然是一個遙遠的承諾。在過去的幾年裏，IPNS一直是一種非常緩慢的、不被他們自己的開發者所推薦的、無法使用的處理內容的方式，基本上只是一個從公鑰到對象哈希的指針。 建議使用域名和dnslink，這是告訴IPFS節點你擁有一個域名的方法，可以用來識別一個對象哈希值。那是可行的，但它不是承諾的去中心化的奇蹟，而且，它仍然只是一個指針。任何鍵值存儲、文件系統的數據庫都可以做指針。
在這裏，我並不是說，像互聯網上大量愚蠢的人那樣，IPFS應該支持動態鏈接，這樣我們就可以在上面建立網絡應用。不，我只對靜態內容使用靜態鏈接就很好，而對需要動態的東西繼續使用其他互聯網協議。
2019-02-14
爲什麼IPFS不能成功，再次解釋 #
2021-05-13 https://fiatjaf.com/b8e2f959.html 想象一下，有人想出了一個P2P內容地址數據共享的解決方案，這個方案將所有文件的內容存儲在網絡的所有計算機中。這不可能實現，是吧？太多的數據，如果你認爲這可行，那麼你就像一個BSV愛好者。
然後有人想出了一個主意：不把所有的東西都存儲在所有的計算機上，而只把一些東西存儲在一些計算機上，根據一些算法和給定的pub key來確定一個節點 上會存儲什麼數據。這仍然行不通，是吧？不管如何這樣分散存儲，數據還是太多，主要是激勵措施沒協調好，所以第一天就會內爆。
現在想象一下，有人說他們將做同樣的事情，但不是存儲全部內容，而是每個節點只存儲一個指針，指向每個數據實際可用的地方。這是否使它變得更好？幾乎沒有。這只是在轉移問題。
這就是IPFS。
現在，你在每臺計算機上的數據減少了，但在全球範圍內，這仍然是一個很大的數據。
沒有激勵措施。
而且現在你有一個尋找數據的問題。首先，如果你有一些你想讓全世界都能訪問的數據，你必須廣播有關信息，讓這個信息充斥着網絡–而且每個人都必須爲每一個可用的文件（或文件碎片）不斷地做這件事。
然後，每當有人想要一些數據時，他們必須找到知道這些數據的人，這意味着他們將用請求充斥(flooding)整個網絡，在peer之間傳遞，直到他們到達正確的peer。
你越是強迫每個peer存儲，運行節點和代表他人存儲數據的情況就越糟糕–但你越是不強迫每個peer存儲，你在全球網絡上flooding就越多，任何人真正得到任何文件的速度就越慢。
但是，如果每個人都只是把所有的東西都保存到Infura或Cloudflare，那麼它就能運行了，真是魔幻的“去中心化”技術。