IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2022/07/19
~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+Xeha
+acetone
+bak83
+cumlord
+hk
+poriori
+profetikla
+weko
An0nm0n
Arch
Danny
DeltaOreo
Irc2PGuest21357
Irc2PGuest21881
Irc2PGuest42386
Irc2PGuest5995
Leopold_
Meow
Nausicaa
Onn4l7h
Onn4|7h
Over1
anon2
anu
boonst
mareki2pb
not_bob_afk
plap
shiver_
simprelay
solidx66
thetia
u5657
uop23ip
Mustafabo hey dr|z3d
dr|z3d what up M
Mustafabo oh you know
Mustafabo straight up gangster shit
Mustafabo how about you?
dr|z3d shizzle dizzle, yo.
Mustafabo dr|z3d, installing i2p+ from dev build exe doesn't work
dr|z3d what's the issue?
dr|z3d if you're on windows, are you installing as admin?
dr|z3d need more info.
Mustafabo the service fails to start
dr|z3d so did you run the installer with admin privs?
dr|z3d Blinded message
dr|z3d do so, you should find things work as expected then.
DreadfulParis This is me swinging by. I have registered this name. But it doesn't matter because in the case I forget the password here I can prove my identity otherwise.
dr|z3d great, welcome DreadfulParis
dr|z3d are you one of the admins on Dread?
dr|z3d I have to ask, there's been a lot of bullshit over there lately :)
DreadfulParis I am. If you would like I can provide a signature.
dr|z3d bah, no need. I'll take you word for it.
dr|z3d So I hear you don't rate java i2p much?
DreadfulParis The performance has been terrible for my use case.
DreadfulParis However I had much better luck with i2pd.
dr|z3d are you running on a raspberry pi?
RN ;)
dr|z3d ok, just checking. :)
DreadfulParis But the networking is difficult when going outside the dread cluster.
dr|z3d and did you have a look at I2P+ ?
RN ^^^^^
DreadfulParis So I fully do think it could have been my fault.
dr|z3d disclaimer: I develop I2P+ :)
RN hehehe
DreadfulParis I'm not sure what you mean by i2p+
DreadfulParis is it a fork or port of i2p?
dr|z3d yeah, I'm surprised you find the performance bad. it should be stellar when configured correctly.
dr|z3d I2P+ is a "soft" fork of I2P, it's been advertized on dread for the last several releases :)
DreadfulParis Oh I think DeSnake mentioned this before.
dr|z3d it's tuned for high performance servers, though not at the expense of average joe.
DreadfulParis I'll take a look. Please do understand I'm just sharing my experience. My use case is not normal.
dr|z3d (and can be further tuned with additional configs)
dr|z3d I get that you obviously didn't get the best experience when you tried it. which is a shame, there's plenty to offer than i2pd doesn't.
DreadfulParis I'm checking it out.
dr|z3d in respect of dread, a couple of things that stand out.. tunnel throttling and rate limiting, always handy to mitigate any potential ddos.
DreadfulParis That's ideal.
dr|z3d there's also active sybil detection and automated blocking, another thing that i2pd doesn't offer.
DreadfulParis The way the i2pd system is setup is with basic fronts of nodes before the true i2pd client.
DreadfulParis We minimize sybil detection that way. While of course burning a lot of servers along the way.
dr|z3d and with i2p+ you also get to choose the very best routers for your own tunnels.. low latency, recent versions, and high bandwidth otherwise they don't get chosen. great if you're looking for responsive server tunnels.
DreadfulParis Also ideal.
DreadfulParis Thanks for this. I did have it mentioned to me but I didn't get the time to check it out.
dr|z3d oh, did I mention it also has dread.i2p on the homepage, complete with a custom icon? :)
DreadfulParis We don't recommend anyone use the addressbook system.
DreadfulParis I personally don't like that kind of transparent trust relation systems.
DreadfulParis Always b32 address.
dr|z3d that's overly cautious.. just validate the dread.i2p address against various providers and it should be mostly good.
DreadfulParis It's more so to prevent a lot of the issues the Tor network has had over the years with centralized link providers.
dr|z3d you'll see it's all present and correct on skank.i2p/hosts.txt | notbob.i2p/hosts.txt etc.
DreadfulParis Yes. But that is right now.
DreadfulParis The problem comes when those systems get compromised.
DreadfulParis It's a point of failure and trust that simply isn't needed.
DreadfulParis Specifically when the idea is to transfer away from the Tor network.
DreadfulParis We don't want to regress.
dr|z3d for the most part, those centralized link providers are pretty good. ordinarily, you can't just register an address without actually owning it.. authentication we call it.
dr|z3d one provider's been running for 20 years and hasn't been compromised yet. he's the i2p lead developer.
dr|z3d the other main provider is the i2pd team. so, you know, pretty solid.
DreadfulParis In my field you don't trust anyone. You make systems that are self authenticating.
DreadfulParis Like these b32 addresses.
DreadfulParis With that being said I am having troubles scaling more.
dr|z3d oh? multihoming not doing it for you?
DreadfulParis The randomization of the leaseset when I multihom provides... well... random and undetermined outcomes.
DreadfulParis As of course it does.
dr|z3d it should for the most part be pretty reliable if the backend servers are all more or less equal.
DreadfulParis I'm not sure if you know how the resolution process of the onion service goes like but it provides a near complete control of what fronts get what traffic from where.
DreadfulParis Being that we can push specific front introduction points into the master descriptor into certain HSDIR to provide a near complete roundrobin load balancing.
dr|z3d haven't looked at it in a while.
DreadfulParis Assuming the introduction points and guard nodes don't die on the network.
DreadfulParis Which is becoming more and more of a problem.
dr|z3d well, you have a couple of options with i2p, one which is less predictable, the other which gives you a single front-server round-robining on the back end.
dr|z3d using something like haproxy.
DreadfulParis Tor's introduction cell layer doesn't have proper limitations and allows a cell spam attack which is quite disastrous for the network.
DreadfulParis I think you need to understand the specific use case I need.
dr|z3d yeah, I hear Tor has plenty of ongoing issues with their hidden service component which they're not rushing to fix.
DreadfulParis Onion services are a second rate citizen.
DreadfulParis As I explained recently I2P is way better suited for the kinds of communications the darknet really needs.
DreadfulParis While Tor is designed for traffic ultimately outside the network. I2P is designed for traffic inside the network.
DreadfulParis Plus with the long running process of I2P timing and corrlation attacks become less of a problem.
dr|z3d indeed. tor's hidden services component was an afterthought, whereas it's front and center on i2p. which makes i2p less popular if all you want to do is browse the web unmonitored by your isp.
DreadfulParis Yes. But it is ideal for private torrenting and hidden sites.
DreadfulParis If I could ask please take the time to read this and let me know if I said something incorrect. The logic is what I base a lot of the future plans on.
dr|z3d Blinded message
dr|z3d slowass site :P
dr|z3d still loading...
DreadfulParis It's mostly resolution issues I would think.
dr|z3d resolution issues?
DreadfulParis A lot of different leases are getting pushed. People don't want i2p to be that stable.
dr|z3d I don't think it's a question of acquring the leaseset so much as just slow tunnels.
DreadfulParis Potentally that as well. When the new recon update comes I have a new network design which is better suited for i2p usage.
dr|z3d not sure what you mean there.
DreadfulParis Dread's cluster is a global cluster.
dr|z3d it was the part about java i2p being complete trash which caught my eye. I was mulling a response, but you're here now, even better.
DreadfulParis We protect core servers by having layers of trusted servers in front that the main cluster can only communicate with.
dr|z3d and I'm guessing you're also routing everything over Tor.
DreadfulParis When it comes to i2p
DreadfulParis It's directly a series of i2p nodes.
dr|z3d oh? good. don't do that with i2p. it's not a good idea.
dr|z3d (whatever DeSnake may think)
DreadfulParis Obviously. I hope you do think better of me after having a long discussion.
DreadfulParis I do have a bias against Java as a language itself.
DreadfulParis This comes from my past history working with java and the pain in the ass it becomes.
DreadfulParis I am much more confident in C++ binaries.
dr|z3d I never had much of an opinion tbh, you help run dread, you seem competent enough. and over there, you're all hating on java i2p without really giving it the full benefit :)
DreadfulParis Oh believe me. I gave it the full benefit.
DreadfulParis If you search on my profile about i2p you can see my experience.
DreadfulParis I couldn't have gone worse.
DreadfulParis I gave up on it multiple times.
DreadfulParis It just didn't have the performance.
DreadfulParis And couldn't handle the load tests. Mostly because it didn't do proper load balancing like I could do on Tor.
dr|z3d for most of the dread users, i2p/i2p+ is probably a much better bet and overall a better experience, though as DeSnake would have it, everyone MUST RUN I2PD! MUST!
DreadfulParis We don't like java. It's a shared experience.
dr|z3d I don't know why you'd suggest it doesn't have the performance.. give it some ram and a few cores, a nice fat pipe, it'll absolutely fly.
dr|z3d sure, it's got a bigger footprint than i2pd, but it comes with a lot more knobs, bells and whistles to compensate :)
DreadfulParis How much performance do you think is reasonable to expect out of a single instance with a 3rd generation ryzen 5950x and a 1Gbit/s pipe?
DreadfulParis That's not a good thing.
dr|z3d how would you be measuring performance?
DreadfulParis You need to understand less is more when it comes to us. Less footprint for mistakes.
DreadfulParis Basic load testings. 10 deployed servers that have i2pd running on them for over 24 hours gets run with a very simple script.
DreadfulParis It basically connects to the local i2pd process via socks and records how long it takes to load the first byte on the requested site.
DreadfulParis And if that resolution fails.
DreadfulParis Which on the java i2p version it did. A lot.
DreadfulParis On the i2pd version it was much more stable. But the resolution process was still slow compared to other sites.
DreadfulParis Again there are some network tricks I have been doing which does prevent a lot of the regular connections from happening.
dr|z3d you're essentially talking about acquiring leasesets.
DreadfulParis I did come in here to talk about proposal 123 and 140.
dr|z3d I've spent some time looking at improving that in I2P+, it now hits a lot more floodfills concurrently and takes a lot longer to time out before fail.
dr|z3d sure, feel free to speak your mind. you'll probably want to raise the issue with zzz and orignal at some point too.
DreadfulParis I would personally be focusing on 140 on my end to improve the resolution process.
DreadfulParis It is more simuliar to how onionbalance does it on the Tor network.
DreadfulParis Plus it doesn't really require any changes on the overall network to adopt.
dr|z3d is this garlicfarm, remind me..?
DreadfulParis 140 is invisible multihoming.
dr|z3d let's have a look at that.
dr|z3d yeah, I'm there.
dr|z3d the main issue appears to be the disclosure of online servers in a cluster.
DreadfulParis Currently the way I understand about the resolution process is when you run multiple different i2p processes that have the same eepsite key they push to floodfills their leaseset. The latest one will take priority.
dr|z3d yes, and no.
dr|z3d when you multihome, the router hosting the service will push out a new leaseset to the closest floodfills every 10m or thereabouts.
DreadfulParis I would appreciate some education.
dr|z3d if you have multiple routers hosting the same service, they'll all likely be speaking to different floodfills.
dr|z3d when a client wants to visit your site, the router will request the leaseset for dread.i2p from the nearest floodfill, or in the case of i2p+, several floodfills simultaneously.
DreadfulParis Being that there is about 2500 floodfills the chances do seem to be in the favour.
dr|z3d so both my proximity to floodfills, and the server's proximity to floodfills, will both influence which leaseset I receive.
DreadfulParis What happends when a user requests from a single floodfill but it doesn't have the leastset?
dr|z3d it'll ask another.
DreadfulParis Until it finds it?
dr|z3d or it times out looking.
DreadfulParis Any idea what the time out for that is? 60 seconds?
dr|z3d it varies depending on implementation. in i2p+, it may be anything up to 90s or x floodfills, I forget the exact number offhand, but it's enough to get a definitive answer VERY quicky, usual in the order of milliseconds.
DreadfulParis You know that makes a lot of sense now that I think about it.
dr|z3d it's not perfect round-robin, but neither is it super-predictable.
dr|z3d but it's pretty reliable for the most part, assuming your servers are.
DreadfulParis Thanks. That provided me good insight into why there would be some resolving issues on certain requesting nodes.
DreadfulParis The solution for me is to push to half of the floodfills.
DreadfulParis And for most of them the ones I personally control.
dr|z3d I think vanilla i2p has more of an issue, lower timeouts, less concurrent searches.
dr|z3d and from the server perspective, i2p+ is also pushing the leaseset to more floodfills, so it propagates quicker.
DreadfulParis The onion service resolution process is different.
DreadfulParis It's like a ring where certain points correspond to the fingerprint of certain nodes in the entire tor network.
DreadfulParis So depending on the public key and the tor network descriptor the nodes that both the onion service and the user go to are the same.
DreadfulParis It's predetermined.
dr|z3d which is great if you want to ddos the circuits.
DreadfulParis But there are some tricks you can do to spread out over many replicas around the ring.
DreadfulParis It also greatly limits the amount of introduction points you can have.
DreadfulParis Say you have 100 fronts.
dr|z3d one thing you should be aware of re multihoming.. you can't just extend the number of servers indefinitely.
DreadfulParis They all have 3 introduction points in their descriptor.
DreadfulParis Oh I'm aware. But you can extend them far far larger than you can on the Tor network.
dr|z3d for a 3 hop service, your limit is around 4 multihomes iirc. more than that, and floodfills will start to throttle.
DreadfulParis What do you mean? Do floodfills share the leaseset?
DreadfulParis I thought it was just random. The closes ones.
DreadfulParis I'm not so much pushing the stuff more than a regular site. Once every ten minutes.
dr|z3d what I mean is that you're rate-limited when publishing your leasesets to any given floodfill.
DreadfulParis Is it like a burst rate-limit?
DreadfulParis Wait. Could you point me to the code?
DreadfulParis That would clear it all up.
DreadfulParis and you would know.
dr|z3d after a while (think 4 multihomes) the floodfill will ignore you for, what, a 10 minute period or maybe slightly less.. but the main takeaway is that if you want _reliable_ service, 3 hops == max 4 multihomes.
DreadfulParis well there is a problem
dr|z3d there is, if you're running more than 4 multihomes on 3 hop tunnels :)
dr|z3d give me a moment, I'll see if I can find the code.
dr|z3d that's why I mentioned haproxy. you can extend the number of servers you're running that way, which obviously doesn't bump into the same limit.
DreadfulParis But that concentrates it on a single point right?
DreadfulParis For the first connection
DreadfulParis So in the case of a large DDOS attack it might cause reliability issues.
dr|z3d well, you'd distribute over several i2p instances.. so say 4 multihomed servers with however many backend servers behind that.
DreadfulParis Is this haproxy system something documented?
DreadfulParis I know that. I mean more so for i2p
DreadfulParis Like how does it direct the traffic after resolution.
DreadfulParis Does it still stay on the HAPROXY?
DreadfulParis The goal is to spread the load over many different i2p processes on completely seperate servers that will talk to the Dread cluster backend.
dr|z3d client -> i2p instance -> haproxy -> round-robin to one of a number of ips hosting the service.
dr|z3d that's basically how it works.
DreadfulParis So the traffic gets directed through the haproxy.
dr|z3d yeah, haproxy handles which backend server the client gets to talk to.
DreadfulParis That's not so much of an issue. The Dread cluster has a resolution load balancing already. It's not the backend which is slow (generally speaking). It's the connection point.
dr|z3d it's a method of extending the number of backend servers handling your service, if you really need a huge number of servers to handle the load.
DreadfulParis Yes I understand that.
DreadfulParis But that isn't what I need. I need resolution from the floodfills.
dr|z3d well, if you're running several instances already, make sure you're not running more than 4, for one thing, and also see what I2P+ can do for you, once it's been running for a while and got properly integrated.
DreadfulParis Enough that when an attacker comes (they will come) they will need to request from half of all floodfills to get all my i2p processes overloaded.
dr|z3d well, that's the other thing, tunnel throttling and filtering. you can fuck off most ddos attacks that way. not all, but average skiddy hacker won't have much of a chance to do any real damage.
dr|z3d and that's another thing to mention. whatever you're doing now is probably not optimal. ElGlamal leasesets? Don't.
DreadfulParis in i2p there is a banlist on floodfills for looking up the resolution.
dr|z3d you only need ECIES leasesets. much, much harder to consume server resources that way.
dr|z3d there's a temporary list held in ram.
DreadfulParis Lovely. Another reason why my requests were probably failing on the testing nodes.
dr|z3d let's see what you're doing with your leasesets....
DreadfulParis They were getting banned.
DreadfulParis Well I will be changing it around.
DreadfulParis And I'll probably run half of the nodes with the i2p+
DreadfulParis To see if that improves resolution speed.
dr|z3d leasets look good, ECIES only?
DreadfulParis They should be the default that i2pd pushes out.
DreadfulParis I'm running too many i2pd processes.
DreadfulParis That's what I'm getting out of this discussion.
DreadfulParis I won't mention how many of them I'm running. But it's a lot.
dr|z3d sounds like it.
dr|z3d less is more, except when it's not :)
dr|z3d oh, I bet it's a legion and a half. just try 4 :)
DreadfulParis You vastly underestimate how much traffic Dread has.
DreadfulParis But if i2p+ is fast and stable and can scale with more cores and a bigger pipe.
DreadfulParis Well I'll get it figured out.
dr|z3d no, not underestimating that at all. I'm just telling you what the network limits are, if you're multihoming.
dr|z3d if you want to go 0 hop, you can do around 20 instances. :)
DreadfulParis Can't go 0 hop. It will be 3 hop
DreadfulParis Where one will always be one of my i2pd processes.
DreadfulParis Assuming 2000 active concurrent users requesting what is the ideal configuration?
dr|z3d I know, I was joking. 0 hop isn't for anyone running anything vaguely off-grid, if you know what I mean.
dr|z3d ideal configuration for i2p+ you mean?
dr|z3d it should be happy enough with max 2G of ram and an initial heap of 768M, though you'll only find out if you need more less when you're hitting those limits.
DreadfulParis Some requests take over 1MB
dr|z3d ~/i2p/wrapper.config is where you'd configure that, assuming you're installing to ~/i2p/
DreadfulParis specifically for the ads and headers of the subdreads.
DreadfulParis When sending requests over the i2p network what kind of packet sizing does it do?
dr|z3d yeah, but you're not buffering all those requests in i2p+'s ram.
DreadfulParis I would basically be pushing it through i2p as fast as possible.
dr|z3d MTU is currently around 1500 minute headers, so I think we're looking at max 1480.
DreadfulParis Okay so basically the same as Tor.
dr|z3d or thereabouts.
dr|z3d sure, the speed limit is invariably the other routers in the tunnel. more routers, the slower it gets.
dr|z3d at least with i2p+ you're getting the lowest latency routers in your tunnels once your router's had time to profile them.
DreadfulParis That's good.
dr|z3d and you can tune that so you reject say any router that takes more than 400ms to complete a test.
dr|z3d (or whatever)
DreadfulParis So that's pretty basic.
dr|z3d and graphs, don't forget those. enable as many as you think you need.. they'll give you some nice data-over-time visuals to see how your router's doing.
dr|z3d basic in what sense?
dr|z3d latency testing is in conjunction with various other filters that remove a subset of routers from the picture before they're even tested.
DreadfulParis Ya that's not going to be a big thing for me. Most of the systems run in anemic containers when it comes to fronts.
dr|z3d just saying, if responsiveness is something you're placing emphasis on, there are various knobs to twiddle to optimize.
DreadfulParis More data is better when it comes to this I guess.
dr|z3d and yeah, in i2p/i2p+ graphs aren't expensive, and they do give you some good insight into how your router's coping, especially when it's serving a huge number of clients.
DreadfulParis One thing I really did like with i2pd is that you can built it as a static binary.
DreadfulParis Just put the binary in the container with the configuration and run it.
DreadfulParis Boom it's up
DreadfulParis Oh and the offline site key
DreadfulParis How is the nat hole punching on i2p+?
dr|z3d pretty good, though if you're running firewalled you'll not be getting the full experience.
DreadfulParis The firewall we have I think is one of the main issues that i2p has.
dr|z3d i2p really wants to be able to talk to other routers and host tunnels. good for performance, and good for cloaking your own traffic.
DreadfulParis The new network design with recon's cluster is much better and more designed for the kind of traffic i2p does.
dr|z3d if you can open the port on the firewall for tcp/udp, you're laughing. single port.
DreadfulParis On Tor it's easy enough to select your own specific guard nodes and limit the firewall to them.
DreadfulParis Or even bridge
dr|z3d yeah, i2p's a different model. you really want to be able to talk to everyone on the network.
dr|z3d not like Tor which is centralized.
DreadfulParis As I explained in my post i2p is more ideal the more people who use it.
DreadfulParis Is there a proposed rust implimentation of i2p?
dr|z3d absolutely. the more users, the better for everyone.
dr|z3d there's a half finished rust implementation. bit-rotting as we speak.
DreadfulParis While I understand your attachment to the java version, without the ability to complie to a single binary and needing the large openjdk dependency it's a major drawback.
DreadfulParis Got a link to the rust version?
DreadfulParis I can probably put a few thousand or so into getting developers working on it.
dr|z3d for some, sure, for many, it's just another app they install on their desktop. have a serious look at i2p+, put yourself in the shoes of average newb, and see what they're getting exposed to vs i2pd. I think, on balance, for many i2p+ is infinitely better if you want people to get interested enough to hang around.
DreadfulParis The goal is to make it as a drop in replacement to the regular Tor process.
dr|z3d google for str4d rust i2p
DreadfulParis So we can steal the torproject browser and just swap out the process.
DreadfulParis See what I'm getting at?
DreadfulParis It's impossible to do with the regular java i2p implimentations.
DreadfulParis There is too much opinionation on the experience.
DreadfulParis For my liking.
DreadfulParis For example you are familiar with this layout: skank.i2p/resources/images/dark.png
DreadfulParis But for the regular user it is just way too much.
DreadfulParis It is designed for a different era and person.
DreadfulParis People on Tor just want to visit sites reliably.
DreadfulParis Like a regular browser but just more private.
DreadfulParis They don't want to do anything with the command line. They just want to click one button.
DreadfulParis and it shows a regular experience they all know. A browser.
DreadfulParis Oh the rust implimentation isn't as bad as I thought it would be.
DreadfulParis nvm I just started looking at the code.
dr|z3d sorry, was afk.
dr|z3d yeah, I hear what you're saying regarding click and go. the tor browser is something grandma can use. but if you can handhold users during the initiation period, they stick around and contribute. tor is 99% users, 1% contributors. we like to think i2p encourages participation, not just use :)
DreadfulParis It does encourage participation. Because if you get it working you don't want to let all your work go to waste.
DreadfulParis It needs to be dead dumb.
dr|z3d and if you look beyond the screenshots on skank, there's a fairly big chunk of help thrown in with i2p+, an entire section in the console dedicated to it, and more to come!
dr|z3d but sure, I hear what you're saying.
DreadfulParis Okay so the rust code isn't terrible but it isn't ideal. Some protions will need to be rewritten to improve readability.
dr|z3d unfortunately str4d dropped out of the picture a couple of years ago, we haven't seen much of him since.
dr|z3d but if you're up for pushing rust forward, he's probably contactable via github.
DreadfulParis I would completely change the standards and only use the main ones on the network. Like BOB or the NTCP standards.
dr|z3d not BOB. BOB's deprecated.
dr|z3d you'd want SAM.
DreadfulParis Oh sorry I mean not them.
DreadfulParis What in the world did I write lol
dr|z3d and both BOB (formerly) and SAM are optional extras, not core features.
DreadfulParis i2pd still uses bob which is not right.
dr|z3d barebones, you'd probably want to support i2cp, SSU2 and NTCP2.
DreadfulParis Well rust already has NTCP2
dr|z3d it's a slow process migrating people over to SAM.
DreadfulParis Why is that?
dr|z3d not that BOB is used much in the wild anymore. I think retroshare was the main app, and that's now using SAM afaik. SSU2 is about 90% complete as we speak.
DreadfulParis Not samv3?
dr|z3d samv3 is what you'd want to support for sure.
DreadfulParis The goal is to push the standards forward not to make it really backwards compatible fully if you are doing a rewrite.
dr|z3d I mean, if you want other apps to be able to use i2pd for their own purposes, above and beyond i2cp.
DreadfulParis Sam is great for an application standpoint.
dr|z3d i2pchat uses samv2, fwiw.
dr|z3d linked in the topic, if you're not familiar.
dr|z3d it's a fairly rudimentary chat app, 1 on 1, with file transfer built in. fwiw = for what it's worth.
dr|z3d like much of the projects on i2p, needs developers. I've given it an updated ui, but my time is limited and my c++ skills are fairly limited.
dr|z3d but still, if you want a private chat app that doesn't require a cellphone or central servers to operate, it's pretty handy.
DreadfulParis reminds me of ricochet
DreadfulParis It would be interesting to have an openwrt plugin for i2p.
dr|z3d you can run i2pd on openwrt, not sure if that's what you mean. that's where i2pd excels and java i2p has no chance. embedded.
DreadfulParis So it seems that str4d is working with zcash now.
dr|z3d indeed he is, for the last several years.
DreadfulParis Still alive.
dr|z3d he more or less migrated away from i2p and over to zcash.
DreadfulParis Well zcash isn't a competition to i2p. But it makes sense why they would hire him.
DreadfulParis Specifically at the time.
DreadfulParis Most cryptocurrency projects are building on rust.
DreadfulParis I'll be heading off. Thanks for the information. You have been a big help.
dr|z3d before I forget, there's a way to help your users get a 100% bona fida b32 for dread.i2p into their addressbook, so cake and eat it. addresshelper.. familar with that?
dr|z3d sure thing, hope we see you again. :)
dr|z3d feel free to drop by again when you've got i2p+ up and running and want help fine tuning :)
dr|z3d addresshelper for dread,i2p ->
dr|z3d Y7HH2ZsOybwpUWwgh7D201XKrDqyYESKShFwDvhLnKq6n2a8X8yBUtfJ2XdMOL7pmTUBWiZ-JTIOw59Va3zk92rZMKUh2nqsXRnrdI1X8cQJqMyhA8iG8E2mBlDirDiWQBQAEAAcAAA==
DreadfulParis What is this addresshelper? A kind of signed fingerprint?
dr|z3d it's a hostname + b64 in essence.
DreadfulParis Does it update the addressbook at the same time?
dr|z3d if a user already has it in their addressbook, they'll go straight there, otherwise, they'll be offered the option of adding to addressbook.
DreadfulParis assuming they are using the java i2pd clients.
dr|z3d I think i2pd supports addresshelpers the same as java i2p.
mesh huh that works. though it's a bit disturbing
dr|z3d there may be some subtle differences of course.
mesh I guessI I2PTUnnel is doing some kind of intercept
dr|z3d with i2p, you have the option of session only, or saving to one of your addressbooks.
DreadfulParis I still don't like the addressbook system.
DreadfulParis Too much potental for compromise.
dr|z3d you'll come to like it. much easier than remembering a ~52 char address :)
DreadfulParis You don't rememeber. You bookmark.
mesh yeah, having an address book in the router is probably a bad idea
dr|z3d yeah, sure, so you make sure you trust your sources.
dr|z3d it makes for a much easier system to navigate around. notbob.i2p for example.
DreadfulParis Or you can just bookmark things and name them.
DreadfulParis and use the b32 address without the problem of the addressbook becoming compromised later on.
dr|z3d you can do that of course. but sites with hashes for names are much less disocverable. look at tor onions!
DreadfulParis I'll tell you. Absoutely 0 admins on the tor network will be like "use an address book"
dr|z3d your addressbook won't get compromised without your direct intervention.
DreadfulParis Or the intervention of the main addressbook source when you first load up your processes.
dr|z3d once an address is in your addressbook, it can't be overwritten with a new one without your explicit intervention.
mesh well if i2p ever does become popular the address book will be a major attack vector. you'll see a lot of energy being put in trying to get people to add the wrong addresses
DreadfulParis It is a bad decision. I can understand from a discoverbility point but it's not ideal.
DreadfulParis The moment i2p becomes more popular those address books are getting compromised.
dr|z3d so if a host list is compromised and starts serving dodgy addresses, any existing addresses in your addressbook will be intact and any differences will be flagged in BIG LETTERS!
dr|z3d it'll take all of .5s for the network to learn that a host list is compromised.
DreadfulParis Yes but the thing is when markets are under attack they change their address.
DreadfulParis A mirror system
DreadfulParis To hide from the attacker.
dr|z3d yeah, that's Tor.
DreadfulParis It would be the same for i2p generally speaking too.
DreadfulParis There will be mirrors.
dr|z3d on i2p you mitigate the attack differently. tunnel throttling, that sort of thing.
DreadfulParis Specifically because servers can get seized.
DreadfulParis tunnel throttling is simular to the anti-ddos system that Tor has.
DreadfulParis It throttles the connections to the process.
DreadfulParis Which is bad for reachability.
dr|z3d well, sure, if you need to update your hostname/b64 combo, you keep hold of the privkey.dat file and you can update.
DreadfulParis In the case the privkey.dat is compromised, what then?
dr|z3d so seized servers don't need to mean a new hostname/dest.
DreadfulParis Have everyone visit the compromised site via the address book?
DreadfulParis On Tor what happends is the admin spams introduction points to counter the compromise.
DreadfulParis Putting a signed message with the new address.
DreadfulParis So when people load the page they will see not a honeypot but a signed message directing to a new site with a big warning that the server got seized.
dr|z3d not so different to multihoming.
DreadfulParis If people use an address book while I guess you can spam the leaseset there is rate limits and blocks in place.
DreadfulParis Basically.
DreadfulParis It's crude though.
dr|z3d "we've been compromised, here's the updated address" kinda thing.
DreadfulParis and unreliable.
dr|z3d but sure, if you're compromised, you're compromised.
mesh there'
mesh there's no ssl in i2p so it doesn't really matter either way
dr|z3d that's where offline emphemeral keys come into play :)
DreadfulParis Yes. With the v3 address on Tor it has became much easier. But before that we used onionbalance.
mesh all it takes is sending users an email or posting a forum saying "the new address is here" and a bunch of people will go to that link and type in their passwords
DreadfulParis So in the case of a front getting compromised we just remove the front's introduction points from the main descriptor.
dr|z3d you can keep your master key safe, and create keys with a fixed lifespan (think ssl certs) for i2p services you hand out to your various servers.
DreadfulParis Nobody uses fucking email. It's unsafe.
dr|z3d attacker gets an ephemeral key with a 3 day lifespan. oh dear.
mesh dr|z3d: can you really do that? last time I had this convo with zzz he said there's no way to actually attach a Certificate to a Destination
dr|z3d 3 days later, they're useless.
DreadfulParis Yes that's true. With offline keys you don't need to worry.
mesh though that is really the solution. if you could sign a Destination then people could be confident that the Destination goes to a legitimate place
dr|z3d I'm talking about offline keys, mesh, not ssl certs.
DreadfulParis mesh b32 addresses are self authenticating.
DreadfulParis It's by design.
DreadfulParis No certificate is needed.
mesh DreadfulParis: it's not authentication
DreadfulParis You can only talk with a server that has those keys.
mesh DreadfulParis: auththentication means proving identity. you can be sure that the remote end has the keys but that's it
DreadfulParis By resolving to that server and communcating with them on the b32 address it is as strong as a regular https certificate.
DreadfulParis What more could there be?
DreadfulParis Yes the server and key can be compromised and you couldn't know that ownership change.
dr|z3d a little padlock on your addressbar with facebook written on it. </sarcasm>
DreadfulParis But there is nothing else that you can do about that.
DreadfulParis When it comes to the address book though.
mesh DreadfulParis: the way I see it (1) Destinations are disposable. They're also vulnerable to ddos'ing and should be changed often and there other issues (hard to read, cut and paste errors) (2) what you really want is a certificate that can be retrieved via the Destination
DreadfulParis In the case the addressbook is compromised at the start a person would visit a site and assume it is the correct one without the guarentees.
mesh that lets you know the server on the other end is who it says it is and can be trusted
DreadfulParis mesh We use PGP keys for that.
DreadfulParis Signed messages with the full addresses.
DreadfulParis What I'm talking about is what happends if the address book is compromised.
mesh DreadfulParis: that's the right idea though you should not use pgp: google.com/search?q=don%27t+use+pgp
mesh pgp is awful
DreadfulParis PGP is the backbone of the darknet markets.
DreadfulParis It is how people authenticate and communicate over untrusted lines that can be monitored if seized.
DreadfulParis Back to the addressbook.
DreadfulParis For example if I go and sign a message saying "Everyone you can visit dread at dread.i2p" and the address book gets compromised at a later time that is bad.
mesh yeah exactlyu
dr|z3d yeah, the more I think about it, the more I think "tor has the same problem without an addressbook". and tor's being actively exploited, unlike i2p.
DreadfulParis But if I go "Everyone you can visit Dread at [b32 address]" it removes the layer of compromise that can come from the address book from being compromised.
mesh what my system does is create advertisements. Signed XML documents that include a Destination that expire
mesh I also don't use Destinations for a long period of time
DreadfulParis For is being exploite because it's popular.
dr|z3d various b32s all claiming to be the same service. apparently it happens all the time on the various hidden wikis etc.
DreadfulParis If you guys ever want to grow you will need to be popular too.
dr|z3d various .onions sorry.
DreadfulParis Yes phishing attacks.
DreadfulParis To fund DDOS attacks.
DreadfulParis Which is why PGP key authentication is a big part of everything.
DreadfulParis If someone says something that their deposit didn't arrive but doesn't have the PGP sign of the address they are not believed.
DreadfulParis Makes sense right.
dr|z3d also, another random thought by way of ddos mitigation.. increase the length of your tunnels! :)
DreadfulParis What do you mean?
dr|z3d the more hops in a tunnel, the slower it will be for an attacker to send data to your server.
DreadfulParis We can require a longer tunnel for the connection?
DreadfulParis How the fuck does that work privately?
DreadfulParis Okay tell me this.
DreadfulParis When a user gets the lease set how does it start the connection with the eepsite?
dr|z3d client acquires leaseset, client selects individual lease from leaseset, client builds tunnels to the outbound endpoint, handing off to the inbound endpoint of the server. more or less.
DreadfulParis These individual leases are kinda like introduction points to me.
dr|z3d so when a server publishes a lease, it's directing to the the last hop in his outbound tunnel, not directly to the server itself, if that makes sense.
dr|z3d introduction points are more like endpoints, the leases the directions to get there :)
DreadfulParis So when a connection is made it isn't making a brand new tunnel system to whatever the fucking client requests but something it already has?
DreadfulParis it being the eepsite i2p process
dr|z3d I want to connect to dread.i2p, I put the address in my browser, the leaseset is retrieved, and then tunnels to dread.i2p's outbound endpoint are built.
dr|z3d only if my attempt to build tunnels to dread's outbound endpoint fail repeatedly will I fall back to using exploratory tunnels.
DreadfulParis This is what a first class citizen connection is like.
dr|z3d you're evidently switched on. you'll learn a lot about how i2p works just by getting familiar with the i2p+ ui. and I think you might actually enjoy the process. just a hunch. :) anyways, brb.
dr|z3d should mention, we've got i2p+ running both of the main outproxies on the network, so as far as tuning for bandwidth is concerned, that's one of the focus points.
DreadfulParis To me the strength of the i2p network is how it handles traffic within the network.
DreadfulParis How much bandwidth do you generally handle?
DreadfulParis We can save the that question for later. I gtg. Thanks for the help.
dr|z3d aight, catch you on the rebound o/
dr|z3d DreadfulParis: I've patched the latest I2P+ build to push out leasesets to more floodfills.. vanilla i2p hits 3, previously i2p+ did 4, now it does max 8 floodfills.
dr|z3d mustafabo! you get your windows install fixed up?
mesh /win 4
mesh oopsa
mesh silly irc
DreadfulParis @dr|z3d I'll be manually editing the source to push out to a majority of my specific floodfills on the network. It's good to have redundancy.