写了一个在线的网页，实现了只需要输入Matters的文章地址，即可自动列出墙内对应的可访问的IPFS链接，在线转换地址是: <https://matters2ipfs.js.org>, 代码也全部开源在Github上了。
由于本文主要面向大陆读者，所以本文使用简体字。
主要有两个功能：
- 最常用的就是把Matters的文章地址转换成IPFS的公共节点的地址，操作很简单。只需要进入https://matters2ipfs.js.org（建议收藏下这个地址，下次备用）,在输入框里粘贴Matters的文章地址，然后点击Convert 按钮即可自动获取到该文章对应的IPFS公共节点地址列表，并自动检测你当前网络环境对列表里的每一个地址的可连接性，然后你就可以随便选择一个显示为 online 的链接地址，点击右边的复制按钮即可复制对应的IPFS地址。 （注意：这里的可连接性是基于你当前网络的，所以如果你正在使用翻墙软件，最好断开翻墙软件或者在别的未翻墙设备上打开https://matters2ipfs.js.org进行转换IPFS地址的操作。这样才能准确测试大陆网络是否能访问某个IPFS地址。还有小部分情况是：大陆网络可以访问通，但是这个地址被微信封了，这种情况的话，就只能换个其他能用的链接再试试了）
- 还有一个功能就是Matters2IPFS在转换IPFS地址的时候，会自动生成一个地址，进入这个地址之后会自动开始扫描该文章对应的IPFS可用地址，你可以选择把这个地址贴在文章的评论区，这样别人就可以随时点击链接进去查看这篇文章对应的哪个节点地址是可用的。你可以在Matters2IPFS的最底部看到这个地址和复制按钮。
最后说两句，分享Matters的IPFS地址文章有个问题，就是IPFS地址的内容只有文章原文，没有评论内容，甚至连原文链接都没有（这里我想建议Matters在生成IPFS内容的时候，专门加一个原文地址链接在里面，这样即使别人看到的是IPFS内容，也可以链接回Matters参与讨论）。Matters的评论区质量这么高，但是分享出去IPFS地址的文章，别人却找不到原文入口，也就不利于促成更多的讨论了。
欢迎在评论区提建议，投食MAT,Like或在Github上提pull request
from https://matters.news/@deserve/matters%E6%96%87%E7%AB%A0%E7%8E%B0%E5%9C%A8%E5%8F%AF%E4%BB%A5%E4%B8%80%E9%94%AE%E5%9C%A8%E7%BA%BF%E8%BD%AC%E4%B8%BA%E5%A2%99%E5%86%85%E9%93%BE%E6%8E%A5%E4%BA%86-zdpuB1bvMnsAr4APk12FmdRxcqMaEsRo46vKE7p6Arvsg4YiF
-----------
把被封的网页地址转换为IPFS gateway地址的转换器csobot
之前听到网友有个需求：给出一个网页，把它传到IPFS，并吐出 IPFS gateway 地址，方便传播。
现在这个功能来了！
csobot，将帮助您完成这项工作 :joy:
这个机器人在Matrix平台提供服务（可能大家比较陌生，但为了实践去中心化精神，我开始减少使用中心化应用了）。
如果你下载 Riot.im 客户端（iOS，Google Play，F-Droid 和桌面版），注册登录之后，点击下方的 + 按钮进入房间：#csobot:matrix.org
在聊天框里输入：
ipfs-add <url>
稍等片刻，即可得到5个该网页的 IPFS gateway 网址啦~
Riot.im 也提供web端（Riot.im 只是 Matrix 平台的一种客户端）：https://riot.im/app
该房间免登录即可进入，若互动则需登录一下）
目前为初期功能，欢迎提需求和建议~（目前只会下载该网页本身，不会延伸下载第三方资源，所以有的图片若来源于别处则不会显示）
顺便强调一下 Matrix，如官网所述：
是一种开源的、安全的（端对端加密）、去中心化实时通讯网络架构。它能让你
像发邮件一样联络到对方，却不必要求使用统一的（客户端）应用；
可以自主选择你信任的服务器来提供通讯服务（也叫「邦联式」）；
端对端加密级的保密性；
基于web的 HTTP API，保持开放性。
（更多内容将另文介绍）
Happy hacking
from https://matters.news/@uglybull/%E4%B8%80%E4%B8%AA-ipfs-%E8%BD%AC%E6%8D%A2%E5%99%A8-csobot-zdpuAyaW4TNhgGVwJpbbvuNgiS3Cs4WPL5XznNhJzKbqMrY2Y
-----------
如何使用自己的IPFS节点
在Matters推出自己的桌面版本之前，用户也可以下载IPFS生态中的工具，通过自己的节点浏览IPFS上的内容。尽管使用起来还很麻烦，还是推荐给有兴趣的朋友玩玩看。
下载本地节点
- 在这里下载自己操作系统对应版本的ipfs-desktop，一个封装了IPFS节点的简单桌面UI。另一个选择是Siderus Orion，和ipfs-desktop类似、都可用于文件分享，少了工具栏菜单，但是多了些文件管理的界面。
- 安装并启动程序。可以看到自己与多少临近节点相连，也可以用于传输文件。启动后，IPFS节点将会在本地8080端口打开一个http gateway。
安装浏览器插件
节点UI只是用于控制文件传输，但是无法浏览html文档，所以我们还需要一个浏览器插件，让浏览器渲染IPFS传输的html数据，从这里下载，支持chrome与firefox。
安装浏览器插件后，在IPFS节点运行状态下，插件会将所有包含 /ipfs/ 的链接跳转到本地8080端口，通过本地IPFS节点获取数据。这样打开Matters的公共节点文章url都会转到本地节点，也可以通过 http://127.0.0.1:8080/ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/ 访问英文版维基百科。
from https://matters.news/@guo/%E5%A6%82%E4%BD%95%E4%BD%BF%E7%94%A8%E8%87%AA%E5%B7%B1%E7%9A%84ipfs%E8%8A%82%E7%82%B9-zdpuAsoEg4nrL4j5XvZVvj2YpFkJtWpAZ9fbAXR2E9YdDwgia
IPFS開發者大會記錄
Matters正在建立一個分佈式的作品發佈网络，與其他分佈式应用一樣，核心問題是數據的存儲與傳輸。
IPFS生態中提供了一系列通用的工具和協議，用於建立各種不同類型的分佈式應用，使得IPFS成為了許多分佈式項目關注的重點。
這次與會的項目種類繁多，比如工廠中的物聯網、docker image分佈式分發、分佈式的npm與Guix、以太坊+IPFS域名管理、分佈式身份認證等等。我們也通過世界各地一百多位開發者，一窺分佈式技術與生態的進展。
介紹IPFS的基本結構與用法，讓與會者有基本的共識。
IPFS拆分下來，大體可以看做兩個子項目，IPLD與libp2p。
一般通過加密算法驗證的系統，數據都會存儲在通過哈希算法（hash）構造的樹狀結構中，被稱作哈希樹（hash tree，或默克爾樹 Merkle tree）。IPLD定義了數據之間相連的通用方式，負責建構、驗證及調取哈希樹，通用於以太坊、比特幣、git等數據結構。
libp2p則是IPFS之外應用最廣的一個子項目，從邊緣運算到新型的區塊鏈項目，都可以看到它的影子。libp2p主要負責處理客戶端之間通過不同端口和協議相互連接。這一部分原本非常繁瑣，而libp2p在不同的協議和算法之上建立了良好的抽象層，極大簡化了開發過程，也降低了不同協議之間轉換的成本。
除了workshop形式的課程外，三天的大會中有許多lightning talk，簡短地介紹不同的分佈式項目。此外，還有許多不同形式的分組討論，以頭腦風暴和hackathon的方式，理解或者解決某個具體問題，是與世界各地高手一起協作的好機會。
有一次我參加了DHT（distributed hash table，分佈式哈希表）的小組，同組的正好有OpenBazaar的開發者，向其他人很詳細地介紹了DHT的運作方式和局限。DHT是個分佈式key-value數據庫，也是“分佈式”的核心。目前IPFS採用的是Kademlia算法，簡單直接、容易實現，但是也有一些問題，比如單個文件訪問評率過高會讓部分節點過載。Coral DSHT算法的一些設計可以解決這個問題，也會很快引入到IPFS中。
另一次參加了關於動態數據的討論，同組的是radicle（一個非常酷的項目！）的開發者和IIT Bombay的CS教授，一起討論目前IPFS處理動態數據上的局限及可能的改良措施。目前IPFS中的動態數據，主要是通過IPNS提供指針，指向不同的IPFS哈希值，并由IPNS發佈者私鑰簽署驗證。但目前IPNS的更新速度非常緩慢。解決IPNS效率問題的一個方案是整合進PubSub機制，目前已經開發完成，還在測試之中。
從很多更有IPFS開發經驗的團隊那裡，我們也了解到了IPFS當前的其他局限，之後的計劃與設計中也會更加留心。
一個是網絡地址轉換（NAT）。當節點在一個內網中時，節點的IP由內網的路由分配，與外部其他節點的聯通需要轉換IP地址。但是目前IPFS的NAT功能尚不夠完善，特別是在需要穿透多層路由時，有時無法連接上其他節點。
另一個問題是內置的匿名機制。節點最後相連仍然需要通過IP地址，所以目前DHT中也是可以看到其他節點的IP的。一種解決思路是通過Tor或者I2P進行傳輸，與其他暗網一樣掩蓋用戶IP。但是這樣的就會犧牲掉傳輸性能，特別是對於Tor。這一部分的功能開發剛剛開始，但應該比較容易修補和整合。
不過關於匿名機制，葡萄牙的一位開發者開發了p3lib，提供了另一個思路。p3lib不是去掩蓋IP，而是去混淆不同節點想要獲取的數據包。這樣監聽者雖然能夠看到節點的IP，但是無法知道哪個節點獲取了什麼數據。這個方案目前已經可用了，並且似乎效率不錯。
IPFS camp的與會項目中，像Matters這樣直接面向普通用戶、解決日常問題的項目占極少數。大部分項目仍然很“技術”，要麼面向開發者、解決開發過程的問題，要麼是從已有的技術出發、暢想能夠實現什麼。這些項目雖然能夠推動分佈式技術本身的發展，但是本身很難在市場上立足。
雖然對於每個思考過網絡結構的人，都知道分佈式網絡會帶來更好的未來，但是如果分佈式網絡無法提供中心化網絡沒有的功能，市場仍然沒有動力去完成這個轉變。所以在一個unconf環節，我們幾個人在一起頭腦風暴了一下哪些場景中分佈式網絡必不可少。
大家都想到最顯著的場景是突破信息封鎖，及保證信息的保存。比特幣的流行和黑市交易以及跨境轉賬是分不開的，也算需要突破金融機構的封鎖。隨著各國政治獨裁與民族主義的興起，能夠更好保障信息自由和安全的技術會更加重要。Matters也是因為這個原因決定打造分佈式應用。
另一個巨大的應用場景是物聯網。這次看到的項目中，數據規模最大的當屬Actyx，用IPFS解決工廠中物聯網的問題。因為在工廠中有大量機器相互協作，並且有強烈的電磁場干擾，用中心化的路由和服務器既浪費帶寬，又容易被屏蔽。於是這些機器之間直接相連，通過IPFS進行高效快速的互動。
類似的場景還有很多，自動駕駛是快速湧現的一個。自動駕駛的場景中，每一條車流都是一個天然的計算機集群，相互之間需要交流與互動，天然適合形成無線網狀網絡。這一方面可以降低信號延遲、加快反應速度，另一方面可以節省整個地區所需要的信號帶寬、降低開支。雖然中心化架構仍然是大部分工程師最熟悉的方案，但有一些自動駕駛公司已經開始試驗分佈式網絡了。
另一個場景是局域網。分佈式網絡在沒有互聯網運營商提供服務時，仍然可以運作。在大規模集會或者突發災害中，會成為最可靠的信息通道。現在berty等分佈式即時通訊項目在通過libp2p搭建這樣的網絡。Nodle這樣的項目則更進一步，將區塊鏈加入到流量分享之中，等於讓物聯網中的每個設備都成為了一個微型的互聯網提供商。
另一個大家討論到的問題是，分佈式項目如何生存。畢竟，中心化的平台持有了所有的數據與權力，不管是從數據間接獲取利潤，還是從用戶直接獲取利潤，都相對容易。分佈式項目則會難很多，團隊如何生存就成了很大的問題。
這次到場的qri項目，為分佈式項目的生存提供了一個範例：讓軟件開源，并保證分佈式情況下可用；同時提供付費的中心化服務，用以增加效率，或者提供其他分佈式應用本身無法滿足的功能。
短短幾天下來，我對於IPFS團隊的能力和動機有了很多信任。Protocol Lab集結了一批分佈式領域有信仰、有能力的開發者，相信未來的網絡該是、也會是分佈式的，並聯手一步步把這個未來變成現實。
因為Filecoin的成功，IPFS社區已經開始有投機者出現，但總體還是維持了友善和純粹的技術氛圍。Protocol Lab的團隊本身也還沒有多少變現的想法，包括Filecoin獲得的資金也都依協議鎖死在Filecoin本身的開發上。
過去大半年我們在Matters網站上進行的牛刀小試，並未發現太大問題。但是下一步客戶端的開發，則一定會觸到IPFS的瓶頸，需要更多依賴和參與IPFS社區。Matters曾與IPFS團隊有過初步聯繫，這次也和IPFS瀏覽器部分的負責人專門討論了客戶端的計劃。他表示，因為IPFS團隊對中國的網絡環境了解有限，很需要我們來提issue，他也願意來推動Matters所需要的優化。
這三天初識社區，比較全面地了解了IPFS的進展，也建立了一些聯繫。客戶端的設計、後續與社區的協作，相信也都會因此更加順利。
from https://matters.news/@guo/ipfs%E9%96%8B%E7%99%BC%E8%80%85%E5%A4%A7%E6%9C%83%E8%A8%98%E9%8C%84-zdpuAmxB7trH3G78pgfLr4bDBhgA2mWJHWPP5XHog6CywrrLC
----------
從網站平台到分布式網絡
Matters平台雖然經歷了重新設計與開發，但是產品邏輯並未改變。平台仍是一個傳統的網頁，用戶仍需經由域名服務器查找到Matters服務器IP，再與服務器之間通過HTTP建立連接。盡管每一篇文章都已經發布至IPFS，囿於網頁形式，用戶仍然受制於中心化服務，用戶信息和金流體系也都還存儲在中心數據庫中。
但在重構的過程中，我們開始了分布式網絡的准備與鋪墊。Matters網站會持續作為內容發現的中心化窗口， 探索不同的內容發現與分潤的方式；與此同時，這個窗口會通向更大的網絡，任何人都可以加入，建立自己的窗口與社區、擁有自己的數據與回報。
接入一個分布式的網絡，意味著用戶需要下載一個客戶端，不管是以桌面程序還是手機App的形式。對於互聯網，這是網頁瀏覽器；BitTorrent或者eDonkey網絡，這是迅雷、電騾、快播等客戶端；對於比特幣或者以太坊，這是電子錢包。
對於Matters，這個客戶端需要讓用戶能夠不經中心節點交易、瀏覽多媒體網頁，讓創作者自主創作、打包、定價、分發與分潤。通過分布式賬本技術，我們能夠將創作者與讀者直接相連，既能像BitTorrent一樣高效地分發數據，又能像Amazon等中心化的服務一樣維持一個良性的版權生態。長遠來看，這個客戶端也需要和諸多快速興起的分布式內容庫聯通，讓用戶能夠隨時調取屬於全人類的共同知識庫，不管是維基百科、科研數據還是研究論文。
在Matters網站繼續進行迭代的同時，Matters工程團隊將會著手試驗這樣一個客戶端，從桌面版開始。盡管具體的產品邏輯和形態還在討論之中，技術層面已經有了不少線索。分布式存儲功能會由目前已經投入試驗的IPFS提供，而分布式賬本功能則會是目前相對成熟的區塊鏈形式（與合作伙伴Likecoin聯手）。同時，我們在原型階段會采用Electron.js平台，以便復用網站平台中成熟的UI與業務邏輯代碼。
新版上線之前，我們已經將Matters所有文章重新發布至IPFS，一方面調整了版式，另一方面對圖片也進行了分布式存儲。同時，我們也重新設計了文章鏈接：文章鏈接末尾長度為49的字符串，是文章元數據在IPFS中的哈希值，包含文章的作者、發布平台、文章指紋等信息。例如，用戶可以復制文章的元數據哈希值，替換到以下鏈接（或者任何IPFS節點）中並打開 ”https://ipfs.io/api/v0/dag/get?arg=${哈希值}/author”，就可以看到作者的相關信息。這意味著，我們設想的桌面版本可以不經服務器，直接打開Matters文章的鏈接，調取作者與內容數據。
Matters設想中的分布式客戶端架構。綠色部分是分布式的核心功能，黃色部分是中心化的附加功能。客客戶端通過IPFS與以太坊實現核心功能，而搜索、推薦等本質上中心化的功能則作為附屬，依舊由Matters服務器提供。GraphQL負責整合遠程與本地模式，讓應用在能夠在連接服務器與斷開服務器之間切換。
不過，這裡的構想僅僅是大致脈絡，產品邏輯也還在探討之中。一個能夠支持版權的分布式網絡是一種嶄新的交互形態，技術與設計層面都有許多未知需要摸索。我們希望與用戶一起來定義這種全新的交互，為中文網絡世界提供更可靠的傳播工具和更合理的游戲規則。
盡管分布式網絡有潛力帶來一個更加穩定、開放與公平的賽博空間，對於能夠選擇中心化服務的單個用戶，分布式應用並不一定帶來體驗的提升，這是分布式應用項目的難題。但在特定的應用場景中，分布式網絡是不可替代的工具，正如跨境轉賬之於比特幣、文件共享之於BitTorrent、物聯網之於無線網狀網絡。
Matters設想的內容與作者的分布式網絡，甚至在全球互聯網割裂為國家局域網時，仍能正常運作；但在網絡信息相對自由的今天，我們的產品不僅要解決技術問題，更要有新穎的商業模式和多樣的應用場景，才能與傳統互聯網產品競爭。
這些問題需要更大範圍的論證與不同領域的思路，問題的答案也該由社區共同決定。所以，Matters的產品與工程團隊會在開發之余，以這樣日志的方式向大家同步最新想法，希望以此激起討論和暢想，更希望獲得社區中各路高手的協助。既關乎技術路線，也關乎產品形態。
在你的想像中，這樣一個分布式網絡需要什麼樣的工具，又有什麼樣合適的應用場景？
from https://matters.news/@guo/%E5%B7%A5%E7%A8%8B%E6%97%A5%E8%AA%8C-3-19-%E5%A6%82%E4%BD%95%E5%BB%BA%E7%AB%8B%E5%88%86%E5%B8%83%E5%BC%8F%E7%9A%84%E7%89%88%E6%AC%8A%E7%94%9F%E6%85%8B-zdpuB3c76Te7qwTzvmoNSNHCiDSrcQq4QB4rcKSN5hewExKto
No comments:
Post a Comment