IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2022/03/31
mesh there are i2p->tor bridges right?
mesh google for i2p tor bridge doesn't return much, but I'm sure somebody has hacked together a kind of outproxy that lets you reach tor from i2p?
RN using an i2p outproxy adds Tor capabilities on most of them if you want to open .onion or clearnet content
RN presuming you don't manage your own Tor
mesh RN: you're saying I can open .onion addresses right now through existing i2p outproxies?
mesh RN: can you think of any reason why this is a bad idea? I guess people are concerned that a "bridge" will be able to see what .onion sites you browse. Of course this is no different from clearnet sites.
dr|z3d you can browse most .onion sites over purokishi, mesh.
RN yes you can. Not 100% sure on the vanilla one, but puroshki definately does
dr|z3d or if you prefer to router your traffic via a local Tor instance, you can use zzz's socks proxy plugin.
mesh dr|z3d: what's a purokishi? That sounds familiar.
RN and the concern about bridges is the same as the concern about Tor outproxies in general. Always use caution.
RN yes, also the plugin as dr said
RN I prefer to run my own Tor most of the time, vanilla outproxy had too many catchpas, puroshki it definately better there, but running my own lets me ask Tor to change the circuit if I want.
mesh onion sites don't seem to work using the standard http proxy mechanism.
mesh dr|z3d: do I need to configure the router to use this purokishi site? I guess it must be manually added as an outproxy?
mesh dr|z3d: it doesn't seem to work though. Do I need to do anything or should it just work automatically in the browser when I plug in a .onion address?
dr|z3d if you've configured the your browser to use i2p's http proxy, and the proxy itself to use purokishi, it should work for _most_ .onion sites.
mesh ok thanks
mesh it's possible purokishi went down?
dr|z3d sure, always possible. sometimes an individual instance will need to be restarted.
mesh dr|z3d: oh it works now
mesh cool
mesh dr|z3d: twitter3e4tixl4xyajtrzo62zg5vztmjuricljdp2c5kshju4avyoid.onion doesn't work. Perhaps because twitter just created that .onion address.
mesh does purokishi use a whitelist?
dr|z3d twitter is a special case. it's doing some cert pinning that doesn't work over the outproxy. note the .. most .onion sites are http.
dr|z3d if you want to read twitter over i2p, nitter.skank.i2p might be a better bet.
mesh that's too bad but it's pretty cool.
mesh dr|z3d: does it use a whitelist?
dr|z3d did you read the about page? it tells you how it functions.
mesh it doesn't say anything about whitelist, just a blacklist
dr|z3d exactly.
dr|z3d for sites that appear on the blacklist that shouldn't be there, they'll be individually unblocked or whitelisted, but otherwise, it's a blacklist affair. whitelisting would be a full time job.
mesh ok. I guess I would be concerned about the ultimate legality of such an open proxy but that's cool that's it out there.
dr|z3d nothing illegal about running an outproxy. what users do with said outproxy is a different issue. hence blacklists to mitigate any nefarious activity.
mesh dr|z3d: yeah I think the risk is that the law tends to be literal and in this case the proxy is literally sending data that might be illegal
mesh it seems to be a very gray area though there are some cases where proxies used to violate copyright were cleared
mesh at least in the US
dr|z3d "Tor operators may be entitled to statutory safe harbor under DMCA ยง512(a) as conduits for transitory network communications"
dr|z3d The main difference between purokishi and a Tor exit node is the level of filtering that happens to mitigate any illegal usage, both at the outproxy and via a remote DNS server that also provides filtering.
dr|z3d It also filters ads, tracking telemetry servers and a bunch of other hosts.
dr|z3d Tor seems to think that a connection should provide unfiltered accessed; I don't.
mesh dr|z3d: it's an interesting idea. though all those problems go away if people just stop using http. it's a shame Tor consumes so much time and money to do something basically impossible
mesh zzz: calls to I2PSocketManager.destroySocketManager() should result in disconnecting from the i2p router right?
zlatinb mesh: yes
zlatinb actually I2PSession is the object to close
mesh zlatinb: thanks for the clarification
mesh zlatinb: what is the purpose of subsessions btw?
mesh geti2p.net/spec/i2cp says "Multiple sessions on a single I2CP connection are supported as of router version 0.9.21. The first session that is created is the "primary session". Additional sessions are "subsessions". Subsessions are used to support multiple destinations sharing a common set of tunnels. The initial application is for the primary session to use ECDSA signing keys, while the subsession
mesh uses DSA signing keys for communication with old eepsites."
zlatinb I'm not really sure. I think the way the code evolved was that a single session was towards a single destination or something like that. Then subsessions made it more like a regular Socket behavior
mesh does that mean subsessions are primary just a way to support legacy clients
zlatinb I don't think you ever use subsessions explicitly. At least not if you hide behind the I2PSocket api
mesh I2PSocketManager has methods to create and destroy subsessions I think
zlatinb hmm yes ok I don't know then what's the purpose
mesh I thought it might be necessary to use subsessions if you have multiple clients calling I2PSocketManager.connect to different Destinations
zlatinb no definitely not that
zlatinb maybe ability to send datagrams from different source destinations
zlatinb cause ultimately you get only one ServerSocket from a single I2PSocketManager so I don't see much other use for subsessions
mesh zzz: any idea why I2PSocket.close() takes forever? It seems like several minutes
mesh seems it takes a while from the time the server closes the socket to the time that client detects the closure
mesh let me try using less tunnels and 0 hops
zzz because close() does flush()
zzz subsessions are for two destinations on the same tunnel
mesh zzz: how do you mean? 2 local Destinations connected to the same remote Destination?
zzz no. two local destinations period
zzz its a migration feature when we changed sig types
mesh zzz: so best to close your eyes and pretend they don't exist? hehe
zzz exactly
mesh zzz: how expensive is it to connect to the same remote destination on a different port? I remember you saying something like ports are very "lightweight"
zzz more like free
mesh the idea being that protocol design might be simplified by telling the client to connect to a different port to download a bunch of binary data. Is this a good idea? Or will the client see significant delay when connecting on a different port?
mesh zzz: I see. so ports are really just an extra field on the packet. there is no "reconnecting" involved
zzz every new socket has overhead
zzz different port is different socket
mesh zzz: is a new socket just a new stream id to the router?
zzz sure, more or less, but it's a tcp-like 3-way handshake, but the handshake data is much bigger
zzz so do everything you can over a single socket
mesh alright. good to know.