1
00:00:00,000 --> 00:00:29,000
Today we are joined by IDK, who will be sharing with us

2
00:00:29,000 --> 00:00:40,000
about I2P. And I2P is known also as the invisible internet project and has been around since

3
00:00:40,000 --> 00:00:48,000
2003 and I might hear some cat purring in the background and she's telling me to go to sleep

4
00:00:48,000 --> 00:00:56,000
and stop editing this podcast. So with no further ado, let's dive in.

5
00:01:00,000 --> 00:01:07,000
Welcome and thank you for joining us here today, IDK from I2P.

6
00:01:07,000 --> 00:01:08,000
Thank you for having me.

7
00:01:08,000 --> 00:01:16,000
I kind of like was running around looking for you at CCC because I saw on the map that y'all were there

8
00:01:16,000 --> 00:01:25,000
and I have heard about I2P for a few years but when I researched before this podcast episode,

9
00:01:26,000 --> 00:01:32,000
I realized that I2P has actually been around since I saw the earliest research paper was from like

10
00:01:32,000 --> 00:01:38,000
2009 or something. Yeah, yeah, I mean we started even earlier than that. That was the we we

11
00:01:39,000 --> 00:01:49,000
this will be the 25th year we're going to come up on 25 here in more or less October. That is

12
00:01:49,000 --> 00:01:57,000
incredible. Oh my goodness. Okay, immediately there's so many questions and I did like my

13
00:01:57,000 --> 00:02:05,000
master's thesis on like local fur is peer to peer routing agnostic slash delay tolerant networks

14
00:02:07,000 --> 00:02:12,000
and I covered a bit of like the history and some of the earliest ones that I could find back then

15
00:02:12,000 --> 00:02:22,000
were actually like from 2011. So I2P is like way more established than those protocols that I

16
00:02:22,000 --> 00:02:28,000
was studying but before we dive into what I2P is because that's I can think truly what I want to

17
00:02:28,000 --> 00:02:34,000
ask so much about and I assure that other people are quite curious as well. We've heard or I heard

18
00:02:34,000 --> 00:02:40,000
that you introduced this term garlic routing in comparison to like onion routing and tour but

19
00:02:40,000 --> 00:02:49,000
before we dive in there what why did I2P start like what was the kickoff that initiated like the

20
00:02:49,000 --> 00:02:56,000
need for I2P to exist when there already was something like onion routing or tour. Well as a

21
00:02:56,000 --> 00:03:05,000
matter of fact there really wasn't. The thing is that tour and I2P started at Almas exactly the

22
00:03:05,000 --> 00:03:12,000
same time and for almost well for for similar reasons they had slightly different trajectories

23
00:03:13,000 --> 00:03:22,000
however garlic routing was actually coined by a fellow named Mike Friedman who was actually

24
00:03:22,000 --> 00:03:30,000
one of the original authors on the onion routing paper with Paul Seiverson and Nick Bantheson if I

25
00:03:30,000 --> 00:03:38,000
remember correctly. So but what garlic routing was was supposed to be is a way of bundling

26
00:03:39,000 --> 00:03:47,000
multiple of what he would think of as the onion messages together into a single opaque bundle in

27
00:03:47,000 --> 00:03:54,000
order to make the more harder to analyze the traffic by size as it moves through the network

28
00:03:54,000 --> 00:04:00,000
because it's bundled with other stuff that's not necessarily related to it and that's the crude

29
00:04:00,000 --> 00:04:09,000
explanation but the the interesting thing about the history here is that it's actually kind of

30
00:04:09,000 --> 00:04:18,000
evolved down to distinct paths even though the original motivation is largely faded away.

31
00:04:19,000 --> 00:04:28,000
The the tour I2P and FreeNet for a very long time there were considered sort of the big three

32
00:04:28,000 --> 00:04:41,000
of the of the anonymous overlay networks the dark nets if you will and tour of course kind of

33
00:04:41,000 --> 00:04:50,000
openly came out of research at the US Navy Research Lab laboratories and then it had this whole

34
00:04:50,000 --> 00:04:57,000
credibility journey where it was turned over to the EFF and turned into an open source project

35
00:04:57,000 --> 00:05:06,000
and eventually all the US NRL code really kind of just got moved out of it and reused and repurposed

36
00:05:06,000 --> 00:05:15,000
and it's no longer really the the it really no longer shares too much of the the navy roots

37
00:05:15,000 --> 00:05:26,000
anymore whereas I2P was kind of for better or for worse formed in reaction to the Navy's involvement

38
00:05:26,000 --> 00:05:34,000
in tour the idea of building it as a peer-to-peer network where everybody participated in routing

39
00:05:35,000 --> 00:05:44,000
was to eliminate this idea of like national stakeholders and things like that and in this

40
00:05:44,000 --> 00:05:52,000
way it was sort of expressly cyberpunk and crypto anarchist compared to Taurus you know sort of

41
00:05:52,000 --> 00:06:00,000
corporate approach which is not entirely fair to them either I have actually nothing but respect

42
00:06:00,000 --> 00:06:06,000
for what tour does they do a hard job in a difficult environment and they do it very well

43
00:06:08,000 --> 00:06:15,000
I'm just to clarify here crypto anarchist in this sense does not mean crypto bro anarchism

