 Can we start now? Yeah, OK. All right. Good afternoon, everyone. My name is Martin Baer. I live in China. And I came with my colleague Zhu Feng. She's sitting here in the front. So I will talk about Elastos, a project that, as you said, may blow your mind. Before I talk about Elastos, I want to talk a little bit about the Internet itself, the history of the Internet, how it was evolved, and how it came to be. So basically, the Internet was built on trust. When the Internet was designed in the 60s, 70s, it was kind of assumed that everyone who would ever get onto that network was a trusted person from some trusted institution, and we knew we would know who everybody is and we could trust everyone and there's no bad people that would ever be able to use this. So nobody thought about making the Internet in any way safe and build protections against bad people. So somebody at another conference gave a talk about IoT and he described the Internet as a coffee party. So people think the Internet is like a coffee party. Everybody is nice and polite, everybody is friendly, and nobody steals anything and nobody does bad things. Because of that assumption, because of believing that there are no bad people, no protections were built in and so now we have a problem that we cannot keep the bad people out. We have to deal with spam. We have to deal with denial of service attacks. We have problems with cookies. Cookies are being abused. Cookies are so bad. I don't know if you are aware of this here, but in the European Union, the European Union made a law that requires every website that uses cookies to have a message or notice to tell the visitor that we're using cookies and you have to approve that you understand what that means. I don't think it changes anything, but basically you have to think about that. We as engineers, we build something that is so bad that a government has made laws to warn the common people against the threats of what we built. And the same thing might be coming with IoT devices because effectively IoT made everything worse. IoT devices are so hopelessly insecure that really the only thing you want to do, the only thing you can do at this point is to try to just block IoT devices from being able to access the internet entirely. At Scale, the Southern California Linux Expo in Los Angeles, two weeks ago, John Holly gave a talk with the topic Good Fences Make Good Neighbors in IoT, and he was describing in graphic detail what you had to do in order to protect his network from bad IoT devices. I'll have a link to that talk in the slides. So are you familiar with the OC model of networking? Basically the OC model describes seven network layers. There's a physical layer and a data link layer which is mostly your cables, your Wi-Fi signals and so on. There's a network layer where you'll run IP and basically your internet connections. A transport layer where you have the network protocols, HTTP and SSL and so on. Session layer, presentation layer and application layer. So basically the important thing to understand is that the bottom layers are mostly hardware. The network layer and the transport layer partly are in the kernel, and the rest is in your application. Applications are taken care of those top layers. What's most important is applications are responsible for making their own network connections secure. So every application that is running is on its own responsible for making sure that it has a secure network. Your web browser is using TLS to secure the network with the web server, and your email client may use TLS or may not use TLS depending on how it's configured to secure its network connection. At every program, whatever you install is responsible for its own. And you have a TLS, SSH, PGP and different ways to secure different aspects of the network, and you sometimes use multiple combinations of those to get the job done. What is very important is that identification of communication partners, identification of people that you are communicating with is happening within the application. In email, for example, the decision who is sending an email, who sent you an email is made by you as a reader of the email and by the email program, by identifying the email address. And effectively, every application has its own user database. SSH is using the system database in most cases, but it could in theory use its own database. Most websites, web services that run on the machine have their own user database. Your mail server has a different user database. Depending on how it's configured, they all have a different source of what identities exist. I have an SSH identity, I have an email identity, I have a web identity, I have hundreds of different identities. Even though they're all on the same machine, they're all doing different things. SPAM effectively comes from the fact that there is no programmatic user identification. When I receive an email, only me as a reader can actually identify who is the sender of this email. And sometimes I can use the email address, but I cannot trust that email address. SPAM can fake email addresses. And the computer, the software has no way to be 100% sure that an email is sent from the person that it claims to be. Only I as a reader can potentially verify that, and even I as a reader can sometimes not even do that if I don't know this person very well and I know exactly whether they're going to send me that or not. The Nile of Service attacks are even at one level, a few levels lower. They happen at the network level before even they get into the computer. They just spam your computer with network packages. And there's nothing I can do on any machine to prevent that. Because by the time I can do anything about a bad network packet, the packet already is clogging the network because it's already gone through the network. I cannot stop the Nile of Service attacks at the source. I cannot stop SPAM at the source. So how do we get out of this mess? By putting user identification first. By creating an operating system that allows applications to be built on a user-first paradigm. So any kind of networking happens, before any kind of networking happens, the applications have to identify the communication partners and verify that this communication is what we want to do. So quickly, what is Elastos? How are we doing it? First of all, Elastos is a complete set of C++ API and frameworks. It's an operating system runtime that provides end-to-end security across a peer-to-peer network. And it's designed for containers and virtual machines, so it can run in any kind of environment. It can also run natively. And it uses blockchain for user identities and other authentication. Very quickly, the C++ API and frameworks are basically sandbox at the C level. So we allow app developers to write applications in C and C++, but we're still able to provide a sandboxed environment for those applications. They're running inside our sandbox. And we have a runtime inspection system that allows distributed apps to talk to each other. And in order to get there, we rewrote the whole Android stack in C++. I think about that one for a moment. Do you know how big Android is? The whole Android stack, the whole Android frameworks? I think it's about 10 million lines of code or something like that. So the whole thing has been rewritten in C++. When I first heard that, I thought these guys are either crazy or they're genius or both. So why did they do that? Performance, memory footprint. So we're targeting primarily IoT devices because there the need is the greatest. So we want the system to be small and compact and allow IoT developers to write small and compact and fast applications that don't need many resources. We want to enable developers who are at this point mostly used to writing Android applications to be able to write C++ applications in the same style that they already learned from writing Android applications. And we also want to enable porting Android applications directly to Elastos. We can run native Android applications and you can use Java to write your applications, but for a small IoT device, you wouldn't really want that. The distributed OS runtime. So basically, we're building a network on top of the internet and we're using peer-to-peer to connect the devices and nodes. And the idea is, yes, so we're providing end-to-end security across that network. And when the network connection happens, so, sorry, the key point is we prohibit apps from doing their own networking. So all the networking is going through the operating system and this is the important part. Every network connection is approved by the operating system. So applications no longer do their own networking and that addresses the problem. So now I'm going to explain a little more detail. So you've seen that slide before and when Elastos comes into the picture, it looks like this. So Elastos is taking over those middle layers, transport, session, and presentation layer pretty much and part of the application layer. And the applications really are mostly responsible for the user interface, for the application logic, but they're no longer responsible for networking. Networking is effectively the same in every application, so there's no need to repeat all that into every application. And so we are providing the networking as a service to the application and the applications themselves just use that. And so what we achieve by doing that is we're able to move the user identification away from the application layer. We're basically letting the apps specify that they want to talk to a certain identity. If I want to send a message to you, then I will have your identity in some form as a cryptographic key and then the application sends a request to the operating system that I want to send a message to this person and then the operating system will use the peer-to-peer network to find that identity. So there's no more IP addresses involved. I mean, yes, in the lower level, of course, there's IP, but for the applications, the IP address is no longer matter. The applications don't say, I want to talk to this IP address. They just say, I want to talk to this identity. The operating system goes out and finds the identity wherever it may be. It could be moving around from one machine to another. It's certainly going to move around from one IP address to another because depending on where you are, your mobile phone or your computer may have a different IP address. And once it found that identity and basically with a key exchange verified, but this is the correct identity, and also then both sides have verified that they actually approve for this communication to happen, only after that the application itself will be able to send a message to that recipient. And so this authentication verification happens in the beginning so that basically we can approve that we are communication partners, and then after that the operating system just checks that all these checks are in place. And as a user, I don't actually notice that there's something going on. The message just gets sent. So the connections are only opened after the user IDs have been verified and the connection has been approved. And so this way, we basically prevent any form of spam, denial of service attacks, worms, viruses and what have you because applications cannot just do what they want on the internet. And instead of having identities on the application level, we have a kind of network-wide system of identities that can be verified through cryptographic keys. Okay, continuing the runtime. So basically you can imagine if you're familiar with Java, the Java virtual machine, it's kind of like a Java virtual machine, but it's a C++ virtual machine and runtime. And so there's no need to break out of that virtual machine or in order to write native code. That's a problem Java has. You have occasionally a situation where Java runtime doesn't provide what you need and you need to write some stuff in C++ or C, and then you break out of this Java runtime and use a Java native interface to write native code. And so we don't need to do that because we already are at the C++ C level and so you can basically always stay within the sandbox in order to do everything that you need to do. Yeah. So it's kind of like providing a hybrid programming model where you can write in C++. You can write in any kind of runtime language, scripting language, Python, Ruby or anything else you like. You can write in Java or any other language, basically anything that can potentially compile to C, which is pretty much everything. And you get kind of like an Android-like programming environment and feeling like you're programming for Android, but you're doing it in C++ or in other languages. Now, where does the blockchain come in? I've already mentioned the blockchain is used for once for managing user IDs. So we're going to put the user IDs onto the blockchain and then we're using the blockchain to verify that these IDs are genuine and are the ones that we want to talk to. There are other uses for the blockchain. One example is digital asset management. So what we're doing is we're actually on top of just using the blockchain for our networking, we're also providing a blockchain development environment so you can write blockchain applications. But the key point is we're not only about blockchain applications. You can write blockchain applications. You can write regular applications that just do networking. You can write applications that don't do networking if you don't need to. You can write any kind of applications like in any kind of development system like in Android. And the blockchain is just part of the set of features that are being offered to application writers. And there's also coins to enable trading and to enable market-like applications and things like that. I want to expand on this thing, what we call digital assets. That's kind of a key point from a free software perspective because basically if you look at today, we have a few types of digital content and a few ways to share digital content. And one is free to share, which is GNU, which you probably all know, Creative Commons, where you can basically share and do pretty much whatever you want with it as long as you follow the license. And then there is DRM Free, which is... You can share it, but it's actually... You're not legally allowed to share it. I mean, it's like you can copy it, but then you would be breaking the law, but nobody's stopping you from doing it. And then we have at least entitled control by distributors, digital rights management or digital restriction management, however you want to call that, where the distributor controls what you do with the content that you receive. I don't know if you still remember the story when Amazon decided to delete the book 1984 from everybody's Kindle devices. And so you bought that book and you were maybe in the middle of reading it and then Amazon decides that we're terminating that license and we're just going to take it away from everybody. That's what DRM gives you and that's what we don't want. So with the blockchain, we can offer another alternative. The blockchain allows us to track ownership of a piece of digital content. And because we can track the ownership, that means we can allow the reselling of content, which enables this secondary market, which in the world of books used to be a big issue that when you buy a book, where you're allowed to resell the book that you bought or not, there have been lawsuits fought about that. And at least in the US it has been made very clear that there is no way that you can prevent anybody from reselling a book that they ever bought. I don't know how it is in Singapore, and in other countries it may be the same or worse. But the point is with digital assets on the blockchain, we enable the same mechanism where when you own, when you buy a piece of digital content, whether it's a book or a movie or something else, or a program, you are able to resell it because you can prove that you made that sale and the programs that read your digital content, they can verify on the blockchain whether you still have the permission to read it or whether you sold it and you don't actually have it anymore. The important part is that we're taking away the control from distributors to decide what happens with this content and we're giving that control to the consumer who is buying the content who can then decide who to give it to next. A bit about the history. Elastos development started around the year 2000 as a research project at Tsinghua University in Beijing and they were trying to build a smartphone operating system and when iOS and Android came out, they stopped working on that. Tufank may have some more details on that story. Then in 2012, development was restarted. It was then received $30 million funding by Foxconn and it reached beta status. So the $30 million were basically used to, at least as my understanding is, were used to rewrite that Android runtime. So we got Elastos running natively on a bunch of devices, beta status. That phone, I actually have it here if somebody wants to take a look later, running Elastos natively. Although now, I didn't mention that before, Elastos will not run natively on the phones. That's not our target at the moment, although it technically could, but we're actually building an Android and iOS runtime environment that you can basically install into your Android phone, into your iOS phone and then run Elastos apps within that environment so you don't have to flash your phone with a new operating system because nobody really wants to do that. So blockchain development started last year in 2017. There was a private funding round funded from Bitcoin investors and then in January we had an ICO and we got some more Bitcoins. And you can already see from the numbers the ICO was not done to get money in order to fund the project because we already had a bunch of money but it was more done to get mindshare and get people actually interested in the project. And so the roadmap is currently we're working on the peer-to-peer network. I've seen the reports from the developers that this is already now in a working state and there's work done with the development partners to build strategic applications that we want in the ecosystem. The blockchain part is being worked on. We're adding features like side chains so that blockchain applications don't have to put everything on the main chain. We're building a framework for web applications so that you can run apps within the browser and still have the same advantages and there's going to be the public minding of the ELR tokens will start at the end of the year. So that's pretty much it. If you download the slides I have trouble uploading them but I will try to get them uploaded before the conference ends or at least a few days after the conference then you can get all these links from the slides. The resource links is mostly GitHub and Elastos website. And yeah, with that I want to close just one more thing. I've been giving this talk at a few conferences now and everywhere I go I'm trying to assemble all the people who are working with blockchain in the free software community because I have a feeling that there's not enough free software in the blockchain world. It's dominated by investors, by ICOs, by token trading and there's not enough focus on development on free software, focus on the ideals that the free software community wants to share and so I want to get us together and at the end of this track tomorrow afternoon, after the last blockchain talk we're going to have a meet-up of all people who are interested in blockchain development to share what we can do as a community to strengthen our case in the blockchain world and in the world as such and also just mentioning there's going to be a blockchain track at the Hong Kong Open Source Conference in June and I'm also preparing one for the Cos Cup in Taiwan and I'm still looking for volunteers to help me with that. That's it. You have already seen this slide about me and Zhu Feng, as I mentioned she's here. She has been working on Elastos very, very early in the years 2003 to 2006 so she can tell you a little bit about the early history of Elastos and she rejoined the project this year as a product manager. Yeah, and there are links to the slides. So, questions? Yes? Is there anything about using Elastos do you have to change your mental model for, you know, how it treats network access? Yes, you will have to change your mental model as far as network access is concerned because you're no longer thinking about, say, the most common way to work with today is that you have some kind of URL and the URL specifies a host name it specifies a path it may specify a user identity and, or like an email address and so, and then you have to figure out okay, what kind of URL is this? Is this a web URL? Is it an email address? So, how do I send a message or is it an IRC address or something like that? How do I send a message to this person? And depending on what you want to support in your application then you have to write your your networking code accordingly you open a connection to this port and then you start sending your HTTP There are libraries for, of course, for all of these but there's a different library for each way there's a library for email there's a library for HTTP requests there's a library for sending Java, XNPP messages and so on and so, now you will have one library framework for networking and all you're putting in is a user or application identity and you want to connect with this particular identity and then you wait for the approval and then you get the socket to send the message and you write applications that the actual application or do we have to only use the last-door applications because your change on the networking so I'm just wondering Okay, there are two answers to this the question is, can you use or write regular Android applications? So for one, yes, you can still write applications in Java and you can write pretty much traditional Android applications as long as they don't do networking because the networking system is changing so if you want to run inside the Elastos environment you have to use the Elastos way of networking but the rest will stay the same and on top of that you can write your applications in C++ in the same logic and structure as you would do it in Android because we're basically duplicating that way of developing Yes? You mentioned using blockchain Is that public blockchain or are you using it your own? And if you're using a public place for fees? Okay, so the question is if we're using a public blockchain or if we use our own blockchain I'm not sure about the details here but what I understand is that this is actually flexible so we pretty much have our own blockchain ecosystem but we're working with Neo for the whole blockchain technology and so I'm not sure if we're using Neo's main blockchain or if we're using our own but basically we're also providing an environment for other people to write their own blockchain applications and so we're having at least one main blockchain where Elastos is running on and then lots of sidechains for different applications that don't need to be on the main chain so it's pretty complex and I haven't really looked into that detail yet because it's still evolving and it may change over time depending on what makes most sense Any other questions? What's the meetup tomorrow? The meetup tomorrow is after the last talk so I think the last talk ends at 2.25 so at 2.30 in the same room as the last blockchain talk so basically just look at the blockchain track at the end actually this is not on the official schedule but it has been approved by the organizers but they couldn't put it on the online schedule because they're too busy solving other problems but after this I'm going to go around and where I see the schedule printed I'm going to pencil in that we're going to have this event so people can see it I'm going to put it on the board downstairs and to spread the word if you talk to anybody about blockchain mention tomorrow afternoon to come here after the talk after the last one so that we can share and connect Alright, thank you