 My name is also Exeq, as most people know me on GitHub. So I'm going to talk about Mango, which is making Git fully decentralized. And what does that mean? It puts Git repositories onto Ethereum, Swarm, and IPFS. Just a quick note about what Git is. Git is a version control software where most developers keep their source code, and they make changes to their source code, other people can track these changes and contribute changes. So the first thing is about Git, as it was created roughly 10 years ago, and it was created with decentralization and distributed systems in mind. However, 10 years ago, decentralized systems weren't ready. So you couldn't do this. You had to use a central part to Git. However, today, we have decentralized systems in place. We have Ethereum, IPFS, and Swarm. So this is the time to accomplish the goal of Git. Well, the first thing is why do I care about Mango and why do I care about, sorry, why do I care about Mango and why you should also care about Mango? There are a couple of reasons. You don't really want to trust a central repository with all your data. They could take it down. And you want more security than that. There's a very important fact that you get by default if you use Mango. You get proof of existence of your code. So whenever you push your changes or your code, is it better now? So whenever you push changes to your code, it will be stored on the blockchain as well. And because of that, you get the timestamp according to the blockchain. And you can prove that your code with all its content existed at that point of time. You can see that's very important because you can prove in case of legal issues that you were the first implementing that and you have the prior art. And that's really important in the open source software. Another really good use for Mango, which Git cannot really do, is storing large files. So Git just stores large files as a single blob. And whenever other people copy your Git or they make changes to that or they store other files or they change the file, it will be a brand new, entire blob. So if you have a file of like 10 megabytes, which is the solidity compiler, for every new compiler version, you have the full file. Currently, the solidity repository is roughly 100 megabytes in Git just for the compiler versions. With using IPFS or Swarm, you have deduplication. And whenever you store these files and use it in Mango, only the differences are stored. This is something many people don't know about Git. And the last really important point is Ethereum, as a cause, is building decentralized systems. The whole source code of this cause should be available to decentralized systems. The last photo. So what is Git itself? Git is a content addressable file system. What is Swarm? It is the same. What is IPFS? It is the same. There's a tiny bit of difference, though. Git is working on your local system. What other two are working in a global decentralized way? So you see, it makes sense to move your Git repos to either Swarm or IPFS. This is something many people have seen. Git looks fairly complicated. People mostly know a few commands, and they get afraid, they delete stuff, and they start from scratch. I'm going to show you a few tricks, or just try to explain how Git works internally. And that will help you to understand how Mango works. And don't be afraid, it won't belong. So in Git, everything is an object. And every object has an identifier. But this identifier is a SHA1 hash. So in this example, the first one example, I'm just putting some data into Git, and you get back the identifier. And of course, once you notice identifier, you can print the details. So there I just loaded a file, which is the content, hello, Ethereum, hello, Shanghai. On the file system, all these data blobs are stored in a compressed format. OK, so now I have data in Git. And the second thing I need is the file name for that data, and probably permissions in some other details. So the second object in Git is called trees. Creating a new tree is simple. You use the identifier of the data, and you set the file name next to it. And as you see, printing this object works the same way as previously. OK, at this stage, I know what my data is. I know what the file name is. But I don't know who created that file and when it was created and why it was created. So the third object we have is called a comet. It's another simple command which you can use, and you get back another simple hash. Similar to before, you can print that hash, and you get the familiar display which you already see in Git logs. So I'm not saying all of you should use these commands to manage Git, because you do have the higher level systems to do that. But because of these tree objects, you can represent Git in a tree. And the leaf nodes in Git are the data blobs. And then you associate those data blobs with a file name and finally with a comet. And subsequent comets can refer to previous comets, et cetera. And you see the tree is just a flat structure if you want to have multiple directories, you can just chain trees together. When you create a merge or pull request, multiple comets will be referenced in the next comet. So that was the hard part, only about what kind of objects we have in Git. But you can see we have all these simple bits of data and for a single comet, an actual high level commit when you put files into your Git repo, you have at least four, five objects. So my first implementation of Mango was just putting all these objects into an Ethereum contract that works, but probably it's not very useful. For a simple repo of a couple of files with just a hello word in them, it takes roughly 50 million gas. Like developers earn a lot, but probably they don't have enough money to keep up with typo changes and pushing them to an Ethereum contract. So better implementation is realizing the fact that we can use IPFS and swarm. So this is what I did. And I put all these objects into IPFS and swarm. But as I have mentioned, Git uses sha1 hashes. And probably all of you know that IPFS doesn't. So sha1 isn't really good anymore. We could change Git to not use sha1, but unfortunately, it's really tied in with sha1. And we want to keep backwards compatibility with every tool you have today, as well as solutions like GitHub. So we cannot change that. Well, a simple solution is to map IPFS identifiers to Git identifiers. So what this means is I push every single object to IPFS. Then I create a snapshot file of the mapping of these identifiers. And I push this snapshot file to IPFS as well. So why do you need Ethereum? Well, you don't actually need Ethereum, at least to this level. When you push all your content to IPFS, you get this top-level snapshot file. And you can give this snapshot identifier to anyone you want to give your code to. They can download your code that way. However, if they make changes or you make changes, you're going to get a new snapshot identifier. So then you have to give that identifier to them. They make changes. They give a new one. You make changes. You have a new one. It's not really practical. So this is where Ethereum comes into play, and it makes this a practical solution. So at every Git push, they push two details into a mango contract, which is what was the latest commit, which is the Git identifier, and the location of this snapshot file. Today, this costs 140,000 gas, which is a big difference to 50 million. This contract isn't optimized yet, so this could even go further down. So what is mango? And mango is actually a couple of things. It defines the semantics how to store Git objects in IPFS or Swarm. It also defines a contract interface for Ethereum. It gives you an implementation for the Git backend, enabled to communicate with Ethereum and IPFS. And it also gives you admin tools to create repos. So every Git repo has its own contract. There's no point making this complex and having a contract for a number of repositories. This has to be simple and secure as it can. So what Ethereum does on top of this, it can manage access control. And you're also free to implement whatever else you want. And there's just a repo interface you have to conform to. But anything else you do is up to you. And for the actual repo contract, which uses 140,000 gas, there's an implementation in the Mango admin toolchain. This is an actual example how to use the toolchain. Once you install it, you can create repos. This, of course, will need access to an Ethereum RPC node, as well as to IPFS or Swarm. So once you create it, you get an Ethereum address. And that's the address of your repo. Then you can create new users. You can delete users. You can set administration rights and a couple of other things. OK, at this stage, you have your repository. So the next thing is to upload data into it. Assuming you have your repo already, you just have to set up the endpoint, which is your contract address. And you can push data into this repo. As mentioned before, we don't really store the data in the repo, but we need to update the references in your repo. OK, now you have all your content decentralized. So it's time to share it with your friends, and they can download it as well. Since you are able to create multiple accounts in your repo contract, your friends are able to push changes to your repo at the same time. While contract addresses work, I think there will be a better way to do that. And I hope ENS or a similar system will come along soon, and you will have symbolic names for your repos, such as solidity.etherium.mango.eth. I still need to convince the guys to register five letter names in eth, but hopefully that works. So where are we with Mango? Is it a replacement yet? Of course. Well, not entirely, but there's certain use cases that's already capable of. I would suggest that you use your tools you're familiar with today and your services you're familiar with today. But once you have a version of your software or a release you want to persist for an indefinite length of time, you could use Mango, and you could push that certain change set, the certain version of your software to Mango. But this should change in the future. So we have to improve Mango, and we have to improve tools to provide a full replacement, a full decentralized replacement to social coding. So the first thing we have to do here is, which is a tiny thing, with each releasing it you can only set a version number. But it would be really cool to also set a release note, what that version includes. So that's actually possible with Git. There's a feature called Git notes, which you can use to put notes next to any object. It's kind of hard to use, so this has to be improved. The second big thing is to have issue tracking within Git. Google has a project to do that with Git notes, but it's a bit clumsy. So there's still room for improvement here. The really big work here is supporting pull requests or merge requests, as well as like GitHub-style forking. So if anyone has good ideas how to do it, please talk to me, or anyone involved with improving Git. And of course, we need user-friendly frontends, because some people are happy to use the command line, but others would be much more happy to have a nice web frontend to create, manage, and view, and interact with all these repos. One important aspect there with improving the issue tracking and the pull requests with Git, this wouldn't be only for Mango. If you have all these things within Git itself, no matter where you take your repository or your data, including your issues and your pull request, will stay with you. And I hope actually GitHub and GitLab and other bigger companies using Git would be able to support some of these features so you could freely move between Mango and a decentralized website, or a decentralized app, and between these services without any hassle. Well, thank you for listening. I think now it's time to check out Mango. And actually, no one believes this, but it works already. So you could try it out. Thank you. Thank you, Alex.