44
00:06:15,000 --> 00:06:22,000
so it does not mean neoliberalism it means like more the crypto punk scene that came early on in

45
00:06:22,000 --> 00:06:28,000
the 90s and has kind of evolved sentence right am I correct to interpret it that way yeah yeah

46
00:06:29,000 --> 00:06:34,000
very much so and and expressly sort of in used in this case in sort of a

47
00:06:36,000 --> 00:06:44,000
mutual aid sort of context like everybody helps everybody in I2P it's it's a very flat network

48
00:06:44,000 --> 00:06:51,000
we don't try to build hierarchies this kind of tells the story a little bit about that values

49
00:06:51,000 --> 00:06:58,000
that I2P stem from and to me intrinsically also ties into the network design of I2P and you

50
00:06:58,000 --> 00:07:07,000
already mentioned it a little bit it's peer-to-peer right and the users also store their data locally

51
00:07:07,000 --> 00:07:16,000
on their devices and share directly in that sense it depends on what you mean so I2P itself is just

52
00:07:16,000 --> 00:07:23,000
a way of transporting data across the internet it's not really different from like h2tp or web

53
00:07:23,000 --> 00:07:32,000
rtc and in that sense so but you know the difference is that we apply this this privacy

54
00:07:32,000 --> 00:07:38,000
preserving procedure to it so you can do really whatever you want with it and as part of this

55
00:07:38,000 --> 00:07:46,000
operation one thing that does happen is you participate in maintaining a table of the

56
00:07:46,000 --> 00:07:52,000
peers that you know about and so that does get written down to the disc but it's the only thing

57
00:07:52,000 --> 00:07:57,000
that intrinsically gets written down to the disc if you're not sharing files then you're not

58
00:07:57,000 --> 00:08:02,000
sharing files for other people you're only sharing files for you're only sharing files if you're

59
00:08:02,000 --> 00:08:08,000
consciously deciding to share files it's not like free net where your information gets sharded across

60
00:08:08,000 --> 00:08:14,000
a bunch of nodes and then somebody gets gets information to to retrieve all the shards and then

61
00:08:14,000 --> 00:08:18,000
put the information together it's not like it's not one of those models where you

62
00:08:20,000 --> 00:08:25,000
where you become the redundant storage for somebody else's material it is just a way of

63
00:08:25,000 --> 00:08:32,000
establishing the connections so it sounds to me almost like I2P is also filling a part of

64
00:08:32,000 --> 00:08:40,000
an ecosystem like a piece of the puzzle yeah okay cool uh okay there's so many questions here

65
00:08:40,000 --> 00:08:44,000
because when I was doing research but maybe that will get things slightly derailed but just

66
00:08:44,000 --> 00:08:50,000
because I encountered so much information when I was doing research about this the videos I was

67
00:08:50,000 --> 00:08:56,000
watching it was like in contrast to tour uh i2p does not let you connect to regular sites on the

68
00:08:56,000 --> 00:09:05,000
internet i2p connects you to a hidden secret encrypted network is that how it works or is i2p

69
00:09:05,000 --> 00:09:11,000
more agnostic to like what it's connecting between and more facilitating the connection in a private

70
00:09:11,000 --> 00:09:18,000
way yeah you we're really just facilitating the connections in a private way um it is it is true

71
00:09:18,000 --> 00:09:26,000
that as far as the the internal operation of the network goes it's not intrinsic to us that we

72
00:09:26,000 --> 00:09:33,000
have egress traffic like it is tour but it's also not impossible to build it to us egress traffic

73
00:09:33,000 --> 00:09:40,000
is just a just another kind of hidden service another kind of hidden service and we call it an

74
00:09:40,000 --> 00:09:46,000
out proxy what's this term you're using here it's new to me egress traffic like traffic that leaves

75
00:09:46,000 --> 00:09:52,000
the hidden service network for the wider internet and then presumably send some kind of response

76
00:09:52,000 --> 00:09:57,000
okay cool and one of the topics that's when reoccurring on this podcast because also like a lot

77
00:09:57,000 --> 00:10:04,000
of projects in the past 10 15 years or so which of course is not as long as i2p is been existing

78
00:10:04,000 --> 00:10:09,000
but in the past 10 to 15 years there's been this kind of shift where like at least scuttlebutt and

79
00:10:09,000 --> 00:10:16,000
hypercore or formerly non-dut they started moving from trying to solve like the entire protocol

80
00:10:16,000 --> 00:10:22,000
being like one entire giant protocol that's supposed to do everything to moving towards being

81
00:10:22,000 --> 00:10:29,000
more modular and this kind of ties back to what you were talking about of i2p fitting like one

82
00:10:29,000 --> 00:10:37,000
part of a larger ecosystem is is that always how it has been fried to pee or has that journey changed

83
00:10:37,000 --> 00:10:43,000
and what other parts do you fit with right now and what other parts do you see yourselves fitting

84
00:10:43,000 --> 00:10:50,000
fitting within the future well um you know i2p stands for the invisible internet and at the time

85
00:10:50,000 --> 00:10:56,000
in the in the sort of the hacker culture there was a it was kind of important to build a distinction

86
00:10:56,000 --> 00:11:04,000
between the internet and the web so i2p kind of distinguished itself by saying no we're going to

87
00:11:04,000 --> 00:11:11,000
host all kinds of services and we're going to make them intrinsic to our network if we can and so

