WEBVTT 00:00.000 --> 00:00.700 Cool. 00:00.700 --> 00:03.220 Hi, I'm IDK. 00:03.220 --> 00:10.160 I normally work with the I2P project, also work a little bit on IPFS. 00:10.160 --> 00:20.140 And I'm here today to talk about mostly what I've been doing with, I guess, a Monero-linked project called I2P0. 00:22.660 --> 00:28.180 I'm not sure how closely you guys develop with them, but I think that they work with you pretty closely. 00:31.020 --> 00:43.260 Mostly about what I2P0 is, but mostly about what I did with it and what I think other people can learn from what I did with it. 00:43.260 --> 00:46.040 And I call it tricky bundles. 00:47.000 --> 00:59.160 So, I2P's got sort of a bunch of different distributions, and they all connect you to this overarching thing that we call the invisible internet. 00:59.160 --> 01:08.900 And the core Java I2P router has this kind of... this long-standing... we all kind of sign up for... 01:08.900 --> 01:18.260 where you have to install Java and a number of dependencies in advance of actually using it. 01:18.260 --> 01:35.260 And it ends up being about 25 clicks from standard Windows 10 installation to having a working I2P router and browser on top of that. 01:35.540 --> 01:40.660 But on the other hand, you get a whole bunch of other stuff with it. 01:40.660 --> 02:05.100 And all these things are sort of intended as kind of application primitives for building things with I2P, but they also present user interfaces that can be kind of adapted to existing apps as well. 02:05.100 --> 02:11.520 For example, we have a BitTorrent client, and we have an I2P tunnel and things like that. 02:12.940 --> 02:22.280 But obviously, the problem with this is that it's pretty difficult to install for new folks, and that's the problem that I2P0 addresses. 02:23.140 --> 02:25.040 But there's another problem. 02:28.180 --> 02:29.560 Oh, man. 02:31.360 --> 02:33.680 Let me back up a moment. 02:34.940 --> 02:48.680 I like to refer to Java I2P as sort of the core utils of I2P in that it provides everything that you need, but not a lot of people use core utils directly. 02:48.680 --> 02:53.060 They mostly use their file. 02:54.280 --> 02:59.660 It's all kind of wrapped around that if it is involved at all. 03:02.980 --> 03:17.220 And so it kind of begs the question, should we be building out-of-tree apps that incorporate I2P as a way of providing them with something that they need? 03:17.220 --> 03:29.000 And I say something that they need because anonymity is a big part of what we do, but it's not the only thing that we can do for you. 03:29.000 --> 03:30.440 A little bit more later. 03:31.760 --> 03:32.800 Okay. 03:33.240 --> 03:36.120 But there's a problem. 03:36.120 --> 03:47.100 And the problem is this 25-step installation procedure, which, again, I2P0 solves. 03:50.660 --> 03:54.180 Let me back up again for a moment here. 03:57.520 --> 04:00.800 I'm not a great public speaker all the time. 04:05.920 --> 04:19.860 Because I2P is written in Java, which is obviously the JVM, for it to call between non-JVM languages. 04:19.860 --> 04:40.140 So if somebody wants to write their application in something a little more popular than Java these days, like, say, for at least maybe getting started, like Python, then they have to count on somebody to resolve this dependency for them. 04:43.660 --> 04:46.080 And the bottom line is this... 04:48.460 --> 05:04.740 because it means that most everybody who might install your app is going to fail before they even get started because they have to install I2P. 05:05.700 --> 05:20.060 So, you know, I'm just reiterating a bunch of reasons what you probably already thought of that are good reasons to make something like I2P0, which you guys obviously already understand. 05:26.910 --> 05:35.770 But it also elucidates something about our architecture, which is that apps and routers are not tightly coupled. 05:37.070 --> 05:56.350 You join the network and your app requests resources from the network in the form of tunnels or destinations or bandwidth or whatever, but the actual interaction with the network, that's all kind of abstracted away and handled by the router, which is great, 05:56.350 --> 06:00.030 especially in the case of SAM, makes things very easy. 06:04.590 --> 06:13.910 There are kind of a lot of applications that are not going to be distributed through, say, Debian main. 06:14.190 --> 06:24.630 They're going to be written by people who wrote them independently, and they're going to have kind of rapid development cycles. 06:24.630 --> 06:30.410 Sometimes they're going to be distributed by anonymous people who can't maybe buy certificates sometimes. 06:31.410 --> 06:34.770 And all this gets pretty complicated. 06:38.310 --> 06:53.030 So I think that we should develop a new set of best practices for embedding I2P routers in apps that are not necessarily I2P routers themselves. 07:01.300 --> 07:06.780 I2P0 solves this issue. 07:06.780 --> 07:10.920 It only really solves the dependency on Java issue. 07:10.920 --> 07:20.080 It doesn't actually resolve the capabilities of the I2P router in question. 07:22.040 --> 07:26.560 So I took a stab at making that job a lot easier. 07:33.440 --> 07:34.440 Now... 07:34.440 --> 07:38.880 I'm going to talk about why this might be desirable. 07:38.880 --> 07:55.240 There are two sort of broad categories of out-of-tree I2P apps that relate to the problem in question. 07:55.240 --> 08:01.100 There are ones that bundle I2P themselves and ones that don't. 08:01.100 --> 08:07.400 And there is a torrent client that bundles a whole I2P router inside of it. 08:07.400 --> 08:10.720 They release... 08:11.660 --> 08:18.760 It's a complete implementation that works by linking to our Java libraries. 08:18.980 --> 08:38.560 And if you install it on a machine where there's an I2P router already, you end up with two running I2P routers, even though this piece of software actually has the capability to use the existing I2P router and thus less resources. 08:39.200 --> 08:42.980 But you have to go in and do it in the advanced configuration. 08:47.160 --> 08:59.300 Whether or not there's an I2P router capable of working with our app before we actually do it, or before we actually start our own embedded I2P router. 09:02.960 --> 09:05.360 Got a little ahead of my slides here. 09:07.200 --> 09:09.900 So how do we prevent this? 09:09.900 --> 09:15.260 Well, what we've got to do is we've got to probe for different I2P capabilities. 09:15.380 --> 09:20.040 And it turns out that... 09:20.040 --> 09:27.580 There is, but I don't think any of them are necessarily 100% reliable. 09:27.580 --> 09:35.540 So I like to take into account each and every one of them in sequence here. 09:38.100 --> 09:43.520 First of all, we can check and see if I2P is installed to the default paths. 09:43.580 --> 09:47.760 Obviously, this breaks if it's installed to a non-default path. 09:47.760 --> 09:59.020 So we can have a little rule in there that maybe looks for it in a portable installation under a specific directory, but we can't handle every single thing this way. 09:59.020 --> 10:04.240 Moreover, it doesn't actually give us information about whether I2P is running or not. 10:04.240 --> 10:13.060 It's a useful thing to know, but it is not in and of itself enough information for us to use. 10:14.480 --> 10:17.460 We can look at the output of PS. 10:19.080 --> 10:22.640 It's simple enough to do on every platform. 10:22.640 --> 10:27.100 It gives us information about the installed state and the running state. 10:27.180 --> 10:36.900 But it doesn't give us any information about the APIs that are available, at least not without some extra effort, really only on Java I2P as far as I know. 10:36.900 --> 10:40.240 It might not apply to I2PD. 10:44.480 --> 10:45.000 But... 10:48.280 --> 10:54.980 Also, some systems, GR security, will limit the output of PS by user. 10:54.980 --> 10:58.340 And obviously, if it's a service install, you can't do that there. 10:58.340 --> 11:00.020 So it's brittle there too. 11:02.100 --> 11:11.000 So the next thing, and where it gets a little bit more interesting, is we check for a usable I2CP or SAM v3 port. 11:11.080 --> 11:14.040 And this doesn't have to be complicated. 11:14.100 --> 11:23.680 In terms of I2CP, there aren't a lot of libraries that implement the whole specification in other languages, so you probably will end up using SAM. 11:26.320 --> 11:32.600 That said, though, there's also a command line tool that will do this that I wrote as part of this project. 11:34.420 --> 11:38.460 This gives you a lot more information about I2P. 11:38.460 --> 11:39.860 It tells you that it's running. 11:39.860 --> 11:48.740 It gives you the opportunity to create a destination and validate that you are, in fact, talking to who you think you're talking to. 11:50.980 --> 12:00.700 That said, though, SAM v3 is not enabled by default on the core Java I2P router, so it might fail in that case too. 12:00.700 --> 12:04.820 But you'll always have an I2CP port, and that will always work. 12:07.040 --> 12:11.880 And then the last thing is to check proxy.i2p. 12:11.880 --> 12:34.420 And this is just an HTTP request over localhost 4444, just like the regular Java I2P proxy uses for when you're configuring your browser, you know, taking something over cURL or whatever, to proxy.i2p, which is a loopback address. 12:34.420 --> 12:48.780 And what it'll reply with is either proxy is ready or proxy is not ready, you know, tunnels need to be built, or whatever. 12:50.980 --> 13:02.780 And that gives you almost as much information as talking to I2CP just for one request back and forth to validate that I2P is there. 13:02.780 --> 13:06.100 And it'll work everywhere. 13:06.400 --> 13:19.540 So once you've established that there's an I2P router running or not, I think that this should roughly be the 13:23.220 --> 13:25.760 default when you start your application. 13:25.760 --> 13:35.560 So you should check for the presence of a running I2P router first, and then probe for the API capabilities that you want. 13:35.560 --> 13:40.020 If all you need is an HTTP proxy, only ask for the HTTP proxy. 13:41.260 --> 13:44.760 If all you need is SAM, only ask for SAM. 13:44.760 --> 13:58.940 And once that comes back, you'll either know whether the API is available or not, and just start your application. 13:58.940 --> 14:12.420 If not, check the default paths for an I2P router that's already installed by the user before we got there. 14:12.420 --> 14:15.340 If it's available, try and start it. 14:15.340 --> 14:18.800 If it's not available, go to the next step. 14:19.680 --> 14:28.620 If you can't discover an I2P router, go ahead and unpack a copy of I2P0. 14:31.700 --> 14:35.620 Start I2P0, then immediately start SAM. 14:36.480 --> 14:43.040 Use that to establish any tunnels for your application, and I'll get to why in just a second. 14:44.280 --> 14:51.340 Now, I glossed over some details in this slide about waiting for certain things to become available. 14:51.340 --> 15:00.740 I would like to let available for you to review because these are next to impossible to read on this TV, and I'm sorry for that. 15:03.390 --> 15:09.050 Now, there's still a problem with this approach in terms of the resources. 15:09.050 --> 15:21.730 It's not currently possible to run SAM freestanding of either the Java I2P or C++ I2PD routers. 15:21.730 --> 15:28.030 That said, though, I2P0 is pretty darn close. 15:28.230 --> 15:38.830 We can live with that for a while until unbundled SAM v3 is a working thing. 15:44.340 --> 15:54.020 So what I created out of this is called Go Zero and Zero Bundle, which is a library that supports it. 15:54.020 --> 16:10.000 And all it does is treats I2P0 as a static resource, handles installation, start, stop, and management on behalf of the I2P router, or the I2PD router, rather, from a Go application. 16:10.000 --> 16:32.820 These also all correspond to command line interfaces, or command line interface apps, rather, that you can use to manage an embedded I2P, just about any kind of app, because we can generate a .a file and link it to a C program. 16:32.820 --> 16:34.320 It's huge. 16:34.320 --> 16:40.020 It will add some overhead to your app, so that is a bit of a drawback. 16:40.080 --> 16:55.700 But it is exactly the same overhead that you would have added in another place had you bundled I2P0 with your app as a zip, which, of course, is also valid and possible to do with Go Zero. 16:57.720 --> 17:19.720 I2CP check is sort of a re-envisioned piece of the core utils puzzle for people who want to bundle I2P routers with their application in a zip file, in particular, I2P0. 17:21.880 --> 17:33.000 What they do is they do this API probing and path probing to detect pre-existing I2P routers or determine if I2P routers are ready. 17:33.000 --> 17:49.700 So if you want to build a launcher script for your I2P enabled app, but don't want to actually embed it inside of the app, then you can use these to do all your discovery and API probing needs. 17:50.540 --> 18:02.940 And then lastly, the thing that I am beginning to build with this is a replacement for a somewhat ill-fated I2P browser project. 18:02.940 --> 18:25.120 For those of you that don't know, we attempted to build an I2P browser toward the beginning of last year, worked on it for about a year, and concluded that the Mozilla code base was moving a little too fast for us to keep up and also develop the Java I2P router at the same time. 18:25.120 --> 18:39.840 So I spent my time looking for ways to make that process a little bit easier for us to manage, and this was part of what I came up with. 18:41.200 --> 18:53.980 Because we're so decoupled from the applications themselves, I believe this probing is kind of a necessary process. 18:56.520 --> 19:00.160 Actually multiple I2P routers on the same machine. 19:00.560 --> 19:10.980 During the I2P browser process, and at the time, I was developing on an Acer Aspire C720 with 4 gigs of RAM. 19:11.100 --> 19:13.040 It was not fun. 19:13.040 --> 19:15.100 It was very challenging. 19:17.820 --> 19:32.750 And so that was a thing that we needed that we never got around to doing in that one, which I did with this project. 19:34.250 --> 19:37.590 I really want to see I2P0 in all the things. 19:37.590 --> 19:46.550 I want to see it in every app that uses I2P right now that does not bundle a router with it. 19:46.570 --> 20:01.830 I think that it stands a really good chance of smoothing over our install issues, and if done properly, we don't ever have to worry about using too many resources. 20:08.230 --> 20:18.190 And, well, I think that is about the end of what I have. 20:18.730 --> 20:22.630 If there are any questions, I can 20:26.400 --> 20:28.460 see them in the Jitsi, maybe? 20:34.880 --> 20:35.720 Yeah, thank you. 20:35.720 --> 20:36.380 Thank you so much. 20:36.380 --> 20:37.920 I'm looking to see if there's any questions. 20:37.920 --> 20:41.940 I don't see any on YouTube or IRC. 20:42.240 --> 20:47.220 I also don't see them on Discord either. 20:48.280 --> 20:50.580 It looks like it was pretty self-explanatory. 20:52.140 --> 20:54.840 Yeah, nothing too complicated here. 20:54.840 --> 21:02.200 Very useful from my point of view, but nothing terribly complicated in this presentation. 21:05.000 --> 21:07.400 Got it, got it. 21:10.600 --> 21:19.580 Okay, I guess, how familiar are you with the efforts to integrate I2P in Monero in a deeper level? 21:19.580 --> 21:31.920 I know it's integrated through I2P0 with the Monero daemon and Monero CLI to some extent. 21:31.920 --> 21:33.260 Are you aware of those efforts? 21:33.260 --> 21:35.500 Do you communicate with anyone that works on those projects? 21:35.500 --> 21:43.740 I've been seeing myself with those efforts, I would say. 21:43.800 --> 21:53.920 I've been getting myself more familiar with them over the past two months as our browser project is kind of... 21:54.340 --> 21:56.760 well, my browser project at this point. 21:56.760 --> 22:02.280 It's a mistake to identify it with I2P exactly at this point. 22:02.280 --> 22:04.780 This is something I did on the weekend. 22:05.500 --> 22:12.500 But yeah, I've been familiarizing myself with the process there, and I think actually the... 22:15.360 --> 22:19.080 to making some suggestions. 22:19.080 --> 22:21.300 It could be scripted already. 22:22.500 --> 22:29.380 But I'm not sure that that's something that is something that people want to do yet. 22:31.320 --> 22:32.500 Okay, cool. 22:40.210 --> 22:43.350 I don't see any other questions coming in. 22:46.160 --> 22:48.580 Do you normally post your slides anywhere? 22:50.600 --> 22:55.760 I don't have them up yet, but I will put them up as soon as the presentation is over. 22:55.760 --> 22:57.700 I got to reboot this other laptop. 23:01.980 --> 23:02.820 Got it, got it. 23:02.820 --> 23:05.660 I'm wrapping up my trivia thing that's on right after this. 23:05.660 --> 23:07.760 I'm writing a last final question. 23:11.040 --> 23:12.320 Let's see. 23:13.180 --> 23:14.180 Okay. 23:57.880 --> 23:58.660 All right. 23:58.660 --> 24:02.500 Well, if no one else has any questions, we gave it a bit of time. 24:02.740 --> 24:07.040 Well, then I'm going to say thank you so much, IDK, for joining us. 24:07.040 --> 24:09.960 It was great to have you describe what you've been working on. 24:09.960 --> 24:14.100 And it's always good to hear what other privacy projects are going on. 24:14.100 --> 24:22.520 I know it was really useful for me to have known what I2P was before I learned about crypto, because we've had these decentralized systems out for a while. 24:22.520 --> 24:26.220 And sort of people are like, oh, Bitcoin is the only decentralized thing. 24:26.220 --> 24:31.100 And they kind of forget everything else exists in a comical sense. 24:31.940 --> 24:39.740 I think the community can definitely learn a lot from looking at I2P, just because you've been around forever. 24:39.900 --> 24:42.120 Yeah, almost. 24:43.140 --> 24:46.500 If it were a person, we could vote. 24:47.600 --> 24:49.880 It's about 18 years now. 24:49.880 --> 24:51.660 Crazy, crazy stuff. 24:52.640 --> 24:53.180 All right. 24:53.180 --> 24:54.320 Well, thank you so much.