 Okay. Hello. Can everyone hear me? Hi. Good afternoon. Thank you for coming. My name is Alessandro Segala. I work for Microsoft during my full-time job, but I also enjoy hacking with some really cool stuff. And today I'm here to talk to you about the Interplanetary File System, or APFS. This is a talk about the distributed web, but I promise there will not be any blockchain in this talk. So before we start, can I see quick raise of hands? Who has heard or used the IPFS before? So it seems like this is a new topic for most people, so let's see how we can learn about this. So what is IPFS? So the definition that you see here, this is actually my definition. It's not exactly their own, but I describe it as a distributed peer-to-peer protocol and network for accessing documents. There's a few things here, but you can think about IPFS as a sort of decentralized replicated peer-to-peer CDN. The concept of peer-to-peer is in opposition of the traditional client server method. As you can see here, this is the full extent of my illustrator skills. But in a traditional model, like most of us have been building apps forever, there is a centralized server or a cluster of servers, and all the clients connect to that server, and the servers serve the content, do all the processing, etc. In a peer-to-peer model, which is something that you might have heard before if you have used things like BitTorrent, which I've absolutely never heard, but every node in the network has the same documents, and every single node that is trying to access a document can request it from every other node in the network. So it's essentially think of you acting as a client, but also as a server at the same time. Keep in mind that peer-to-peer does not mean serverless. In fact, as you can see here in this graphic, there is a server in here. This is because nodes, clients can come and go, can join the network, can disappear at any time. They might or might not have the documents you're trying to share, and so it's important to keep one server up and running 24-7 as a seeder for your files that are in the peer-to-peer network. One particular characteristic of IPFS is that every time a node accesses a file, it also starts seeding it. So this means that the more popular a file is, the more people request that file, the more spread out throughout the network is and the more available it is, which also means that it becomes faster and that it's really, really, really hard to do a DDOS on IPFS, because as people try to attack the network, they request the files and they actually start seeding it too. So it's literally the opposite of what people are trying to do. Before we get into the next part, one important thing that I want to point out is that IPFS, when you think of this, you hear the name file system. A lot of people think that it's a sort of NAS. It's not. I actually think that that is the bad stuff about the name, but IPFS is not a NAS. You don't just upload your files into this network and then the network keeps your files forever. It's more of a CDN, literally. You just use IPFS to distribute your content, but you must always keep one node up with your data 24-7 if you want to make sure that there's always at least someone seeding your files. I'm going to go in a demo in just a moment, but before we get into that, there's another concept that I need to explain, which is the content IDs. So inside the IPFS network, files are addressed using their content ID. It starts with slash IPFS slash something. That something is simply fine a little bit. It's a sort of the SHA-256 hash of the file, and so each file in the network is addressed by its own hash. I can also request a folder. In this case, as you can see in the second example down there, in this case I'm requesting the readme file inside a folder, and that is the hash of the folder. The hash of the folder is calculated from the hash of every single file. It's not exactly the SHA-256. It's a little bit more complex than that, but we don't have a lot of time today to get into the actual details of the network. But these two addresses above, they actually point to the very same file. So if you request the first one, you're going to get the readme file by requesting the file directly. If you request the second one, you're going to get the readme file by requesting the file inside the folder. The biggest benefit of addressing content by its hash is that the network is tamper-proof. So if one of the nodes in the peer-to-peer network were to send tampered content, like medium-alicious actor that wants to do a man-in-the-middle and serve you modified content, then the client would be immediately able to understand that the file was tampered with and would reject that block. The other benefit of addressing content via the counter-IDs or the hash, but which is also a challenge, is that the content is immutable. So if you change, as you know, if you change even a single bit in a file, the SHA-256 hash of the file is completely different. So we will need to look into ways that we can make it possible to actually update a content that doesn't require changing its hash. Let's get into the demo right away and let's see how IPFS works. So I have my machine here and I have IPFS installed, and I can show that it's installed by running IPFS version. And the very first thing I want to do is run in an IPFS node inside my machine. So I'm starting it with IPFS demon. This should take just a second and it will start. Now it's ready. Let's open another terminal and let's request a file from the network. Most commands in IPFS are inspired by the standard UNIX commands. So in order to request a file, for example, the command is IPFS cat and then the address of the file. So let's request that readme file I was talking about a moment ago and you can see that the file is loaded. So this is me requested a readme and I requested it through the peer-to-peer network and some people somewhere in the world sent this file to me. I can also list the content of a folder. So this file is inside a folder and again the command is IPFS ls. And you can see that this is a folder. It contains a bunch of different files. Each file also has the hash of the individual file. Of course I can request a file inside the folder. So let's do IPFS cat. Inside the folder I want the readme file and you can see it's exactly the same file. But this time I access it through the folder rather than the file itself. We can publish documents on IPFS. So I have a folder on my desktop called Good Boys. You can probably imagine what's in here. And there's a bunch of files. So let's add IPFS, add one of these files to the network with the IPFS add command. You can see that my machine hashed the file and then publish it in the IPFS network. So now everyone in the world with this address can retrieve this file from my machine. I can also publish entire folders with IPFS add dash r for recursive and the folder name. And now publish the entire folder. So this is how you retrieve and add files from the IPFS network. Some of these things that I publish are documents like images that do not really work well inside a terminal. I don't think you can really look at an image inside a terminal. Thankfully there is a better way for that. And every single IPFS node, every time you start an IPFS demon, inside your machine you also get a gateway that you can access through a web browser. So the gateway is always available in localhost 8080. And I can type an address here to request it. So I'm going to request this folder that I just published. And you can see the list of files. Here's one Good Boy and there's more here. Not only I can publish files and documents and pictures, but I can also publish a hierarchy of files. So inside here I have a folder and I can click on the folder and oh, look here. Instead of listing the files, this folder had an index.html file and I can use this to publish more than just a list of files. If I look at the contents of the folder, you will see that there is an index.html and this file inside is linked to an image that was in the directory one level above. So even though every file is identified by its hash, when you put a file inside a folder you can also reference files by their name and every single path as long as it's relative can work. When I say as long as it's relative I mean you cannot start with a slash, but you can start with a period or just the path of a file. So let's go to the next step. So if you're thinking like I'm thinking, when you saw that I can run index.html files and they're actually rendered, the next thing your mind is going to is Jamstack applications. I think that Jamstack apps are quite familiar concepts for many people in this room. Those are apps that are built with Jamstack means JavaScript, APIs and pre-rendered markups. They're very common right now when you're building an app, for example with React, Views, Veldt, Angular, etc. The app is completely static. There is no server-side processing your app and the app is usually served through some sort of object storage like AWS S3 or Azure Blob Storage and then it's served through a CDN before that. The app can communicate with backend resources through normal REST call or GraphQL calls or GRPC calls if you want to really be fancy. And you can do a lot. If you think of modern Jamstack apps, well, Facebook is being rebuilt with React and it's going to be Jamstack. Twitter just republished their app as a Jamstack app. You think of Gmail, Outlook.com and a bunch of other apps. They're very, very popular. How is this relevant for us using IPFS? Well, we could obviously serve these apps through IPFS as well. So rather than having the apps stored inside object storage and a CDN, we use IPFS as a continuous distribution network. The APIs, as you can see, are still here. These don't have to be your APIs. You can, for example, interact with third-party APIs to provide value to your users, so you still do not have to manage a backend. And this is exactly what I'm going to show you in the demo. There is a demo application you can find on GitHub if you're interested in trying it yourself and the URL is there. So this demo app is a pretty normal application written using the Svelte framework. You could use React, you could use anything else, and it's compiled with a webpack. This application is configured to interact with... Imagine this was an enterprise application and this is configured to interact with the Office 365 APIs and it can show what's next on my calendar. There is absolutely no server-side processing that I manage, no API that I manage, but if I go to localhost 3000, you will see that... Oops, it didn't ask me to authenticate. I forgot to sign out. Anyways, if I had signed out, it would ask me to authenticate using Azure Active Directory, and then it would get permission to access my calendar, which is stored on Office 365. This is showing the next appointment on my calendar. Tomorrow I'm going to get lunch. This place is really going to get in Montreal. If you don't know that, it's great gnocchi. They're not paying me for saying this. I really love this place. This app is now running locally with just a normal NPM run dev, so there's a webpack server that serves this app. The next thing we want to do is, as you would normally do, stop the server and actually run NPM build to build the app and stage it. This should take just a second, and then my app will be inside the disk folder. You will see here that I have the index.html and the JavaScript and CSS. I can now publish this app into IPFS as excited as I did before. So IPFS add, dash, error, and the content of the disk folder. This app is published, and now everyone in the world can use this content ID, put it inside an IPFS gateway, and look at my app, and the very same app serves through IPFS. Again, this app does not have any backend, but I am using third-party APIs to do all the processing. So this is really cool, you're saying, but what about normal users? If I had to tell my business user, if I was an enterprise developer building an app for my company, and I had to tell everyone that in order to access the app, they have to download the IPFS application, run the demo on their machine, and there is a GUI for that, but still, then instead of typing a URL-like example.com, they would have to type the URL of gateway, and that very long string, which is the address. So thankfully, there is a solution for that. The first thing is that your users don't necessarily need to run IPFS on their machine, and they can use a third-party gateway. There are a few public gateways. Here you see two examples, gateway.ipfs.io, quote-unquote official one, and a third-party one served by Cloudflare at cloudflare-ipfs.com, and I am highlighting Cloudflare in particular, and we'll see that in a moment why. So by using this, rather than going to localhost 8080, you can go directly to the same, to these addresses, and you don't need to run a demo locally. The next thing is the URL is pretty complicated. Imagine telling someone over the phone that they have to go to cloudflare-ipfs.com slash ipfs slash qmy, et cetera, et cetera. This is absolutely not nice. There is a solution, however, and that relies on the IPNS, or the Interplanetary Nameservice, and on DNS link. So we can create a TXT record on a domain, and the TXT record can contain the address of documented-side IPFS. So, for example, if I want my app to be available on next.italipale.me, I will create the TXT record on underscore dnslink.theaddress, and that TXT record contains the content that you see here. Now that I've done that, anyone, even you right now on your laptops or phones, you can go to cloudflare-ipfs.com slash ipns, watch out for the N this time, and type the domain next.italipale.me, and that will load your app, the very same app. Then the very last step is how we can make this even easier. So the reason why I was talking about the Cloudflare gateway specifically is because they have a really cool feature which lets you map a domain name to the Cloudflare IPFS gateway, and it lets you visit the website directly without having to type cloudflare-ipfs.com. So let's look how you can actually bring that up into production and make it so your users can use that in a very simple way. So like I was saying a moment ago, this app is now available on cloudflare-ipfs.com slash ipfs slash the address, but I can also change this to ipns slash next.italipale.me, and it's a very same app. Because I mapped my domain to Cloudflare, I can actually use next.italipale.me. You can see here there is the txt record with the address, and then there is another CNAME that points next.italipale.me to cloudflare-ipfs.com. So if I go to next.italipale.me, I gain the very same app. The other thing that I wanted to show you is how you can actually move the next step, which is you don't normally, as I'm sure all of us know, we don't really recommend doing things on the developer machine, but if you want to do the build, then ipfs add error, and then you have to distribute the hash, update the DNS, et cetera. We can use continuous integration and continuous delivery, excuse me. So in this Git repo, where my code is hosted, which is public and you can take a look, this is the code of the application, I set up continuous integration using Azure Pipelines. I'm going to make a change, and for example change the title of the page, the only way where I'm using that, and I'm going to change it to next on my calendar. Committing the changes, and this should trigger the continuous integration immediately using Azure Pipeline. The CI will take a minute, so while the CI runs, I'm going to show you exactly what is happening inside the CI definition. The first step on the CI is to run npm install, excuse me, npm install, and then run npm build. This builds the application as if it were any other application. Then we can scroll down, and this takes the application and copies the compiled files to my IPFS server using SSH. This IPFS server is something that I have running 24-7, and it is running the IPFS demon using Docker. I'm not going to get into the detail of how you can set it up, but the instructions are in that Git repo that you saw a moment ago. You can see that I have an IPFS node that is running Go IPFS here. This node is currently pinning a bunch of different files. In the IPFS word, to pin a file means that you're always serving that file. Like I said a moment ago, every node in IPFS not only can request files, but can also see them to other users, to other customers or sorry, to other clients. Because of that, you might end up in a situation in which your node is seeding the entire word, or like a significant amount of data, so the IPFS demon can periodically do garbage collection. Instead, when you add the file using IPFS add, or when you pin it using the IPFS pin command, this file is pinned to your node and the garbage collection will never remove that. This is quite important when you have a server to make sure that your files are always served 24-7. Somewhere around here, in this long list of caches, there is also the app that I just built and that the CI has put the server and pinned it. The next step in the CI is actually the next relevant step is that it goes and automatically uses the Cloudflare API to modify the DNS the value of the TXT record and then points my users to the latest version of the application. For this, my domain is Austin on Cloudflare, if you have another DNS provider, you can do that as well. So the CI, let's see, should have run by now. And you can see here the CI was completed. It has built the application, staged it and updated the DNS record. And now if I refresh the page, oops, wrong page, you will see that the title changed from coming up on my calendar to next on my calendar. One other thing that I wanted to say is that I've been showing how you can use your own server, your own Linux VM to pin the files. There are actually some third-party services that offer IPFS pinning as a service. I'm not going to name names. Those are valid options. At the moment, they do not have any SLA. So I would still prefer, personally I still prefer having my own server maybe in addition to using third-party services. So now the application is live. The CI CD has run. It has updated the code. And it's running on this domain. And everyone in the world can just access it using a web browser and nothing else, nothing more. So you don't need to do anything fancy about IPFS of anything particular. So one of the question is, why would I want to do that? What are the benefits? I've highlighted some of the benefits before, but one other important benefit is that this can really scale. So I had one app, one static website that was deployed through IPFS and through Cloudflare, on March 13, 2019, in one day the app somehow got viral and the traffic spiked 5,060%. That doesn't mean 5,000 requests, but 5,060% requests compared to the previous day. My server that was sitting in those files had an impact on the CPU. So if you want to see how much the impact was, it's around 1%. So again, serving 5,000 more requests, the impact was essentially zero. Part of that, sure, it's thanks to the CDN that was doing caching, but as you know, a CDN also still needs to grab content from our region. And by using IPFS, I was able to really distribute the traffic really effectively. So what's next? The first thing is to be creative and think of ways of more and more things that you can do using a Jamstack. I'll show you before a moment ago this demo app. This demo app had no backend whatsoever and yet I was able to show my calendar as an example and make the app very interactive. I authenticated using Azure AD. Most organizations that are using Office 365 already are on Azure AD. The other alternative is Google Apps or G Suite. Chances are that if you're building an enterprise app, you can totally rely on authentication of one of those two. You can use those APIs to do a lot. You can store data on OneDrive. You can use third-party APIs for generated thumbnails, for sending emails, sending text messages, or whatever you want. And I guess the next question is could we actually get away without any backend API at all? Do you remember the image before that was still APIs even if we were using IPFS? Well, I would say that not quite yet. However, we are working in the distributed web. Some people that are much, much smarter than me are looking for solutions to that. However, I promise at the beginning I would not be talking about blockchain as I'm not going to say anything else about this. And so, thank you. And you can find the sample code on GitHub. My username on Twitter and GitHub is ItalyPaleL. It's like the beer, but rather than India, it says Italy. And I'm available for question here for the next five minutes, and then you will see me also the Microsoft booth if you have any questions.