88
00:11:11,000 --> 00:11:18,000
yeah it definitely did have this original idea of building an actual invisible internet with

89
00:11:18,000 --> 00:11:26,000
things that you know at the time like irc and you know SSH servers and arbitrary applications

90
00:11:26,000 --> 00:11:31,000
that you just tunneled over your hidden service network um and to some extent towards capable

91
00:11:31,000 --> 00:11:37,000
of doing this too and and that's fine but that's also uh but it's not really their the raison

92
00:11:37,000 --> 00:11:43,000
depth for like it is for us and i think it shows in our design you know we we've kind of planned

93
00:11:43,000 --> 00:11:50,000
to be scalable to an invisible internet that's amazing and the times are becoming more and more

94
00:11:50,000 --> 00:11:58,000
pressing to do that i was seeing today that like a lot of people are using i2p for torrenting

95
00:11:58,000 --> 00:12:06,000
linux distros that don't use system d slash h verification yeah yeah like that's so weird

96
00:12:07,000 --> 00:12:13,000
you know the world is be like you get into this and you've got this vision of what

97
00:12:14,000 --> 00:12:20,000
oppression looks like or is gonna look like and some it to some extent you're right and then

98
00:12:20,000 --> 00:12:27,000
sometimes it just comes out of the blue and is so weird and out of the way and ill conceived

99
00:12:27,000 --> 00:12:35,000
that you just wonder about the foolishness oh i don't usually like to talk about my my

100
00:12:35,000 --> 00:12:42,000
politics i don't like to burden people with them but gosh it's not a burden cumbersome yeah

101
00:12:46,000 --> 00:12:55,000
yeah it's kind of uh it feels like a curveball that i think an entire movement was uh not quite

102
00:12:55,000 --> 00:13:01,000
seeing but also at the same time that is exactly where oppression is going to start yeah it's in

103
00:13:01,000 --> 00:13:09,000
the movements that are trying to make things more free more liberated more available more egalitarian

104
00:13:09,000 --> 00:13:18,000
yeah well and also i think in my experience as you know growing up in america um in in around

105
00:13:18,000 --> 00:13:26,000
the time uh you know between 1999 and 2001 was pretty pivotal shift for the way america treated

106
00:13:26,000 --> 00:13:37,000
its children um we went from uh we went from walking to school to walking through metal detectors and

107
00:13:37,000 --> 00:13:44,000
we went from being able to get on airplanes to eventually kids having to get you know state

108
00:13:44,000 --> 00:13:51,000
issued ids to get on airplanes and i think there's a certain degree to which the uh the age

109
00:13:51,000 --> 00:13:58,000
verification to me speaks of the way that the surveillance normalizations are being directed

110
00:13:58,000 --> 00:14:05,000
expressly at children so that they don't protest them in their adult life and fortunately in england

111
00:14:05,000 --> 00:14:11,000
it's kind of backfiring right now they're drawing mustaches on themselves with makeup markers and

112
00:14:11,000 --> 00:14:22,000
defeating the verification filter which is just hilarious but also sad yeah i mean the the

113
00:14:22,000 --> 00:14:29,000
verification was never there for actual kids no no it's obviously not there to normalize surveillance

114
00:14:29,000 --> 00:14:36,000
on them it's not going to protect yeah exactly and implemented by the people you know we are

115
00:14:37,000 --> 00:14:44,000
yeah it's okay so this is a solar punk podcast

116
00:14:48,000 --> 00:14:57,000
yeah it's really easy to just continue spiraling into the darkness of what's going on in the world

117
00:14:57,000 --> 00:15:03,000
right now and especially when it starts creeping in on our own communities but that's also something

118
00:15:03,000 --> 00:15:08,000
that i thought was like speaking of lightness or like not lightness but speaking of

119
00:15:09,000 --> 00:15:14,000
solutions to these kind of challenges because we shouldn't face away from the challenges but

120
00:15:14,000 --> 00:15:19,000
rather straight up them and trying to solve them and that's something i2p is doing and i think

121
00:15:19,000 --> 00:15:25,000
you mentioned this earlier but like i2p is used for torrenting and i2p is for distributing

122
00:15:25,000 --> 00:15:32,000
districts of linux without system b um we we kind of went into the topic a little bit just

123
00:15:32,000 --> 00:15:36,000
to dive back in when we talk about tour and when we talk about onion routing and when we talk

124
00:15:36,000 --> 00:15:42,000
about garlic routing you mentioned earlier that there's this whole bundling of messages that happens

125
00:15:42,000 --> 00:15:50,000
in i2p that does not happen and for example tour um and you mentioned that i2p is a peer-to-peer

126
00:15:50,000 --> 00:15:56,000
system that facilitates connections and i was also reading up a little bit online that there's

127
00:15:56,000 --> 00:16:01,000
you can have inbound connection and outbound connections but they never pass through the same

128
00:16:01,000 --> 00:16:08,000
notes it's always like different from an expert to a novice how would you describe onion and how

129
00:16:08,000 --> 00:16:12,000
would you describe garlic routing and what are the use cases now for garlic routing and what are

130
00:16:12,000 --> 00:16:19,000
the future use cases for garlic routing that you see well right now i'd say that their use cases

131
00:16:19,000 --> 00:16:26,000
are fairly similar they're both visual metaphors right you're peeling the layers of an encrypted

