[00:00.000 --> 00:13.080]  Hello, everyone. Thank you for joining this event, and thank you very much for the organization
[00:13.080 --> 00:18.560]  of this death room. Much appreciated. I know how much work this is. Awesome work. Thank
[00:18.560 --> 00:25.600]  you. So thanks a lot to the whole FOSTEM team. Really cool. This presentation here is mainly
[00:25.600 --> 00:34.560]  about privacy. And the I2P network is a so-called overlay network, which I will shortly introduce.
[00:34.560 --> 00:42.880]  And I'm the JavaScript TypeScript library maintainer of this library, which allows you
[00:42.880 --> 00:53.360]  as developers, me as developer, to write privacy by design applications. Privacy by design
[00:53.360 --> 01:00.600]  means a few things, which I'm going to talk about shortly after the introduction. I'm
[01:00.600 --> 01:07.720]  a totally independent researcher and developer, and I'm one of the co-founders behind Diva.exchange,
[01:07.720 --> 01:12.200]  we're just a loose of bunch of developers and researchers spread all over the world,
[01:12.200 --> 01:19.240]  very much interested in privacy topics. And one of the topics is free banking technology
[01:19.240 --> 01:26.320]  for everyone, which is not part of this presentation, but it's no centralized model involved in
[01:26.320 --> 01:32.760]  my work, so there is no business model at all involved, because if I'm fully distributed,
[01:32.760 --> 01:39.800]  fully distributed, not only decentralized, fully distributed, it's totally impossible
[01:39.800 --> 01:48.600]  by design to introduce business models. Obviously, no coin, no token, or things like that. I'd
[01:48.600 --> 01:56.440]  like to talk quickly about the motivation. So, why I2P-SAM, this SAM got developed, and
[01:56.440 --> 02:02.680]  how we set up a completely distributed network like I2P, an overlay network. And I obviously
[02:02.680 --> 02:06.800]  like to talk about creation of applications, so how we do that, and how we can do that.
[02:06.800 --> 02:16.160]  We look at the use cases and then some questions and take-outs. All right. I'm Conrad, I live
[02:16.160 --> 02:26.080]  in Switzerland, so, bonjour. Great to have you here. And I lecture at the University
[02:26.080 --> 02:32.560]  of Applied Science in Lucerne, Central Switzerland, a bit about microservices and fully distributed
[02:32.560 --> 02:39.480]  systems, where I'm a bit an alien in this cloud world, because today everything is cloud,
[02:39.480 --> 02:46.520]  but I'm not cloud, I'm peer-to-peer. And now we're here at this I2P network. Let me ask
[02:46.520 --> 02:52.720]  you a question. Please raise your hands. Who ever got in touch with an overlay peer-to-peer
[02:52.720 --> 03:02.600]  network like I2P? Again, I'm not totally lonely, so thank you very much. There are a few which
[03:02.600 --> 03:16.320]  have heard of it, and in a nutshell, I2P is a fully anonymous confidentiality giving messaging
[03:16.320 --> 03:22.560]  system. So it's, you have the general internet as you know it, and where all the cloud applications
[03:22.560 --> 03:28.960]  are running somewhere in central services. And this I2P network is a layer on top, it's
[03:28.960 --> 03:37.680]  a software layer, and everybody who's running such an I2P node is becoming a client and
[03:37.680 --> 03:45.040]  a server. So when I'm talking about a node, a node which might be run by every one of
[03:45.040 --> 03:52.360]  you, you're a client and you're a server. You're both at the same time, and you're helping
[03:52.360 --> 04:03.160]  the network. There are around 34,000 I2P routers in the network, which is a joke. That's nothing.
[04:03.160 --> 04:11.680]  That's compared to the internet infrastructure as we know it today. That's tiny. That's nothing.
[04:11.680 --> 04:20.960]  But still, these 34,000 routers, more or less, they run this fully anonymous and fully confidential
[04:20.960 --> 04:30.640]  messaging system. And please, it's an overlay network. It's not, well, some media call it,
[04:30.640 --> 04:36.200]  but it's not a darknet. It's just an overlay network. It's a piece of software. It's a
[04:36.200 --> 04:44.000]  technical solution to a problem. And the problem is we want anonymity and we want confidentiality,
[04:44.000 --> 04:51.760]  because these two things, by definition, define total privacy. And if I want to disclose my
[04:51.760 --> 04:58.960]  private stuff, it's my decision and only my decision. And that's the point behind privacy.
[04:58.960 --> 05:07.840]  All right. So I ask you now, please, in this room, to be open towards peer-to-peer applications
[05:07.840 --> 05:13.280]  which are a bit more complex, but not really complicated, and open your mind for something
[05:13.280 --> 05:21.240]  which has nothing to do with the cloud. All right. Why did I do the work and develop a
[05:21.240 --> 05:32.280]  library, an I2P SAM library? Well, the I2P core developers, they are super cool, hardcore
[05:32.280 --> 05:55.040]  network guys. And they love what they do since 20 years. Devo chain, which is a fully distributed
[05:55.040 --> 06:03.160]  storage layer, so something to store data in without trust. And that's kind of a problem.
[06:25.040 --> 06:47.360]  You can't be spied out. Everything you exchange is totally private. And there is no man in
[06:47.360 --> 06:52.680]  the middle. There is no man in the middle. Because, again, this I2P network works like
[06:52.680 --> 06:58.960]  a garlic. All the messages which are hopping through this network from node to node, from
[06:58.960 --> 07:07.200]  peer to peer, they're multiple times encrypted. So you send your message from your application
[07:07.200 --> 07:14.240]  into the network layer, and it ends up at the destination, and it's multiple times encrypted.
[07:14.240 --> 07:27.240]  Just by using the library. That was the motivation. When you appear to peer, just by definition,
[07:27.240 --> 07:33.760]  you get a bunch of problems you don't really want. And it's complicated a bit to get into
[07:33.760 --> 07:39.240]  it. So at Devo, we thought, hey, come on, let's build a few Docker containers to simplify
[07:39.240 --> 07:44.760]  this process. And today, the students at the University of Applied Science and Lucerne,
[07:44.760 --> 07:50.600]  they were able to set up a complete test network and a complete developer network within a
[07:50.600 --> 07:56.800]  few minutes. And that's this Docker container you find on GitHub. And, by the way, also
[07:56.800 --> 08:05.440]  mirrored to Kodberg. But you find it on GitHub. And then you can start by initializing these
[08:05.440 --> 08:13.160]  containers with a simple script. And with one go, you have your I2P connectivity available.
[08:13.160 --> 08:19.920]  You have, if you like to, a storage layer available. And you can start programming. You
[08:19.920 --> 08:25.080]  can start developing without needing to care about all the complexity of such a peer-to-peer
[08:25.080 --> 08:40.360]  network. And this is a screenshot of GitHub. And here I'd like to be totally open. All
[08:40.360 --> 08:46.920]  we do at Devo and all I'm doing is really, really free Libre software. There are no
[08:46.920 --> 08:53.320]  strings attached or strange stuff or things you need from somewhere else. It's really
[08:53.320 --> 08:58.880]  free. It's really Libre. And it's very strict licensing, which we're doing. So that's quite
[08:58.880 --> 09:06.360]  important for me personally to have open source software at its core. And that's very important
[09:06.360 --> 09:15.080]  for me. So there exists also a simplified version. I told you, you need a network to
[09:15.080 --> 09:21.640]  communicate between your peers. You need maybe a storage layer on top. But the storage layer
[09:21.640 --> 09:27.280]  is not a necessity. So if you say, well, I just want to communicate. I do not want to
[09:27.280 --> 09:33.240]  store anything. I do not want to store data. Then you don't need a blockchain because you
[09:33.240 --> 09:38.760]  don't want to store data. So if you just need to communicate in your application between
[09:38.760 --> 09:47.400]  peers, then you have this simpler setup. You go with NPM install, I2P SAM. And in there
[09:47.400 --> 09:57.400]  is a YAML file. That's the last one. So this is SAM.Devo.I2P.YML. And you initialize this
[09:57.400 --> 10:05.320]  container in there. And you have a very much simplified application development environment
[10:05.320 --> 10:17.920]  available without storage capabilities. The library got quite popular in the last months.
[10:17.920 --> 10:24.240]  It has to do with one thing we did for the DNS crowd, domain name system, domain name
[10:24.240 --> 10:28.280]  service. And the students at the University of Applied Science State got the job from me
[10:28.280 --> 10:38.960]  to create an API for a DNS system for I2P because I2P does not even have a DNS. So welcome
[10:38.960 --> 10:46.280]  to Stone Age. And so the library got used by the students and got more popular in the
[10:46.280 --> 10:53.000]  last months, which is nice. And here we have this, by the way, who is familiar with Docker?
[10:53.000 --> 11:00.840]  Who is using Docker? Okay. Right. So great. Almost everybody. So yeah, here you have
[11:00.840 --> 11:06.840]  a YAML file. I don't have to say much. You use it. And, ta-da, you have your environment
[11:06.840 --> 11:13.960]  available. And everything is available on GitHub on Mirage to Codeberg. Now I want to
[11:13.960 --> 11:23.080]  go through theoretically to two simple use cases to inspire you to create your own privacy
[11:23.080 --> 11:31.200]  by design application, your own. We go through two examples. One is reading and the other
[11:31.200 --> 11:38.800]  example is writing. As you said, as I said, every note in the network, you are a client
[11:38.800 --> 11:45.240]  and the server at the same time because you're a router within the I2P network. So what we're
[11:45.240 --> 11:53.880]  doing first, we're reading something from the network. Now the documentation on NPM,
[11:53.880 --> 12:04.000]  the documentation on GitHub for this library is quite grown up. It's quite complete. That's
[12:04.000 --> 12:12.160]  my personal view on it. If you have a different view, please do not hesitate to tell me and
[12:12.160 --> 12:20.960]  improve this documentation because I can learn that much from you. So here we have an example
[12:20.960 --> 12:27.760]  of creating a reading stream. So you want to read some data from another node in the
[12:27.760 --> 12:34.680]  I2P network. And you can simply use this very first quick start example and then replace
[12:34.680 --> 12:44.080]  only the IP which points to your Docker container which we have seen in the YAML file just before
[12:44.080 --> 12:54.280]  and ta-da, you're communicating through the I2P network. That's it. So privacy by design
[12:54.280 --> 13:00.080]  and exchanging private messages, totally confidential, anonymous, over the existing
[13:00.080 --> 13:08.160]  internet infrastructure isn't difficult anymore. Here it is. It's not more. And the same thing
[13:08.160 --> 13:13.680]  is now also if we're looking into writing data which means nothing else, you're offering
[13:13.680 --> 13:23.280]  a service on the overlay network I2P. There is the other example in the readme which is
[13:23.280 --> 13:30.760]  doing both things at the same time. The second example is creating a writing instance. So
[13:30.760 --> 13:36.080]  serving some data and at the same time, that's the very last part here at the end, it's
[13:36.080 --> 13:42.680]  reading data. And it's not doing this locally by simply locally connecting from the reading
[13:42.680 --> 13:50.280]  instance to the writing instance. No, it goes through the overlay network, through I2P completely
[13:50.280 --> 14:06.600]  and it does its job. A word of warning, I2P is not fast. Confidentiality and total anonymity
[14:06.600 --> 14:15.880]  has a price tag attached. And this price tag is called speed, latency. So to give you an
[14:15.880 --> 14:21.920]  idea, when we're reading and writing data from the diva blockchain where we're exchanging
[14:21.920 --> 14:27.080]  this data over peers, distributed all over the network, we have latencies of three till
[14:27.080 --> 14:35.920]  five seconds. Three till five seconds. That feels like 1992 or something. So that's the
[14:35.920 --> 14:44.880]  cost of privacy. You don't get privacy for free. Right, a few use cases. And I'd like
[14:44.880 --> 14:49.280]  to highlight the second one. The first one is the free banking. That's where I'm working
[14:49.280 --> 14:53.280]  together with and everybody is invited because we're totally transparent. So if banking is
[14:53.280 --> 15:00.920]  your thing, yeah, join in. If chat is your thing, then the I2P development team is really
[15:00.920 --> 15:10.360]  would be super happy to, would be super happy that somebody hops into the chat challenge.
[15:10.360 --> 15:18.760]  You don't have to worry that the chat application is not good enough because I2P simply has
[15:18.760 --> 15:26.200]  nothing. So it would be a great thing to start somewhere. And if you're a good user interface
[15:26.200 --> 15:30.680]  designer or user experience designer, hey, they would be like in heaven if they get something
[15:30.680 --> 15:39.320]  like that. That would be, wow. Additionally, games could be a topic for some people. But
[15:39.320 --> 15:47.400]  the latency could be a killer there. So it would be interesting. Right. Since I have
[15:47.400 --> 15:53.360]  now around eight minutes left, as my colleagues have shown me, which is great, I'd already
[15:53.360 --> 16:00.880]  like to enter the links, discussions, feedback and questions face of this presentation. So
[16:00.880 --> 16:14.000]  please, any questions? Oh, yes. Call to action. There are some questions. And there is a micro
[16:14.000 --> 16:35.160]  phone. Hi. Thank you very much for your presentation. So usually in secure systems, one of the issue
[16:35.160 --> 16:41.000]  is that due to security, there is more friction for the user. And that's also part of the
[16:41.000 --> 16:48.920]  cost of implementing secure systems. So, of course, here, almost everybody used Docker.
[16:48.920 --> 16:54.440]  So that's not an issue. But for, let's say, my grandma, that's going to be a bit more
[16:54.440 --> 16:59.960]  difficult. It's probably also not the target audience. But on the network side, have you
[16:59.960 --> 17:08.360]  tried, for example, setting up a compatibility layer with WebSockets or WebRTC so that the
[17:08.360 --> 17:17.160]  full stack could be run from the browser? Yeah. Short answer. Yes, WebSockets. WebSockets,
[17:17.160 --> 17:23.840]  not WebRTC. WebSockets is used by Diva, which is a real-time banking exchange system running
[17:23.840 --> 17:31.400]  on your own device. Yes. Yes. Everything which you, as JavaScript developers and TypeScript
[17:31.400 --> 17:37.080]  developers do know is on board, it just might be sometimes a bit slow. But I do not believe
[17:37.080 --> 17:42.360]  that there are additional user experience challenge. Obviously, you're totally right.
[17:42.360 --> 17:47.640]  But since you are the developer, I have, I just deliver the glue. I just deliver the
[17:47.640 --> 17:57.680]  glue between the privacy network and the end user interfaces. So the human-machine interaction,
[17:57.680 --> 18:01.960]  which we as developers should create. But this here, this library is just the glue, which
[18:01.960 --> 18:07.720]  gives you privacy by design. Thank you very much for this question. More questions? Please.
[18:07.720 --> 18:16.000]  Hi. Thanks for the presentation as well. How does it compare to other peer-to-peer networks
[18:16.000 --> 18:25.240]  such as IPFS, for instance? Thank you very much for this question. There are other presentations
[18:25.240 --> 18:31.320]  in the lightning talk, in the lightning room, just afterwards. First, I have the I2P presentation,
[18:31.320 --> 18:37.920]  and then there are other overlay networks. Honestly, I can't compare it because I'm
[18:37.920 --> 18:45.520]  the I2P guy. It says I2P here. But there is quite some research around which compares
[18:45.520 --> 18:53.360]  these networks. What I'd like to lay out is, on the research gate, which is the academic
[18:53.360 --> 19:02.440]  network for papers, there are some interesting papers around to read about darknets, and
[19:02.440 --> 19:08.760]  now I call it darknet, which have storage capabilities suitable for large files. Please
[19:08.760 --> 19:15.320]  do your own research. Please think what you're doing. Privacy is important, but there are
[19:15.320 --> 19:21.720]  also bad actors out there. So do your own research, and please read the research gate
[19:21.720 --> 19:28.720]  papers and articles about overlay networks. Is this okay for you?
[19:28.720 --> 19:36.840]  When are the lightning talks? It's today the lightning talks. There will be lightning
[19:36.840 --> 19:43.400]  talks today comparing those different. Okay. So the speed of the networks, the latencies.
[19:43.400 --> 19:52.160]  No? Don't worry. I'm going to check the links. Thank you.
[19:52.160 --> 20:05.480]  More questions? Sorry. I actually had a question about the latency. The problem is the number
[20:05.480 --> 20:11.880]  of the servers know that we have only 34,000. That's the problem. If we got more, that would
[20:11.880 --> 20:21.040]  mean that we can speed it up. It doesn't let it go faster.
[20:21.040 --> 20:27.520]  Interesting question. The question is, if there are more nodes in the network, will the network
[20:27.520 --> 20:36.720]  become faster? By building overlay networks, now theory, tunnel building is involved. Tunnel
[20:36.720 --> 20:44.120]  means a message hops over several nodes in the network. Now, a message comp can be only
[20:44.120 --> 20:54.560]  as fast as the slowest node in this route, so in this tunnel. Just by stacking up additional
[20:54.560 --> 21:02.960]  nodes in this network is not necessarily decreasing the latency of the network. It depends off
[21:02.960 --> 21:11.520]  the available bandwidth and performance of all the nodes involved within one tunnel.
[21:11.520 --> 21:21.360]  So the answer to your question is, it depends. More questions?
[21:21.360 --> 21:34.640]  Yeah. Since there's no other questions, could you give some more context about your free
[21:34.640 --> 21:40.280]  banking use case, the first one? Right. Yeah. It's a JavaScript type script
[21:40.280 --> 21:47.760]  application. It's built to exchange any existing or any future digital value, which can be
[21:47.760 --> 21:54.160]  something like to take an example, which everybody understands, Bitcoin, but also can be something
[21:54.160 --> 21:59.600]  like a piece of music and art, which is digitally available. It has nothing to do with Ethereum
[21:59.600 --> 22:06.360]  or directly. It's just an exchange system for all digital values. And here we require
[22:06.360 --> 22:13.040]  by definition in our foundation, it has to be private by design, because we want that
[22:13.040 --> 22:19.200]  people decide and not some operation in the center. That's the context I'd like to give
[22:19.200 --> 22:44.840]  here. Other questions? And thank you very much for your time. Thank you a lot.