| This talk was part of an educational series in the Chinese Telegram that takes place every Friday. Guest: Jingyu Niu, Technical Advisor of Elastos. Hello everyone, I am Jingyu Niu, and I am in charge of the Elastos system team. We have introduced some basics of Carrier in WeChat groups before. Today, we are sharing the latest progress of Carrier and some of its DApps. Before I start, I'd like to briefly introduce what Carrier is. Carrier is a decentralized communication infrastructure on Elastos' platform and it provides communication services for DApps on Elastos' platform. When talking about DApps, people may assume that DApps run directly on the chain. However, Elastos Runtime can support DApps to run independent of the chain and Runtime support a variety of decentralized Apps. The purpose of Carrier is to provide a completely decentralized communication infrastructure towards blockchain philosophy for DApps. When talking about decentralization and blockchain philosophy, here's what I think. First of all, Carrier doesn't have a centralized server to provide communication service in between apps. It is a network that fully runs on its own, and it has a fundamental difference when compared with QQ, WeChat, WhatsApp, Facebook Messenger and many other similar applications. Although those apps are all IM, they are loaded through a centralized communication service infrastructure, which is run by its service providers. Those communication infrastructures are not only used on IM apps such as QQ, but also used by Tencent to support IoT devices. Carrier does not have centralized servers, therefore the concept of service provider does not exist in Carrier. Second of all, communication on Carrier is not only decentralized, but also anonymous to some extent. The anonymous feature is similar to blockchain anonymity that users or apps can keep a certain anonymity based on their needs. In the meanwhile, Carrier itself uses asymmetric cryptography technology to ensure that peer-to-peer network is transparent and encrypted. Each node's ID has its own public key, and its private key is privately owned. Communication data between two nodes can only be properly read by these two nodes. In addition, apps can link Carrier ID and DID together which authenticates the identity of nodes. Anyone who is also interested in DID should check out the Elastos DID service. Now that we have briefly introduced Carrier, let's focus on today's topic – the latest progress status of Carrier. Previously, Carrier was able to support basic peer-to-peer information transfer, peer-to-peer data transfer and streaming, and multiplexing protocol encapsulation for running Apps purposes. Our recent progress includes the following: First, we upgraded the compiler system. We changed Shell script and Makefile to CMake, which is more simple and convenient for developers. Second, there has been a high demand of a Windows platform from the community. Previously, we lacked a Windows platform supported by Carrier. Currently, we have added the Carrier support for Windows. Third, Carrier supports group broadcasting messaging which is similar to the concept of group messaging in WeChat. Lastly, we received frequent requests for file transfer from the community. We have therefore recently added assistant API for file transfer which also supports breakpoint resuming. Among the new progress updates, let's first talk about file transfer API. About file transfer, our previous interface could actually support it well. It's just that we did not provide a designated API and developers had to realize the file transfer function on peer-to-peer streaming on their own. This time we provided a designated API specifically for file transfer and made it easier for developers. We also supported breakpoint resuming on the API layer so it's much easier for developers if they use this new set of API to transfer files compared to the old streaming approach. Another update is the group broadcasting messaging support. Group broadcasting messaging can support broadcasting between Carrier nodes. It's similar to WeChat or groups on Telegram. The big difference is that Carrier is a decentralized infrastructure and there is no centralized server to cache and transfer messages. In the future we will continuously improve the support in this aspect to provide optimal experience for apps run in different scenarios. The above is the main progress updates that were completed by our engineering team. Besides that, we have also optimized certain function details and stability. In the meanwhile, there are also some other functions being developed, such as offline messaging, IPv6 support and more. Offline messaging is a tough problem in a decentralized world. Our engineering team is working hard on that. Please refer to the timeline in the Roadmap published on Elastos official website regarding the specific plan for it. Please be assured, our engineering team is progressing according to the original plan. A formal version will be released by the end of the year, and it will include all the updates mentioned above. If developers are interested in learning about it earlier, you can always visit Github to acquire the latest main codes and start coding to experience it. You can also get the latest binary instruction packet from Travis CI on Github. In the following, we will discuss potential apps Carrier can be applied to and how to make the landfall of those apps. The goal of Carrier is to solve communication problems among DApps using a decentralized approach. The communication needs from DApps will vary in many scenarios, and let's discuss a few typical scenarios. The first thing that came to my mind is the decentralized IM. Just a few days ago we had a heated discussion about Carrier-based ElaChat in the community. A lot of community members already experienced the ElaChat. Nowadays, the mainstream IM apps are all based on centralized servers. However, in the decentralized blockchain world, we all feel we should have a decentralized IM app. Carrier's current functions can well support the development of IM apps. The ElaChat team was on the right track and announced their progress in this matter in the community. Once the core function of an IM app is well developed, there's so much room for its growth. The mass adoption of WeChat and QQ is a great example. The second scenario would be IoT. We've mentioned before that a centralized IoT platform has many drawbacks, such as problems involving dependency, security and privacy to service providers. Currently, we have collaboration partners as well as community developers who are exploring the approach of using Carrier as a fundamental part of the network for IoT devices. The ioeX team already started using Carrier as part of the device network and building apps and services on top of that. ioeX is using the to B model. Carrier can also be used in the to C model such as smart home aspects. We welcome all interested developers and community members to explore Carrier uses in the smart home industry. The third scenario is the general need for DApp communication. For example, our collaboration partner Shijiu integrated Carrier inside of TV boxes and mobile apps in order to remote control the TV boxes. That means when seniors and or youth are at home and need help regarding the TV box, a remote assistance will be able to help them. Another example is the popular decentralized exchanges. Carrier might be suitable to support communication needs on mobile ends for decentralized exchanges. As much as we want, we can't list all scenarios that Carrier might be applicable to. It's up to the developers and community to come up with new ideas based on needs. The goal of our engineering team is to support the needs from developers, and make the landfall of both Carrier and Carrier-based apps. Last but not least, Carrier as a decentralized communication platform has its advantages and disadvantages. There's no perfect person in the world, and a perfect technical solution does not exist either. Since the business model for Carrier is decentralized, and there's no centralized server to interfere and help, it will behave differently compared to centralized communication infrastructures in terms of communication capability, feature and performance. Those differences do not necessarily mean one is better or worse than the other. As long as we use Carrier properly in a reasonable way, there's so much we can imagine about Carrier-based DApps. | 