132
00:16:26,000 --> 00:16:34,000
structure and peeling corresponds to a decryption and the visual metaphor extends to the visual

133
00:16:34,000 --> 00:16:41,000
similarity between onions and garlic you have an onion bulb which is one sort of single structure

134
00:16:41,000 --> 00:16:47,000
and then you have a garlic bulb that if you break it apart has these multiple onion-like structures

135
00:16:47,000 --> 00:16:54,000
inside of it uh to be uh explicitly honest this is also a a relatively unexplored and

136
00:16:56,000 --> 00:17:05,000
even for us kind of experimental even at this stage uh sort of sort of idea the goal with it uh though

137
00:17:05,000 --> 00:17:16,000
is to combine messages that are not necessarily related in a single bulb and the bulb then gets

138
00:17:16,000 --> 00:17:24,000
transmitted over the wire and that has the effect of obscuring the size of the actual

139
00:17:24,000 --> 00:17:36,000
cloves within the bulb and also changing hypothetically the size of the bulb as it goes across the

140
00:17:37,000 --> 00:17:47,000
network and that is supposed to and in theory may help with uh size-based analysis of data that

141
00:17:47,000 --> 00:17:53,000
we're trying to keep private let's see i try to keep this very simple um or maybe a metaphor will

142
00:17:53,000 --> 00:18:01,000
work so suppose you are trying to figure out who uses the most electricity and an electrical

143
00:18:01,000 --> 00:18:08,000
network you are going to track people's usage right well you can kind of do the same thing

144
00:18:08,000 --> 00:18:13,000
for hidden services in terms of bandwidth and if you have like a high bandwidth hidden service

145
00:18:13,000 --> 00:18:19,000
you can tell oh this residential computer uh served 500 gigabytes of data to the door network

146
00:18:19,000 --> 00:18:28,000
i bet there's a hidden service there right um so so so we uh so by breaking this data apart and

147
00:18:28,000 --> 00:18:33,000
recombining it we try to foil this kind of traffic analysis and turns out it's actually

148
00:18:33,000 --> 00:18:42,000
really hard uh it is probably limited protection but it is protection um and we do study it and we

149
00:18:42,000 --> 00:18:49,000
are trying to uh see where we can apply it more and improve it uh to make this kind of protection

150
00:18:49,000 --> 00:18:55,000
more effective and you know we kind of do this in order to continue to be what they call low latency

151
00:18:56,000 --> 00:19:03,000
at least it used to be the definition of low latency was that you were sending data as fast as you

152
00:19:03,000 --> 00:19:09,000
can get it minus the queue that sent it um now i mean something a little bit different because

153
00:19:09,000 --> 00:19:13,000
at least in the context of places like nim and things like that but that's the definition that

154
00:19:13,000 --> 00:19:18,000
we're using for it and so we don't have to delay things through the network to obfuscate where

155
00:19:18,000 --> 00:19:23,000
they're going yeah because that was another point that i've heard mentioned that with tour if you're

156
00:19:23,000 --> 00:19:29,000
a government or some very large entity that can monitor both the incoming and

157
00:19:29,000 --> 00:19:39,000
outcoming port so to speak or like uh nodes yeah the data flows more or less yeah then you can

158
00:19:39,000 --> 00:19:48,000
kind of locate who is who and de-anonymize data but i took he kind of circuments that issue

159
00:19:49,000 --> 00:19:56,000
to a to an extent for certain things the the difficulty is that even in a situation like

160
00:19:56,000 --> 00:20:02,000
tour uh this kind of attack only work on certain kinds of hidden services they have to sort of

161
00:20:02,000 --> 00:20:09,000
stay in the same place and they have to have a lot of customers so like if you're doing things at

162
00:20:09,000 --> 00:20:17,000
a tremendous scale over either tour or i2p and people are trying to target you with these data

163
00:20:17,000 --> 00:20:24,000
flow analyses i think for right now you're probably still in pretty big trouble uh but

164
00:20:24,000 --> 00:20:32,000
if you are doing something where you can cycle your identity fairly frequently and maybe use a

165
00:20:32,000 --> 00:20:40,000
long-term identity that is blinded and not revealed to the network then you can actually use these

166
00:20:41,000 --> 00:20:50,000
technologies to um to be anonymous long-term because the kinds of attacks that are possible

167
00:20:50,000 --> 00:20:55,000
against these at-scale hidden services are not necessarily going to be possible against your

168
00:20:55,000 --> 00:21:01,000
bittoral client or your chat app i think that's a fair assessment of where the defenses are at

169
00:21:01,000 --> 00:21:06,000
right now and i'm not sure that there's a great way to protect an at-scale hidden service other

170
00:21:06,000 --> 00:21:13,000
than to like send an equivalent amount of cover traffic down a pipe to somebody else's hidden

171
00:21:13,000 --> 00:21:17,000
service uh and that sounds like madness yeah

172
00:21:21,000 --> 00:21:28,000
uh i can't imagine the volumes of data that would require yeah it's uh it's kind of crazy

173
00:21:28,000 --> 00:21:35,000
there are people trying it and we're reading their papers um but it's uh we're skeptical

174
00:21:36,000 --> 00:21:43,000
because that's another aspect i noticed there's a lot of papers written about i2p yeah i didn't

