【IPFS应用开发】IPFS原生应用 IPFS原生DAPP

本系列文章是针对 https://blog.csdn.net/weixin_43668031/article/details/83962959 内容的实现所编写的。开发经历包括思考过程、重构和推翻重来。

一个基于IPFS的原生Dapp

看似一个普通的网站：但他已经成为了一个原生的IPFS应用。
https://github.com/bill080307/VideoShare


http://ipfs-gateway.dlimba.top:8082/ipns/QmUnZTQFJCd573goUHECvkG63UdAW9CTgZAMvp8EkGnMmJ/
截止2019年底，网上介绍IPFS网站，或者IPFS应用的文章很多，但是我还没见过一个完全原生的IPFS应用，从CryptoKitties到百度莱茨狗，从到DTube到，他们是DAPP，他们的业务数据确实已经上了分布式区块链技术，但是执行程序是传统单点式的，执行程序不在链上。数据在链上，但是数据所对应的显示单元、贴图，该如何显示不在链上，这就导致如果服务器挂了，仍然无法使用这个所谓的DAPP了。如果只是将数据放到分布式账本上也叫Dapp，那就太小看Dapp中的D(Decentralized)了。
看似这是一个普通的视频网站，但实际运行除了ipfs节点无需其他服务软件了，当然把网页显示到屏幕上的浏览器还是需要的。

Dapp (仅数据)

一般定义
一般对于Dapp的定义是，运行在分布式网络上，参与者的信息被安全保护（也可能是匿名的），通过网络节点进行去中心化操作的应用。
以太坊定义
以太坊定义智能合约/Dapp是一个交易协议，根据区块链上设定的条件来执行的一个合约或者一组合约。
–百度百科

对于大多数人来说这类Dapp早就接触过了，比如

百度莱茨狗

CryptoKitties
这些Dapp、D游戏、D软件确实做到了数据分布式(D)，采用以太坊作为数据库就完美的解决了数据分布式的过程，但是并不能称之为【原生】，因为对于一个应用APP来说包含程序和数据2部分，他们没有做到应用的分布式。通过浏览器打开的Dapp，仍然需要访问服务器的index.html作为应用程序的入口，Dapp的程序部分没有接入到分布式网络中算不算是一个真正的Dapp。当服务器不可用时（比如服务器宕机、域名解析错误）程序部分就无法使用，光有数据也没法使用Dapp了。

DTube主界面
DTube 和 YouTube的界面很像，有未来的YouTube之称，但是他仅仅是将大文件存放当了IPFS上而已，网站本身并不是分布式的，只是大文件传输时用了IPFS技术。

原生Dapp

对于仅将数据存入分布式账本的应用而言，原生Dapp是把应用的程序和数据都放到分布式账本上。在编写过程中用到了一些传统架构下的程序用于辅助，这些辅程序并不破坏原生Dapp的运行，用辅助程序只是为了让原生Dapp更加方便、稳定的运行和使用。
我的应用 https://github.com/bill080307/VideoShare 相对于以太坊寸土寸金的地盘，选择ipfs这种分布式的储存方式，使用nodejs作为开发语言，编译出来的程序部分js可以放到ipfs上，通过IPFS网关直接在浏览器中打开运行。只需开启一个ipfs节点就可以程序本身和数据了。

播放页面 http://ipfs-gateway.dlimba.top:8082/ipfs/QmPh5RHFtxrKBx7b8YDr3y72cycjmhFtHiryafz7jeeEws

原生Dapp的缺点

真正做到分布式应用的程序很少，当然缺点也不少。
难以做统计，在我这个应用中无法做到统计播放次数，这是因为分布式架构引起的，采集播放数据固然需要中心化。如果在我分布式应用中嵌入如【站长流量统计 - 友盟+】可以实现，但是只能统计部分，因为我的原生Dapp是可以在没有互联网，仅有内网的情况下运行的，这部分播放无法连通中心化的服务器。
更新迭代困难，我作为发布节点，通过ipns已经更新的记录，但是全网想要同时收到新版本是不可能的。几分钟，几小时，甚至几天，才能完成全网程序版本的更新，他们的更新就像社交圈，ipns记录通过一传十，十传百的方式扩散更新。