大家好，我是牛靖宇，亦来云系统组负责人。之前在微信群里介绍过Carrier的基本情况，今天为大家分享一下Carrier最近的一些进展以及Carrier之上的一些应用场景。
在开始之前我先简单介绍下Carrier。Carrier是亦来云平台上的去中心化的通讯框架，为亦来云平台上的DApp提供通讯服务。讲到DApp，大家可能直接的印象就是运行在链上，但是亦来云通过Elastos Runtime可以支持DApp运行在链外，为去中心化的应用提供多样性的支持和丰富的形态。Carrier就是为这些去中心化的应用提供完全去中心的，符合区块链哲学的通讯框架。
讲到去中心以及区块链哲学，我是这么认识的。首先，Carrier是没有中心化的服务器为大家提供应用间的通讯服务的，它是一个完全自运行的网络，这一点和国内的QQ、微信，国外的WhatsApp、Facebook Messenger等这样的应用有着本质的差别。这些应用虽然都是IM应用，但都是通过一个中心化的通讯服务设施来承载的，并且由对应的服务商来运作这些中心化的服务设施。这些通讯设施不仅被应用于IM应用，比如QQ，腾讯同时也用它的通讯服务设施来支持IoT设备，Carrier因为没有中心化的服务器，所以也就没有所谓的服务商的概念。
其次，Carrier的通信在去中心的基础之上还有一定的匿名性，这种特征类似于区块链的匿名性，用户或者应用可以根据需要来保持一定的匿名性。同时，Carrier本身也采用了非对称密钥加密技术，节点间的通讯数据是透明加密的。每个节点的ID就是它自己的公钥，私钥自己持有，任何两个节点间的通讯数据只有这两个节点可以正常解读。另外，应用也可以将Carrier ID和DID关联，从而实现对节点身份的认证需求，如果大家对DID感兴趣的话也可以关注下亦来云的DID服务。
刚刚我们简单的对Carrier做了一个概要性的介绍，下面我们回到今天的主题，先跟大家分享下Carrier近期的工程进展情况。之前，Carrier已经提供了基本的点对点消息，点对点的数据报和流的支持，同时也支持了多路复用一些面向应用层的协议封装。近期我们的主要进展包括以下几个方面：
第一是更新了编译系统，从Shell脚本加Makefile的模式改为了CMake，对开发者而言更简洁易用；第二是社区一直对Windows平台有诉求，之前Carrier支持的Windows平台是缺失的，目前增加了对Windows平台的支持；第三是支持了组播消息，也就是类似于微信里的群组概念；最后一个也是社区提的比较多的文件传输，所以我们新增了文件传输的辅助API，同时支持断点续传。
在这些新的进展里面，先说一下文件传输API。关于文件传输，其实我们之前的接口可以很好地支持，只是我们没有抽象并提供专门的API来支持，需要开发者在点对点的流上自己实现文件传输功能，这次我们针对应用间文件传输的功能，提供专门的API，方便开发者使用。在API层面我们也为断点续传提供了相应的支持，如果开发者用这组新的API实现文件传输会比之前基于流的方式实现要简单很多。
另一个是组播消息的支持。组播消息可以支持一组Carrier节点间的消息广播，直观的概念就类似于微信或者像Telegram的群，但是因为Carrier是去中心化的设施，没有中心化服务器来缓存并转发消息，所以在组播消息的表现上和中心化的通讯设施提供的功能还是会有不少的差异，后面我们也会不断完善这方面的支持，争取为各种应用都提供良好的支持，从而满足不同场景的应用需求。
上面是我们的工程团队已经完成的主要进展部分，除了这些之外还有一些功能细节上的完善以及稳定性的完善，另外还有一些功能在开发中，比如离线消息，IPv6的支持等等。离线消息在去中心化的模式下是一个比较棘手的问题，我们的工程团队也在努力攻关解决这些问题，关于具体的版本计划还是以亦来云官网上公布的Roadmap的时间点为准，工程团队也是按照原定计划在进行中。到年底会再发布一个正式的版本，这个版本会包含上述的这些所有新的成果，如果有开发者想要提前了解和尝鲜一下，可以从Github仓库中获取最新的主干代码，自己编译去体验，也可以从我们仓库集成的Travis CI中获取最新的二进制包来体验。
接下来我们可以探讨下Carrier的应用场景以及如何落地。Carrier的定位就是用去中心的模式解决DApp间的通讯问题，而DApp的通讯需求可能会有很多的场景，在这里就探讨几个典型的场景。
首先，我想到的是去中心的IM，刚好前几天基于Carrier的ElaChat在我们社区引起不小的热度，也有很多社区伙伴已经体验尝试了一下。目前主流的IM应用都是基于中心化服务的，而在区块链这个去中心的世界里，我们从情感上都觉得需要一款去中心的IM应用，Carrier目前的功能就可以比较好的支持IM应用的开发，ElaChat团队也只在这个方向上做了一些尝试，前几天也在社区公布了他们阶段性的成果。一旦有了IM应用的核心功能，其实应用的想象空间还是很大的，我们也可以从微信、QQ这类应用里体会到这一点。
第二个方面是IoT，在这个方面之前也有提到过，中心化的IoT平台有诸多的弊端，比如对服务商的依赖、安全、隐私等问题。现在我们有一些合作伙伴包括社区的开发者也在探讨和尝试使用Carrier作为IoT设备的基础联网方案，包括台湾的Ioex团队也采用了Carrier作为设备组网的基础方案，并在之上构建他们的应用和服务，Ioex目前构造的是一个to B的模式，在to C的模式里同样也可以使用Carrier，比方在智能家居方面，欢迎有兴趣的的开发者和社区成员参与，一起在智能家居方面有所尝试。
第三个是泛的DApp通讯需求，比如我们的合作伙伴视九在机顶盒里和对应的手机应用中内置了Carrier，来实现远程的机顶盒的控制和操作，解决了老人家或者小孩在家遇到问题需要远程协助的问题。再比如目前比较有热度的去中心化交易所，Token的交易实现了去中心化，那么在交易过程中的交流怎么实现去中心化，Carrier可能是一个比较合适的方案来支持去中心化的交易所手机应用的交流通讯需求。
其他潜在的应用场景我们在这里没办法一一罗列，需要开发者根据应用在通讯方面的需求，看如何结合Carrier来实现，这部分更多的是需要社区和开发者发现更多新的闪光的点子。我们工程团队的目标就是支持好开发者的需求，能够让Carrier以及使用Carrier的更多的应用落地。
最后我想再说一点，Carrier作为一个去中心的通讯平台，有其优势，也有其劣势，世界上没有十全十美的人，同样也没有完美的技术方案。因为Carrier是一个去中心的自运营模式，完全没有一个中心化的服务器来辅助，所以Carrier提供的通讯能力、特性、表现上和中心化的通讯设施会有差异，这些差异并不体现孰优孰劣，只要我们用合理的方式使用Carrier，还是会给DApp带来丰富的想象力的。
来源：亦来云