175
00:21:43,000 --> 00:21:50,000
count but there seems to be like a relatively large uh network of researchers who are looking

176
00:21:50,000 --> 00:21:58,000
at i2p and studying i2p yeah i think we owe some of that to a few researchers that we have been

177
00:21:58,000 --> 00:22:06,000
that we worked with in europe um and a couple more who took an interest in us out in Colorado

178
00:22:06,000 --> 00:22:12,000
and then i think there's a professor in japan who's got a thing for us as well oh and then there's

179
00:22:12,000 --> 00:22:19,000
a friend of mine ben who is a t.a. in boston who got a couple of skits to work on the paper at

180
00:22:19,000 --> 00:22:24,000
darthmouth we've been very grateful uh there should be about four more papers that we know about

181
00:22:24,000 --> 00:22:28,000
coming out this year one of which is going to be on machine learnings are you yuri

182
00:22:29,000 --> 00:22:37,000
wait like you're okay let's roll that back a minute

183
00:22:39,000 --> 00:22:46,000
so i2p and machine learning in the same sentence and paper uh why and how i think uh i guess what

184
00:22:46,000 --> 00:22:52,000
they're going to do is try and apply machine learning to that same traffic flow analysis um

185
00:22:53,000 --> 00:22:58,000
and see how granular they can get it uh and maybe make it work for things that are

186
00:22:59,000 --> 00:23:05,000
at smaller scale than the large darknet markets and whatever and we'll have to respond to that

187
00:23:05,000 --> 00:23:12,000
and it might involve changes to how we do darlic encryption or something along those lines as well

188
00:23:12,000 --> 00:23:19,000
it's likely system that it might affect so this is something i'm really curious about because

189
00:23:19,000 --> 00:23:24,000
you mentioned already before our current conversation and it's something we've touched

190
00:23:24,000 --> 00:23:34,000
on a little bit now uh which is like what you're currently developing slash working on and i2p

191
00:23:34,000 --> 00:23:40,000
has changed a bit over the years but the general concept is saying the same it sounds like what

192
00:23:40,000 --> 00:23:46,000
is in the pipelines right now what is where which direction are you heading well a couple of different

193
00:23:46,000 --> 00:23:54,000
directions actually um one very big very important uh project that we're working on right now is

194
00:23:54,000 --> 00:24:02,000
post quantum enable we did post quantum encryption for our tunnel mechanism and now we're working on

195
00:24:02,000 --> 00:24:08,000
post quantum encryption for our transport mechanism switch or distance from the tunnel mechanisms and

196
00:24:09,000 --> 00:24:14,000
then after that that probably projects probably going to take another year possibly a year and a

197
00:24:14,000 --> 00:24:22,000
half then we are going to move on to post quantum signatures and that will sort of complete our

198
00:24:22,000 --> 00:24:29,000
migration to post quantum hybrid cryptography and maybe maybe we might be the first one of our

199
00:24:29,000 --> 00:24:34,000
class of networks to do that successfully that would be pretty cool um the other thing that we're

200
00:24:34,000 --> 00:24:43,000
doing is we're working on using some of the third party or in in one case sponsored implementation

201
00:24:43,000 --> 00:24:55,000
to do things like enablement and other software stacks so uh about two years ago a uh rust developer

202
00:24:55,000 --> 00:25:03,000
named um RO outton and wrote emissary which is a full implementation of an i2p router in rust um

203
00:25:03,000 --> 00:25:11,000
and a few months ago i i completed a an effort to write an i2p router in go and basically what we're

204
00:25:11,000 --> 00:25:18,000
doing now is trying to make the um as transparent as possible to integrate those into other applications

205
00:25:18,000 --> 00:25:25,000
so if we're successful uh you know i'm probably going to try and get i2p into sync thing and you

206
00:25:25,000 --> 00:25:30,000
know an acrylix torrent which is used in a bunch of bit torrent clients and you know if i if i'm

207
00:25:30,000 --> 00:25:35,000
really lucky maybe tail scale or something like that and the goal of this is you know everybody

208
00:25:35,000 --> 00:25:41,000
in right i2p helps everybody right so by enabling more applications and helping people get get the

209
00:25:41,000 --> 00:25:47,000
things that they want working on the network we help ourselves by uh distributing the network to

210
00:25:47,000 --> 00:25:54,000
more people and getting them participated in routing and uh showing them that you know being a part of

211
00:25:54,000 --> 00:26:02,000
this network has uh has benefits that extend to that so there's like two follow up questions or

212
00:26:02,000 --> 00:26:07,000
two questions that i've been like brewing on here while listening to you uh the first one's

213
00:26:07,000 --> 00:26:14,000
related to the quantum encryption and the second one is related to your efforts of collaborating so

214
00:26:14,000 --> 00:26:21,000
i'll just do them in order and you can take them off however you want um but uh the first one is

215
00:26:21,000 --> 00:26:27,000
regarding quantum encryption and i've heard of a few different approaches to quantum encryption

216
00:26:27,000 --> 00:26:34,000
and a PhD i knew was writing a paper and he approached it by having an encryption that changed

217
00:26:34,000 --> 00:26:43,000
every few seconds which seems maybe not sustainable but i'm very curious about what your approach is

218
00:26:43,000 --> 00:26:52,000
there and then the second question is um are you building like an SDK software development kit for

219
00:26:52,000 --> 00:26:59,000
other projects to engage with i2p through or are you doing it more by project to project basis

220
00:26:59,000 --> 00:27:05,000
and how are you engaging but yeah starting with first quantum stuff fortunately for us we don't

221
00:27:05,000 --> 00:27:12,000
have to roll our own uh roll our own thing the researchers have already done at least a significant

222
00:27:13,000 --> 00:27:20,000
uh part of the research work for us our job mostly boils down to the subtleties of our own

223
00:27:20,000 --> 00:27:27,000
implementation because everything that we use for cryptography is ultimately based on some variant

224
00:27:27,000 --> 00:27:34,000
or the noise protocol handshake so for tunnels um it actually kind of depends on the context but

225
00:27:34,000 --> 00:27:45,000
it's going to be noise ik or noise n and then for ntcp and ssu2 for transports they're going to be

226
00:27:45,000 --> 00:27:54,000
noise ik and and that's actually uh that important um in detail except to know that because it's

227
00:27:54,000 --> 00:28:00,000
all noise based we get the benefit of all the research that has been done on post quantum

228
00:28:00,000 --> 00:28:06,000
noise handshakes so ultimately we're just doing the noise handshake from the post quantum noise

229
00:28:06,000 --> 00:28:13,000
paper awesome that's one of the great benefits of working with existing and established ecosystems

230
00:28:13,000 --> 00:28:20,000
that one doesn't have to build one's own wheels every time yeah yeah well then also in

231
00:28:20,000 --> 00:28:26,000
the cryptography is hard like i remember the first time i really got my head around key

232
00:28:26,000 --> 00:28:31,000
compromise interpretation you know they're not going to bother to explain it just if you

233
00:28:32,000 --> 00:28:37,000
want to know why cryptography is hard get your head around key compromise interpretation

234
00:28:38,000 --> 00:28:46,000
it is uh it is magic math that cares what kind of pen you use as the cryptographers say yeah

235
00:28:48,000 --> 00:28:53,000
so the other thing uh the other question you asked was are we building an sdk and yes

236
00:28:53,000 --> 00:29:00,000
yes absolutely we're building an sdk um two of them in fact we're building the uh the go one

237
00:29:01,000 --> 00:29:07,000
works if you compile it from the the tip of the source i'll cut a release here in the next week

238
00:29:07,000 --> 00:29:12,000
or so call it's called on ramp and it's of course sort of geared toward go developers and then the

239
00:29:12,000 --> 00:29:18,000
rest one is a little as far along but i'm gonna circle back and try to influence our

240
00:29:19,000 --> 00:29:26,000
uh toward that when uh when i have time but we uh but yeah we're gonna build sdk's the goal being

241
00:29:26,000 --> 00:29:32,000
to make it as easy to use as whatever library they're over to using whether that's you know

242
00:29:32,000 --> 00:29:39,000
standard go or standard roast or tataio or whatever that would be to pee for the ipf systems or

243
00:29:40,000 --> 00:29:47,000
yeah that's super exciting and i know a lot of people who are protocol developers who are

244
00:29:47,000 --> 00:29:53,000
going to be very glad to hear this and i think here is somewhere where i would also like to clarify

245
00:29:53,000 --> 00:30:00,000
a little bit because i'm sure i'm not the only one who's a little bit confused about what's

246
00:30:00,000 --> 00:30:05,000
compatible with what especially when we enter like the rote local first slash peer-to-peer

247
00:30:05,000 --> 00:30:13,000
realms so would i2p function in a delay tolerant network do you know what i mean when i say that

248
00:30:14,000 --> 00:30:25,000
yeah um and the certain things would i think yes um it did you know i suppose it kind of depends

249
00:30:25,000 --> 00:30:33,000
on the delay certain aspects of the network are uh our time sensitive you have to have like

250
00:30:33,000 --> 00:30:42,000
synchronized clocks to uh to know how old a router info is for instance um but there are certainly

251
00:30:42,000 --> 00:30:50,000
parts of it that could be delay tolerant um yeah and i'm guessing just to call to clarify because

252
00:30:50,000 --> 00:30:59,000
i'm using one of those terms again but uh like yeah the delay tolerant in this sense becomes

253
00:30:59,000 --> 00:31:05,000
very important because if you have internet shutdowns or if you have regions where connectivity is

254
00:31:05,000 --> 00:31:12,000
very poor like the amazon rainforest or something you want to still be able to connect when the

255
00:31:12,000 --> 00:31:18,000
connection is back up again so kind of opportunistically connecting and which is very different from how

256
00:31:18,000 --> 00:31:26,000
mmm server client systems work where you need continuous uptime but does that then mean just

257
00:31:26,000 --> 00:31:31,000
to interpret your answer a bit it doesn't sound like it's ready to go out of the box for delay

258
00:31:31,000 --> 00:31:38,000
tolerant networks but it sounds like there is some sort of compatibility potentially how much

259
00:31:38,000 --> 00:31:46,000
tweaking like let's say i'm a developer and i get access to your sdk can i just implement it in my

260
00:31:46,000 --> 00:31:53,000
protocol so is it do i have to do something um so i can answer the question for a couple of your

261
00:31:53,000 --> 00:32:04,000
cases um in the case of something like an internet shutdown uh your we can handle that to a pretty

262
00:32:04,000 --> 00:32:12,000
well-defined tolerance which i believe if i recall correctly is 72 hours although that might be a

263
00:32:12,000 --> 00:32:21,000
soft delay and what i mean by when i say that is that um you will have enough peers in your network

264
00:32:21,000 --> 00:32:28,000
who are not considered stale by your local router to rejoin the network without reaching out to a

265
00:32:28,000 --> 00:32:35,000
bootstrap server first and this actually has an interesting side effect too which it mean which

266
00:32:35,000 --> 00:32:43,000
is that if you know other people who are behind the shutdown that appears on your network you might

267
00:32:43,000 --> 00:32:51,000
actually stay connected to them depending on this how the shutdown works so you'll end up with a

268
00:32:51,000 --> 00:32:58,000
sort of mini i2p inside the shutdown network it's kind it's called it's a phenomenon of network

269
00:32:58,000 --> 00:33:03,000
segmentation and whether or not it's a good thing or a bad thing sort of depends on your

270
00:33:03,000 --> 00:33:09,000
perspective and your threat model um but it is a sort of side effect of what can happen in these

271
00:33:09,000 --> 00:33:15,000
kinds of situations and then when the shutdown ends you'd re you'd rejoin the larger network um so to

272
00:33:15,000 --> 00:33:24,000
that for that sort of situation then then yes it would be uh it would be tolerant of delays uh but

273
00:33:24,000 --> 00:33:31,000
any deeper than that it gets more subtle um you know you need to if you have to get a message

274
00:33:31,000 --> 00:33:37,000
somewhere then uh you can do that opportunistically or you can store the message somewhere and

275
00:33:37,000 --> 00:33:43,000
storing the message somewhere is more convenient usually and we don't do that so maybe you have to

276
00:33:43,000 --> 00:33:50,000
do that in your application so so so it's a it's a bit subtle there is some out of the box

277
00:33:50,000 --> 00:33:57,000
functionality for this asynchronous phenomenon but it is mostly around our own network resilience

278
00:33:57,000 --> 00:34:06,000
and not really exposed to the applications awesome uh i have two questions that immediately just like

279
00:34:06,000 --> 00:34:14,000
emerge within me and one is you said the local router do you mean local node or do you literally

280
00:34:14,000 --> 00:34:22,000
mean local router like uh that's the kind that's the software we call the i2p node um it's a it is a

281
00:34:22,000 --> 00:34:28,000
router it actually routes traffic for other people so we call it that we call it a router

282
00:34:28,000 --> 00:34:34,000
i was my mind was going to physical hardware routers and i was like oh

283
00:34:36,000 --> 00:34:41,000
okay but great uh that helps clarify that and then the other aspect i was thinking you mentioned

284
00:34:41,000 --> 00:34:48,000
that there's like this uh impromptu like local network that can form when internet connectivity is out

285
00:34:49,000 --> 00:34:58,000
um and that ties into two things uh does does i2p care about

286
00:35:00,000 --> 00:35:07,000
how the data is transferred like is it like is it sneaker not compatible can it like connect

287
00:35:07,000 --> 00:35:17,000
via any sort of means or is it tied to the internet infrastructure as we know it um yeah first part

288
00:35:17,000 --> 00:35:26,000
of the question um for i2p as it exists right now you pretty much need something ip shaped

289
00:35:26,000 --> 00:35:32,000
to run it off there are actually other kinds of darkness like cjdns and igdrasil

290
00:35:32,000 --> 00:35:40,000
um that are non-anonymous that uh we actually do to some extent interact with and you can route

291
00:35:40,000 --> 00:35:47,000
i2p over those but those are still pretty much just ipv6 networks uh that have slightly different

292
00:35:47,000 --> 00:35:54,000
properties than the one that um we have now that being said though there are like the the tricky

293
00:35:54,000 --> 00:36:01,000
bit is to make sure that the things that you change about how the network operates don't affect

294
00:36:01,000 --> 00:36:07,000
how anonymous the users are so like yeah we could probably implement some kind of sneaker net

295
00:36:07,000 --> 00:36:16,000
transport arguably sort of at least at the bootstrap level we do so like i2p relies on this

296
00:36:16,000 --> 00:36:24,000
distributed data structure to find the peers in the network that you need to uh to they need to

297
00:36:24,000 --> 00:36:30,000
talk to and we transmit the information about these distributed data structures over what we call

298
00:36:30,000 --> 00:36:39,000
the transports now um and so if the uh but the transports are just sort of an interface

299
00:36:40,000 --> 00:36:50,000
so if we wanted to we could in theory make a sneaker net transport where you plug a plast drive

300
00:36:50,000 --> 00:36:57,000
into your computer hit the sneaker net transport button it copies something to your flash drive

301
00:36:57,000 --> 00:37:02,000
you know to the next computer any trans any of uh shared some transport information and to some

302
00:37:02,000 --> 00:37:10,000
extent like that kind of exists um for for instance like when you join the network you get a zip file

303
00:37:10,000 --> 00:37:16,000
full of pure seed information and that is possible to transfer over the sneaker net now and that's

304
00:37:16,000 --> 00:37:23,000
exactly the sort of data that would be transferred over the um over the regular transport ports except

305
00:37:23,000 --> 00:37:28,000
it's being transferred involved there another interesting possibility might be to build something

306
00:37:28,000 --> 00:37:35,000
on top of like lower when or mesh mesh tastic to exchange exactly the same routing information

307
00:37:35,000 --> 00:37:41,000
although you know each of those things sort of has different kinds of exposure uh that it gives

308
00:37:41,000 --> 00:37:50,000
you two um sneaker net will be timing sensitive mesh tastic is broadcasting messages encrypted or

309
00:37:50,000 --> 00:37:58,000
not into the air uh around your house so like uh absolutely we could but it is a situation where

310
00:37:58,000 --> 00:38:04,000
more research is required to determine whether or not we should. Last but not least maybe about

311
00:38:04,000 --> 00:38:15,000
of these kind of questions the the there's been a researcher uh who's kind of dubbed this

312
00:38:15,000 --> 00:38:24,000
phenomenon uh grassroots networks and in scuttlebutt we used like that a network didn't have a single

313
00:38:24,000 --> 00:38:34,000
term um and it basically is just different ways of describing if a network enables you to start

314
00:38:34,000 --> 00:38:41,000
one part of a network a circle let's say in one area that later meets another circle in another

315
00:38:41,000 --> 00:38:46,000
area and then they can integrate with each other is that possible with i2p as well yeah absolutely

316
00:38:46,000 --> 00:38:53,000
in fact i think it's probably really one of our defining features yeah the network as long as it

317
00:38:53,000 --> 00:39:02,000
can contact itself eventually converges into a into a global phenomenon yeah well i'm a little

318
00:39:02,000 --> 00:39:06,000
bit lost track of how long this episode is because we've had a lot of coming to the issues

319
00:39:07,000 --> 00:39:16,000
yeah um but uh hopefully that will be entirely not noticeable when i have been finished editing

320
00:39:16,000 --> 00:39:26,000
this podcast um but uh on that note you mentioned that you're building these SDKs and what the

321
00:39:26,000 --> 00:39:32,000
next steps are exciting that they're going to be released so soon and he's mentioned also that you

322
00:39:32,000 --> 00:39:38,000
have a release already next week or in two weeks or something oh i'll have it ready soon um i'm

323
00:39:38,000 --> 00:39:45,000
definitely a week feels like a week feels like plenty in time but a week always feels like plenty

324
00:39:45,000 --> 00:39:52,000
in time yeah so a month yeah exactly i mean to you know patted out like monty scot

325
00:39:54,000 --> 00:40:00,000
nice maybe we'll synchronize the releases of this podcast episode on your release or we'll see how

326
00:40:00,000 --> 00:40:06,000
we go about it but uh people who want to contribute to IDK or sorry no saying your name

327
00:40:07,000 --> 00:40:16,000
but uh people who want to contribute to i2p um how do they go about it well we accept uh

328
00:40:16,000 --> 00:40:23,000
contributions on github and gitlab um and we're also pretty flexible about things like

329
00:40:24,000 --> 00:40:31,000
uh receiving patches to our security and research emails uh which are security at itp.net

330
00:40:33,000 --> 00:40:41,000
and research at git itp or research at itp.net um where we we've taken patches over irc

331
00:40:42,000 --> 00:40:50,000
in the project internal irc that's itprc and it's built into the um both i2p and itpd

332
00:40:50,000 --> 00:40:56,000
so if you can connect to it there then you can connect to us and we will accept patches over irc

333
00:40:57,000 --> 00:41:03,000
uh we've accepted patches via paste bin mostly we just want to be able to review the code

334
00:41:03,000 --> 00:41:10,000
um but the easiest way to get us is probably either github or irc is there anything else that

335
00:41:10,000 --> 00:41:16,000
you're sitting with you're like yes this should be mentioned before we wrap up oh um you know i

336
00:41:16,000 --> 00:41:28,000
think that the the um might be good to point out the the namespaces for the two new router projects

337
00:41:29,000 --> 00:41:40,000
there is uh eepnet emissary it's eepnet slash emissary on github that's the rest implementation

338
00:41:40,000 --> 00:41:52,000
and then go itp slash go itp uh is the go implementation and one last thing is that uh for about 12

339
00:41:54,000 --> 00:42:00,000
13 years we were unable to take donations due to not being a registered nonprofit

340
00:42:00,000 --> 00:42:06,000
we have since partnered with a registered nonprofit uh stormycloud.org so if people want to donate

341
00:42:07,000 --> 00:42:13,000
i2p they can donate via stormycloud now. awesome actually that ties into one of the questions

342
00:42:13,000 --> 00:42:20,000
that i forgot to ask that i usually ask which is how do you fund yourselves? well for a long time

343
00:42:20,000 --> 00:42:30,000
we didn't. yeah nowadays yeah we have a certain degree of we have more flexibility in how we fund

344
00:42:30,000 --> 00:42:40,000
things now and um with with stormycloud being involved and so you know my taxes got easier

345
00:42:40,000 --> 00:42:50,000
that's for sure. congratulations for that happy to hear the more sustainability the better um

346
00:42:51,000 --> 00:43:03,000
well thank you so much for joining idk and i hope to run into you again sometime have a lovely day

347
00:43:03,000 --> 00:43:09,000
yeah you too thank you for having me on your podcast again thank you take care you too

348
00:43:20,000 --> 00:43:24,000
so

349
00:43:35,000 --> 00:43:39,000
so